I can imagine things like this happening very easily mid/long term: https://www.reddit.com/r/ClaudeCode/comments/1xq2n3t/a_year_....
As of 2026, I think LLMs still lack vision, and long term, tend to build a very scattered codebase, if maintainers don't pay a lot of attention.
LLMs do have cognitive limits as well!
Discussion (though topic has been flaged): https://news.ycombinator.com/item?id=50433079
But AI doesn't care. It can, and it will, happily churn through a messy codebase.
Do you have examples of where this actually worked for you? How large was the codebase, how long did you have agents generate the mess in it?
I ask because my experience is pretty different, even with Opus 5.5 and Astra - unleashing agents on a messy, vibe coded repo only seems to increase the mess. The agents just slow down more and more as they keep generating further mess, they make more and more incorrect assumptions based on bad code previous agents left behind, and I grow more disappointed in their capabilities every day.
Actually reviewing all agent output thoroughly is the only effective way I've personally found of working with agents. In order to ensure that every line of code they add is actually there for a good reason, and not organized in a way that future agents will miss it, or misinterpret it. It's the only way I can prevent them from producing worse results as the repo grows.
I find myself desiring simplifying a codebase just because I still need to make so many decisions and the cognitive load of that has gone up with how much I can do in parallel and still keep track of.
The promise of Agile is that you can release quality code on a regular tempo. The features may not yet be fully polished but you can drive small incremental releases with some set of correct+desired behavior and focus on improvements to critical areas and robustness in longer arcs as long as the core does the thing you really need it to do. Sometimes you have to come up with an equally incremental path towards the Big Refactor you want, setting up dominoes cycle after cycle till you can knock them down at once, but it can and has been done. You still need to prioritize quality and may have to be political about how you do it, and you still need management buy-in because you will not move as fast as a team throwing things against the wall -- but you'll also never actually hit a wall, or if you do it will be more of a speed bump, which is the selling point.
Edit this really has nothing to do with AI. This can be done 100% by hand, 100% by massively parallel agentic swarms, or anywhere in between. It's about process, planning, and the people (yes exclusively people) involved.
Most businesses and developers shouldn't be innovating, but instead providing secure solutions to their clients. The last 30 years of "innovation" has given us countless security bugs.
I’ve been in the industry for a much shorter period than both of you; but the companies I worked for didnt really innovate anything.
But since AI writes everything anyway, innovations that improve “developer experience” are pointless, and all the other low hanging fruit has been taken.
I don't think any of this changes with AI, the only thing is that it's possible to handle much more incidental complexity. Ultimately I expect it to land on a similar equilibrium in terms of software quality that is gated by what the users of the system will tolerate. The more things change, the more they stay the same.
I can tell you: your management skills will be copied by the AI (thanks to your input!)
I still code by hand on some personal projects and for CodeCrafters to keep myself somewhat sharp, but when it comes to paid work, my soul is devoted to Orca and running multiple Claude sessions in parallel.
My partners are happy.
Right now, management has velocity so it’s happy.
Earlier they got the code understanding as a default, and it was never something that made a difference to their metrics.
The success of the LLM Code model then relies entirely on the ability of tech debt to be cheaper to solve in the future.
My biggest issue with AI is not really technical debt, it's engineers losing sight of the system's internal working. This can make it difficult to reason about the code, fix bugs or security issues.
I just don't think we have the tools right now for engineers to accept software becoming a black box.
AI can generate "confidence" only in very limited amounts. It can help with testing, but that becomes very expensive and hard once we leave the realm of tests that can be simply written with code, like unit tests. At some point, the only way to increase the confidence in a codebase is actual testing with actual, real user interaction. And once that's maxed out, the only way to further generate more confidence is to get it into production and let real users (not test users, production users) find the remaining bugs no tester and no AI ever managed to hit.
This is the sole reason why AI doesn't make code "disposable" - yes, it can rewrite any codebase far more quickly than any human, but that new code will start at low confidence values - AI cannot transfer the confidence that the old codebase achieved simply due to being smashed against reality in production use to the new code it writes.
This is also the reason why it still makes sense to maintain libraries, even though AI could not just theoretically, but also practically write a lot of functionality from scratch that we usually import into projects via open-source libraries: the newly written stuff doesn't come with the same confidence as the already-battle-tested library does.
The problem is that oftentimes code is the only real record of the system design and specification. That creates problems because it’s harder to replace obsolete code and modules. You can try to reverse engineer a spec from current behavior, but that always leaves uncertainty about what behavior is intentional and what behavior is accidental and changeable, and because when the system behaves in surprising ways there’s no clear source of truth on if it was supposed to do that.
What I see with LLM coding is that it makes it easy for people to “at of one” a project, and armies of one tend to produce few artifacts other than the code itself. This, ironically, makes code less disposable by eliminating any sort of thoughtful, detailed record of design intent. The code itself becomes the only record, so modifying or replacing the code needs to either replicate the original code as close as possible, warts and all, or take extra care in reverse engineering and analyzing the original code to try and understand if any simplifying changes can safely be made. Which doesn’t actually happen very often because it’s a lot of generally unenjoyable work.
Which, in turn, is why LLM codebases tend to accumulate bloat at a higher rate.
But that's only valid in the industry though. Most of the software I'm using are free software, created by passionate people who used to care about quality because that's their name on the label, their reputation as an individual, their badge of honor, and also that's what makes us all feel good at the end of the day.
So, if I have few expectations from the quality of commercial software, I'm genuinely worried that open source authors would adopt AI generators too. Of course they will, I know I did. It's hard to resist. The speed gives you the fun you've lost writing good code your way.
Is code generation going to ruin the quality of open source software? I actually don't think so. I believe the benefits in terms of finding bugs (next postgres release will be the best when it lands!), conversions into better techs (finally, that old buggy python tool that's so convenient will be rewritten to rust or something), and we will have more new ideas, more people trying more things, being more ambitious etc.
Actually, it reminds me of when I transited from assembly to C, and even more from C to OCaml, for my personal projects: for a while, it was not fun! I was unhappy with the memory layout, with the GC, with the 31 bits integers, I could hear the bytes screaming at me: "come back and take care of us" and felt guilty. But, on the other hand, I was no longer typing kilometers of repetitive boilerplate, and had more time to think. Coding was no longuer typing at the keyboard, but more about thinking about designs and abstractions, and it felt both wrong to leave so much in the dark but also appealing to be able to think bigger.
And that's a bit of the same when driving an LLM: you have to spent much more time than usual designing, specifying, spelling out everything that matters; in one hand you feel that it would be faster to type the code yourself, but it's actually not true because you have an LLM to discuss the design with; whereas left to your own devices you would type and type for nights a design that you will revise several times over, rewriting most of everything several times. Now "coding" starts with a lengthy process of arguing with Claude until a good design is written down, recursively down to some good amount of details, until you can unleash the agents and voilà, you have it all done and working the next morning.
And there is some pleasure in that, too.
I'm worried for the users, for the workers, for the citizens, for myself, but not for the programmers part of us: machines will still be fun.
Using AI to generate something that had no value in first place is just silly.