The 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).

That's not vibecoding anymore.

True microservices have never been tried.

Do I smell a true Scotsman here?

Not everyone that smells like peaty whisky is a Scotsman!

Like 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.

My friend, it's possible you missed the joke.

Oh, I did indeed miss it facepalm.

Vibecoding is just not looking at the code. You can not know code, but still know what to ask for. That's already a thing we expect of LLM use; if you don't ask it right, give the right context, etc, it's not as useful. So give it the right architectural guidelines, compartmentalize your use of it, and you'll get good results.

Then we should be seeing something already, this approach exists for many years by the serverless folks. Vibe coding it should be rather straightforward since there's loads of tutorials, example code, etc. available.

The problem of this approach is the problem of "correct microservices". You are moving complexity up from the application layer to the architecture layer. If you ever had to work on "correct microservices", you will know that even for humans it becomes hard to have a mental model and reason about the system as a whole. Good luck having your LLMs tackle it, when at times the best way to describe those services is through diagrams instead of text descriptions.

Wow. 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.

You 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.

That 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.

OpenAPI, 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.

What'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.

Funny 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.

Both 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.

No, the problem is the AI can't avoid making mistakes often. I'm not measuring it on LOC.

   Now 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")

Microservices increase complexity by a lot.

Knew exactly what this was before even clicking on it. Brilliant, funny, but also realistic!

Note: the video is partially NSFW due to abusive language.

I'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.

That'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.

I'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.

AI 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...

Yeah, 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.

Using HTTP as a linker (i.e. microservices as typically implemented) gives you a ton of other problems to worry about instead though...