AI usage generates a fragile codebase (evanxmerz.com)

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.

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.

Using AI to generate something that had no value in first place is just silly.

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.

But AI doesn't care. It can, and it will, happily churn through a messy codebase.

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 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!

I can tell you: your management skills will be copied by the AI (thanks to your input!)

No doubt code quality increased substantially, but I've been wrestling overengineering for a long time, with both GPT/Claude - they will take any small chance to write excess code/documentation/specifications, anything - they seem to love reinventing the wheel. Heck, even prompts sent to subagents are walls of text.

Explicitly requiring simple solutions works for simple problems, but for more complex ones, complexity quickly creeps in. I even ask the alternative model to challenge the complexity of solution, but doesn't work really well.

There is a perverse incentive for AI companies to train models to be verbose, as it increases the tokens consumption.

> "My immediate question would be what kind of adversarial reviews and deterministic gates did the author write to capture the dimensions of maintainability (lack of DRY, cyclomatic complexity, unclear naming, poorly architected flows, etc) that they cared about."

I wrote a tool at Meta to use AI to solve all those issues at scale. I don't necessarily think it really solves the problem, although I'm unsure about the reason (perhaps that's why they got rid of me!). There's something about codebase brittle-ness that isn't captured with those well-known, easy-to-catch quality issues. It could be related to architecture, design patterns, or something else that's a little larger than even the largest LLM context windows right now.

I think code validation is an interesting problem. It's like judging "rightness", which is an inherently subjective thing in all except the trivial cases.

And further, surely you know some very strong programmers who are very bad at art, or math, or human relationships?

We will just repeat the same pattern, have the latest and greatest frontier models rewrite the software just like how many desktop monoliths moved to React SPAs.

The real winners are frontier labs, we pay them to write black box software and we pay them to rewrite the software.

I've always thought that good engineering should go smoothly by definition. You shouldn't be juggling a ton of bugs and broken develompent pipelines. The problem is justifying this in a work culture that doesn't care about quality and is stuck looking at numbers that can be immediately justified.

Depends on use case

Doesn't seem like a good strategy to me.

For the last 20 years of my career, I have prided myself on keeping a clean codebase, making 'art-not-science' decisions of when and what to abstract, scope boundaries, then implementing them cleanly, specifically to be easily grok'd by other developers. But after building, from scratch, and operating an (essentially) vibe coded software solution (in typically a very engineer led/low level space) over the last 9 months, I am still able to move at super-human speeds in terms of delivering features, investigating and fixing any issues (there aren't many, certainly less than most human teams I've been in) - whether that's because of AI advances or just their innate quality of being able to tackle the dross coding tasks that always got avoided by humans in my past I'm not sure but I'll stick with it until a better approach becomes apparent!

I feel my specialist skills (coding, debugging, devops) has been devalued - I can't justify holding those as my value-add proposition any more - but new skills are replacing those (context/AI/agent engineering) in equal measure.

For a different perspective, the european peers in my developer network, while never outspoken against their company, like, and redistribute content that circle around the same points. Some have fixed mandates to use AI, in order to use AI, working more to keep the product stable (even outside normal work hours), or complains about the divide between management and developer's perspective on these tools.

There is also some consideration about compliance issues and liability when you're stamping commits with your name (luckily for almost all software enginners there is no malpraxis law to punish gross negligence).

I have had experiences out of my technical depth where I’ve instructed an agent to do something technically nonsensical. The agent tried to do it, creating a mess. Nothing works, I get frustrated, only to realize I have a fundamental misunderstanding of something technical.

A similar thing happens when you ask for something, but the complexity for the perfect solution is 10 x the complexity of a simpler, 90% solution. And sometimes you only realize that looking at code (or feeling lots of brittleness)

This raises alarm bells. It's a deeply unserious take on software development that I hope doesn't spread (but I know will). YOLO it all.

We absolutely will regret the slop AI, as it will become load-bearing (ahem) in short order. There will be critical outages and people will die.

reminds me of all the PHP spaghetti code that would float around because it was "quick and easy" -- eventually that all becomes brittle and someone has to come in and rearchitect it from scratch

you may not pay the price, but your successor will

but then again, you could say that's your employer's problem, not yours (and you'd be right)

the biggest problem is the future, not the present. Presently, we -- you, I, others -- still have the skill and experience to look inside the box and understand it, guide the LLM to make smarter decisions, etc.

not only will those skills atrophy in ourselves, but the younger generation won't even develop them in the first place. eventually you have almost no one who understands anything about how things work, they just know how to issue high level commands. It's like if eventually everyone working at CERN just knows how to push the buttons on the LHC but doesn't understand much beyond that. That's where we are heading.

But what happens when your Node runtime, OS, compilers, or even libraries start regressing to the same lower-quality level? Everything starts collapsing and falling apart. That matters.

Not really? A lot of companies have comparable codebases that are kept in check.

Service-oriented architecture helps at this scale by forcibly creating boundaries.

A good lithmus test I've noticed is "I want to do this thing the system should do", and if claude identifies a major refactor - well that's a sign the code needs a human touch first.

My futzing around is now at a higher level and involves enlisting the help of agents to dig through the code and logs and other sources to help solves problems.

Right now I am working an effort to reduce the amount of "build friction" across our code base. Even scoping this out would have taken a non-trivial amount of time and fixing it would never have been funded. With the help of AI tools, I can now attach this problem and make the lives of hundreds of engineers better.

it's not gone, it's literally a prompt away. I run "tech debt" loops all the time, ask it to simplify the code and architecture, remove left over code from previous refactors.

the quality of the resulting code is better than ever

Assuming you mean an average software developer, that's still an incredibly low bar.

    Code quality is no longer a concern to almost anyone

Being able to speak to what’s possible or not will definitely be a valuable skill.

Hopefully when the cost of tokens rises and your company can no longer afford to pay for it at the level needed that someone will be willing to keep it running.

The bill for the API usage was _hundreds_ of times higher than the subscriptions. Companies with a few hundred engineers, but without sky-high margins, simply cannot afford not to understand their codebases.

I also don't think this is the right way. We are giving away practices and lesson learned over decades, in just over 6 months without fully understanding long term implications both technical and non-technical. And that is based on very optimistic bet that models will be able to handle all those potential issues that we might be concerned about in present. All the arguments/counter-arguments are mostly speculative, and I think only time will tell. My speculation is that this all BS will at some point self-correct at some point, it wont be like pre-LLM but it wont be crazy vibe-code don't look at code (or pretend we review code) either.

I remember the "software craftsmanship" movement of the early and late oughts. Refactoring patterns, clean architecture and all that--nobody outside a tiny group gave a single sh*t about it.

We all may end up ignoring the source code most of the time. But for a few years at least, we won't be able to ignore the quality of it, because nobody knows how to use "AI" in a way that has stable high quality over years of changes.

Another note: some software has a history of multiple decades. In fact, I happen to work on such software. IMO it would be irresponsible to turn the code into an incomprehensible slop fest just because some AI boosters want me to believe that "coding is solved" or "software is dead".

https://epiq.sh/blog/the-soft-fabric-of-agentic-code

"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.

Also: syntax is for humans, might as well use LISP AST syntax for all future languages since no human is going to read it anyway.

Also, sharing a link would be great if you're comfortable with the idea.

Codebase has never been better and healthier, and any tech debt that has been accumulated after a few releases can be removed in a few prompts when you are out of product ideas and have some free tokens to spare.

(I added US mountains and trails btw: https://fescims.com )

I have seen all those when running a fairly new eval inspired by something I read in the ts-rust repo, giving a simple GPT-6 Astra code base to Opus 5.5.

Implementation accuracy was higher and token usage lower when Opus 5.5 got a Fable 5.1 built code base of the same feature set and coverage compared to the fragile GPT one. Incidentally I struggled to parse the latter but not the former.

Yes, a modern model will happily work on the most unmaintainable slop (doesn’t even need to be LLM derived slop, we have all seen bad Human written code) and that is great if you have an old code base to maintain. But if one can avoid it, even if one uses only models and never looks at the code, being efficient has value. Heck, rewrites are doable and affordable now, I have restarted projects and the gains were quickly apparent, even if we just look at model usage efficiency gains.

At the current pace, the very idea of maintaining software will become as relevant as the idea of trimming wicks, stropping razors - or making every frame you take with a camera count.

When the marginal cost of replacement drops to a sufficiently low level, the entire paradigm changes.

I say this as someone with 30+ years of development experience, who built everything to be maintained until the heat death of the universe. I just don't think it's a relevant question in this brave new world.

This reminds me of Moore's law in the 1990s.

If you program ran slowly, or used too much RAM, you could spend six months optimising it (or removing features). Or you could just sit on it for six months and release it as it is - hardware moved on so fast that, by then, it probably ran successfully.

Your suggestion is a bit like this: don't worry, the pace of model understanding will catch up faster than the code will get disorganised.

I'm not saying I agree but it's an interesting idea.

how many users do you have and how long has your app been out there?

unless that number is very large, then you have no idea whether your app is fragile or not

example: I own a Polestar 4. Great car, love it. I have non-deterministic SW glitches. Other people have non-deterministic SW glitches, but they're not the same ones as me. Other people never encounter any glitches. Others have tons of glitches that I don't have. Every new car that is sold, is another edge case. We had a Tesla for years, and the SW was rock solid, great stability. Why? Because their SW has been out there for over a decade with millions of experience points, and they have a large team that are aggressive about fixing and rolling out updates almost daily. Until you get to that point, you can't judge whether your vibe-coded app is stable or not.

“It’s not a code base that warrants that size, it’s a mobile app”

“Fragility is inconsequential to me and I am blind to my users dealing with it”

i'm working on a fairly complex application and it's not even near 200k loc. but this is the second version - the first was vibe coded and was over 400k and full of bugs/issues that were slowing down development. i rewrote it and it's half the size, half the dependencies, and much faster & more robust.

is it more complex than your app? hard to say since neither of us want to disclose our identities :)

This felt very out of touch for the reason you brought forth: hand-crafted products very often become more valuable in an industry where production is done at-scale. (Provided the hand-crafted product is of high quality.)

We’ve discovered a way to take what someone asks for and generate a lot of relevant code at a significantly lower cost than what it would take to contract out. Maybe for small requests this could be fine for users in the future, but inevitably people will prefer carefully-crafted codebases that provide robust experiences or high reliability.

just curious, and tempted to do the same, so far I don't like the code made by llms in dynamic languages codebases

Type systems are not a panacea. You still have to be logical and careful about them, especially around boundaries where types are just assumptions and not logical inferences. Then you have functions that switch type, but only a subset of the input is actually valid (string -> int for a number parser). Checking for NaN is like checking for Null.

Type systems does help, but they need the same attention as code to be actually helpful.

Step 3: Prompt the agent to write mutation tests to harden the suite

Step 4: Prompt the agent to write property-based tests.

Step 5: Prompt the agent for 100% code coverage

Step 6: Keep a look out for small issues with steps 2-5 above and refine a Skill or Rule to package the workflow and plug gaps in the model's current shortcomings.

Step 7: Dedicate some time to manually reviewing and thinking about interesting edge cases worth testing.

---

If you follow these steps, you will have better test coverage than 99.9% of any code an engineer ever wrote pre-AI... and it will be almost completely automated.

My team's incidents and bugs are DOWN this year while we're shipping more.

Leveraging AI effectively requires a new paradigm of interaction. The name of the game is to use techniques and strategies and guardrails that create an environment that produce good software.

Eventually unsupervised code leaks because you stop reading the 3rd (+1200, -350) pull request

Compute > Insight. Every time.

We can keep searching for essential human characteristics that humans have and AI lacks, but every attempt increasingly resembles an ego-preserving negotiation with the inevitable march. It's reminiscent of the God of the Gaps[2], but for human exceptionalism. As AI competency encroaches on more and more of human ability, we'll retreat into smaller and smaller gaps - foxholes of inimitablity.

As long as human value is justified by ability, quality, or characteristic, this problem will endure. The one escape hatch is the classical liberal idea that human value isn't tied to anything, that, by virtue of being human, people have universal, inalienable worth.

We should stop the project to attempting to substantiate human value by other means.

1. https://en.wikipedia.org/wiki/Bitter_lesson

2. https://en.wikipedia.org/wiki/God_of_the_gaps

Now it's gone. Spec-driven dev isn't the answer either, some of the UX bugs areas are simply not something that ever existed in the regression suite.