That said, my experience tells me that enterprise and business coding has rarely ever been about stable or robust codebases. We engineers and a fraction of competent engineering managers and a vanishing small number of directors fought against business interests to ensure quality was priority when it came to code, but it was always an uphill battle and we were oftentimes disciplined for spending too much time on quality and design.
A timed cadence of release is anathema to quality code because you can't timebox it.
So, AI is just the extension of that. Do I try to ensure my agents design code I would consider to be good? Yes, absolutely! But I've fully outsourced it and I find it's also fully capable of fixing it's own mistakes. I've gone far beyond anything I individually or even with a team was ever capable of with AI assistance, so I believe I just have to apply my experience and skills into management and architecture rather than actual lines of code.
Time only will tell how this plays out.
Wallaahu aʿlam.
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!
But AI doesn't care. It can, and it will, happily churn through a messy codebase.
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.
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 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.
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.