4 ms·
Anyone who regularly uses LLMs to produce code knows that vibe coding anything larger than a to-do app is not currently realistic. Once your codebase reaches t
by spicyusername 1y ago
Anyone who regularly uses LLMs to produce code knows that vibe coding anything larger than a to-do app is not currently realistic.
Once your codebase reaches the size needed to solve actual business problems, the quality of the output varies wildly, the complexity of the prompts required to produce useful code increases, and the output code requires significant editing to actually integrate without bugs or errors.
My personal opinion is that for vibe coding to be viable as the complexity of feature requirements or the size of the code base increase, the specificity and complexity of the input prompt will eventually demand more from the engineer than just writing the code, since code is more specific by definition than natural language.
- okokwhatever 1y agoOpenAPI, microservices segmentation and keeping things small helps a lot. Probably the worst piece of the puzzle is the UI to maintain the coherence but it can be solved.
- tester756 1y agoMicroservices increase complexity by a lot.
- stavros 1y agoWhat's the largest app you've entirely vibe-coded with this architecture? For me, everything fails at a few hundred lines, no matter how micro you keep your services. Mind you, we're talking zero review at all, just using whatever the LLM produces.
- paulcole 1y agoFunny how devs here used to love bragging about how their job isn't to write code and that they shouldn't be measured on LOC. Now suddenly the problem is that AI can't write a lot of code.
- stavros 1y agoNo, the problem is the AI can't avoid making mistakes often. I'm not measuring it on LOC.
- surgical_fire 1y agoBoth can be true. LLMs have an unsolvable problem of "hallucination". It is a bad description of what the problem is because hallucination is all they do, it just also happens to be correct in many cases. The larger the codebase or the problem space, the less accurate LLMs tend to be. And developers to a lot more than generating LOC.
- JohnBooty 1y agoNow suddenly the problem is that AI can't write a lot of code. That's not the problem at all. AI can obviously write lots of code faster than a human. The problem is that AI can't currently write large quantities of correct and maintainable code to create a larger app. (For some value of "larger")
- bigcat12345678 1y agoAI created openapi is like mud house on beach, the first wave will destroy the whole thing into pieces beyond memory can remember it's original ugly shape...
- kevinmchugh 1y agoYeah, I have a rule to tell the agent to not write to any of our OpenAPI specs, it reliably mangles them and then gets stuck trying to unmangle them. I get better results modifying the specs myself and using that as context for the agent so it better understands what I want.
- jen20 1y agoUsing HTTP as a linker (i.e. microservices as typically implemented) gives you a ton of other problems to worry about instead though...
- pc86 1y agoI'm becoming increasingly convinced that you need a purpose-built LLM to generate usable UI code. There are ways to use LLMs to increase efficiency and velocity without sacrificing quality, but they're all at the API/backend/service/whatever-you-want-to-call-it level, or in the initial planning stages. I basically use LLMs to plan work, then to do the backend work with close supervision, then I do all the UX stuff completely on my own.
- chrisweekly 1y agoThat's really interesting. I feel like that runs counter to a broader perception that vibe-coding the FE / UX is straightforward, vs more challenging backend stuff. As someone whose 27-year career began with - and remained largely centered around -- client-side / FE / UX, it's of particular interest.
- pc86 1y agoI've "vibe-coded" a few small hobby projects, and use cursor sometimes for professional stuff, and it always collapses for me on "real" front-end tasks. Yeah I can say "give me a layout of a certain style" and it will do reasonably well if it has no existing constraints. But for example, I vibe-coded a UI and then tried to adjust the tailwind theme it picked, and it was an absolute nightmare. You would have thought "change the primary color from A to B, select a new accent color that is darker than what you've selected and is not A or B, and now update the dark theme to be comparable" spread across multiple prompts was one of those crazy 3d animation puzzles you see used as a way to break LLMs.
- 0xbadcafebee 1y agoThe limitation is the scope of the problem space; reduce the space and it becomes more reliable. Use the LLM to create independent discrete highly-cohesive composeable applications (with test suites), use those to compose the business logic, and it will be reliable. So basically microservices (but, actually correct microservices, rather than how most people make them).
- 0x696C6961 1y agoThat's not vibecoding anymore.
- pc86 1y agoTrue microservices have never been tried.
- tempodox 1y agoDo I smell a true Scotsman here?
- dc10tonite 1y agoNot everyone that smells like peaty whisky is a Scotsman!
- piva00 1y agoLike some bizarro world of Unix Philosophy-esque tools mashed into the approach people have when creating "serverless" applications? Or define what a true microservice is because I think there are many takes on that.
- pc86 1y agoMy friend, it's possible you missed the joke.
- 1y ago
- OutOfHere 1y agoThat expresses it well. For the code output to be good, my specifications have to be very detailed and thoroughly reviewed by multiple LLMs. Even so, I still have to make some changes manually, both before and after the code generation. It could be possible to add broad refactoring steps with vibe coding, but I remain skeptical. I think the frontier of how far one can get with vibe coding will keep pushing forward, but it's not that far yet, especially when security and performance are on the line.
- deleted 1y ago[deleted]
- rubicon33 1y agoWow. I’ve never actually heard this take before but I think you’re spot on. Vibe coding has serious limits as the scale of the project grows. As the complexity grows, human language becomes a crude tool compared to just coding and you will find your efficiency falls off a cliff trying to get the LLM to understand and effectively change or implement what you could have done by hand.
- deleted 1y ago[deleted]
- sixtyj 1y agoYou can vibe code chunks, but not whole repo. I have tried to do it and every LLM starts to hallucinate after 2-3 hours. And you have to know what you want to achieve. Coding with “a little help” is feasible.