> If you keep vibe-adding features, and somehow keep getting customers to pay for this thing, what happens once the codebase becomes so complex that an LLM cannot fit it inside its “brain”?
you realize this point is well, well beyond what a human can "fit" in their brain as well? you start making shorthands and assumptions about your systems once they get too large.
This is true, but it ignores the fact that claude constantly pushes the code toward more complexity.
Any given problem has a spectrum of solutions, ranging from simple and straightforward, to the most cursed rube goldberg machine you've ever seen. Claude biases toward the latter.
When working on larger code bases, especially poorly factored ones (like the one claude tends to build unsupervised), it's default mode of operation is to build a cursed rube goldberg machine. It doesn't take too long before it starts visibly floundering when you ask it to make changes to the software.
Complexity management is something human software engineers do constantly. Pushing back against complexity and technical debt is the primary concern for a developer working on a brownfield project. Everything you do has to take this into account.
I think the existing comments already cover it most, also, I would argue that we are seeing a new emerging group of coders come into the realm of programming and we are judging them at their worst and comparing them to our best. It is quite insane to me to expect someone who just started to fully build google.com and all of it's infra,security,etc.
If you want proof that there's a serious issue with vibe-coding over the long-term, all you need to do is be a Claude Code user and see how for every release they make they either create 5 new bugs, or re-introduce 5 they've already patched 15 times over the last year.
The creators of Claude can't even vibe-code well. Claude Code is one of the sloppiest, least stable tools I've ever used. Anthropic has already proudly boasted about Claude Code is entirely vibe-coded and vibe-maintained. It's not a flex. It's a signal not to trust it.
> The creators of Claude can't even vibe-code well. Claude Code is one of the sloppiest, least stable tools I've ever used
Claude Code was not designed on a stable architecture and was completely vibe-coded itself on a weekend so much that the authors can't read the code and are instead more like sales focused than engineering focused other than the Bun authors who are doing the actual work.
If it wasn't for the Bun developers, Claude Code itself would become completely unmaintainable.
The main thrust of the article is that codebases can grow too large to be manageable by LLMs.
> It simply will not fit the context window, and README files are of limited use.
I think many useful applications can be built without reaching current context window limits, which will certainly grow. Besides, there are many tricks that Claude Code and Codex use for getting around this problem, such as compacting and sharding a task across many agents.
articles like these almost always strike me as sour grapes, people trying to make vibe coding look bad, because of job security. Is vibe code good? I would argue, for the vast amount of BS little corporate IT projects out there yes, and it's just going to improve. Is it good enough for anything serious...hell no, but it might be soon.
I agree that AI today over-engineers. However with the rate that everything is improving, do people really think that it's also not going to be able to refactor and optimise the code in a year or two from now? It can already do a decent job at it today if you prompt it to.
13 comments
[ 3.8 ms ] story [ 32.4 ms ] threadyou realize this point is well, well beyond what a human can "fit" in their brain as well? you start making shorthands and assumptions about your systems once they get too large.
Any given problem has a spectrum of solutions, ranging from simple and straightforward, to the most cursed rube goldberg machine you've ever seen. Claude biases toward the latter.
When working on larger code bases, especially poorly factored ones (like the one claude tends to build unsupervised), it's default mode of operation is to build a cursed rube goldberg machine. It doesn't take too long before it starts visibly floundering when you ask it to make changes to the software.
Complexity management is something human software engineers do constantly. Pushing back against complexity and technical debt is the primary concern for a developer working on a brownfield project. Everything you do has to take this into account.
Claude doesn't.
The creators of Claude can't even vibe-code well. Claude Code is one of the sloppiest, least stable tools I've ever used. Anthropic has already proudly boasted about Claude Code is entirely vibe-coded and vibe-maintained. It's not a flex. It's a signal not to trust it.
Claude Code was not designed on a stable architecture and was completely vibe-coded itself on a weekend so much that the authors can't read the code and are instead more like sales focused than engineering focused other than the Bun authors who are doing the actual work.
If it wasn't for the Bun developers, Claude Code itself would become completely unmaintainable.
> It simply will not fit the context window, and README files are of limited use.
I think many useful applications can be built without reaching current context window limits, which will certainly grow. Besides, there are many tricks that Claude Code and Codex use for getting around this problem, such as compacting and sharding a task across many agents.