Try using a statically typed language, refined types, and functional programming. Your tests become limited to things that are hard or impossible to assert with the type system.
After 7 months and a 500k LOC codebase I can say that in my experience the fragility is inconsequential.
Disclaimer: I have no SaaS platform, it's a mobile app.
In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.
Most people talking about suboptimal implementation, fragility, and maintenance burden seem to theorize and extrapolate with no actual experience in implementing a large project with AI.
I can't blame them, I see the same in my day job, but the results after 500h+ on a separate project show that the concerns do not manifest in practice.
Every once in a while something comes up that proves beyond a doubt that 99% of human beings on planet earth cannot think for themselves. And most sensible things that human beings do, they do by following the herd or "instructions".
AI is a force multiplier in whatever you apply it to. Most software companies output binaries with new features, whether it runs locally or on a server. Binaries with new features. None of the business owners give a shit about what is in the binary. It may be extremely fragile and only work for one type of user, but if they only have one type of user nobody cares. Most software doesn't keep evolving forever and at some point gets rewritten as a 2.0 version or whatever, so the quality was never as important.
It doesn't have to be that way. You can use AI just as effectively to produce quality source code as you can slop binaries. It depends on the business priorities and what is actually important.
The caveat is if you are the one engineer on the team trying to use AI the right way to produce quality source instead of binaries as fast as possible, you might get left behind or let go since your work no longer aligns with the business.
AI is great at following patterns and loves to write tests. Start with good patterns that most teams would not have the discipline to write by hand and it is possible to get very robust code.
Imagine a junior engineer in the same position: they write shallow tests, they write overly complex code.
What do you do? You provide guidance, support and tooling so they can write better tests and code. You supervise and help them meet the standard. It is the same with AI agents (including the challenge of how to carry that knowledge around and transfer it). You are responsible.
You are also responsible for the understanding part: know what is being worked on, glance at changes, inspect the outcomes, cross-check specifications, tests, product requirements. The 'moving too quickly' idea is the other side of the same coin; it is your responsibility to keep track of things and decide what's worth intervention. The exact same thing happens in a project where you have ten developers (or 200) working together — you cannot possibly read all of the code they write.
we'll recalibrate eventually based on understanding what level of abstraction we can operate on. If these code bases become unmanageable then the trend will correct itself.
I can't imagine a broad movement of devs using AI more thoughtfully without a widespread incentivisation from employers. And I can't imagine the latter at all. We'll probably just have to cope with more brittle/fragile codebases.
I do agree with some parts but not others. Reverting a flawed changed, e.g. should have never been as difficult as I have seen it been in some orgs before the advent of LLMs. Same for poor UX landing, both are issues that sure, may be thrown into sharper relief now, but were issues in some code bases and not others and remain that way today. More over, they are issues which can be permanently addressed in the former and in the later are one of the key sources of differentiation today.
On code readability, shallow tests and general quality, I can agree emphatically, though not universally. In other words, there are models which write the densest, hardest (for me) to parse code and tests that break with the lowest load/timing deviations yet proof less than nothing.
These do that regardless of how much one ships in my experience however so I wouldn’t attribute this to the velocity and more poor data at the heart.
I know this reads a bit like “you are using the wrong model” and I understand if someone testing e.g. an OpenAI models understandably extrapolates across all models and considers poor parse-ability in code a likely result of velocity, but you can always step back and work slower, plus, for what it’s worth, I struggle to parse OpenAI code when running their models through my evals after step 7 which is still a fairly measured in scope code base.
Essentially, I have seen LLMs, even the newest frontier, produce barely legible slop when building simple CRUD and I have seen a massive rewrite of the existing Firefox code base using APZ to enable an infinite canvas of browser tiles grow in a manner where, even at this stage having replaced a lot outside Places and Gecko, I can walk through changes made and explain the logic, as well as look at any part I haven’t been in for a while and find my bearing even without assistance.
Whatever model you use, however much you trust it, if you can get a grip and explain what something does, that puts you in great shape. It also, for what it’s worth, helps future changes by better models to land with higher token efficiency and accuracy. I have put Opus 5.5 into a GPT-6 Astra written code base and it could land features, but the rework the model did along the way was eye opening. I then repeated, explicitly enforcing no changes beyond the initial scope which Opus 5.5 still could succeed in, but took far longer, far more tool calls and significantly more tokens then that change should have taken. I also have examples where any model can be more error prone and slower than myself, though those are unique and I myself have been told I was using the wrong model and sucked at prompting.
Use models like any tech if you want for what you feel comfortable for or don’t, both can yield good or bad outcomes. Code was, for me, always a means to an end, enabling something. That hasn’t changed and never needed more LOC or massive scope.
The silent part is "undirected". You can patch these holes by observing them and the author us aware. By itself, these are the flaws.
I think speed is the biggest flaw though. If i could get variable speed while planning vs building, thatd change some things. I run local models, so i am mostly in the slow lane. When patching these flaws, i want it to read the code parts and diagnose quickly.
When its coding, i want to see the problems its encountering with the prompt. I usually observe its thinking a few rounds and if it misunderstands, i redirect.
But in all of this, i want a dial that just speeds up once i feel its doing the right thing.
SOTA today, to me, would put a model floor like qwen3.8-flash-next on a platform i can dial up the speed. Thats all. I think many of us will bring our own harness, so the only hard point is how dumb the engineers tools are.
Since im building local, my tools do a lot more management. So.e of tge opinions i see on HN trigger a "skill issue" reflex because we have a whole shopping mall now if tools and the incurious seem oblivious to how these models are used by cloud providers.
Learning about the raw capabilities of LLMs makes getting them to "do the right thing" is now just a job description.
Lastly, the last decade of tech oligarchy exposes how little education elites had about humanity and wicked problems. Elon musk reinventing public transportation several times ignorantly. The fact that a social program requires the consent of the people it helps. LLMs are a stark lesson in the difficulty of knowing all the constituent parts and still being unable to predict outcomes.
> Elon musk reinventing public transportation several times ignorantly.
In interviews, he admitted that the Hyperloop was intended to mess up the California High Speed Rail project because trains are boring. It's the opposite of ignorance, it's malice. Hanlon's inversion.
Try using a statically typed language, refined types, and functional programming. Your tests become limited to things that are hard or impossible to assert with the type system.
My code has never been stronger.
After 7 months and a 500k LOC codebase I can say that in my experience the fragility is inconsequential.
Disclaimer: I have no SaaS platform, it's a mobile app.
In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.
Most people talking about suboptimal implementation, fragility, and maintenance burden seem to theorize and extrapolate with no actual experience in implementing a large project with AI.
I can't blame them, I see the same in my day job, but the results after 500h+ on a separate project show that the concerns do not manifest in practice.
Available in the AppStore? Would love to see it!
This is absolutely right because AI lacks Fingerspitzengefühl: https://architecturenotes.co/p/the-cost-of-ai-in-code-goodby...
AI doesn't "lack" it, it just may have less of it, and the gap is closing. Like it or not.
We just need new Software Engineering books that explain how to build software in the AI age.
Every once in a while something comes up that proves beyond a doubt that 99% of human beings on planet earth cannot think for themselves. And most sensible things that human beings do, they do by following the herd or "instructions".
The question is, is it really a problem when letting agents rewrite everything better costs not that much.
Business incentives create fragile codebases.
AI is a force multiplier in whatever you apply it to. Most software companies output binaries with new features, whether it runs locally or on a server. Binaries with new features. None of the business owners give a shit about what is in the binary. It may be extremely fragile and only work for one type of user, but if they only have one type of user nobody cares. Most software doesn't keep evolving forever and at some point gets rewritten as a 2.0 version or whatever, so the quality was never as important.
It doesn't have to be that way. You can use AI just as effectively to produce quality source code as you can slop binaries. It depends on the business priorities and what is actually important.
The caveat is if you are the one engineer on the team trying to use AI the right way to produce quality source instead of binaries as fast as possible, you might get left behind or let go since your work no longer aligns with the business.
it doesn't have to.
AI is great at following patterns and loves to write tests. Start with good patterns that most teams would not have the discipline to write by hand and it is possible to get very robust code.
Read his first point bro
AI Without Oversight Considered Harmful :)
AI non-usage brings about irrelevance under pressure from competitors with fragile codebase.
Imagine a junior engineer in the same position: they write shallow tests, they write overly complex code.
What do you do? You provide guidance, support and tooling so they can write better tests and code. You supervise and help them meet the standard. It is the same with AI agents (including the challenge of how to carry that knowledge around and transfer it). You are responsible.
You are also responsible for the understanding part: know what is being worked on, glance at changes, inspect the outcomes, cross-check specifications, tests, product requirements. The 'moving too quickly' idea is the other side of the same coin; it is your responsibility to keep track of things and decide what's worth intervention. The exact same thing happens in a project where you have ten developers (or 200) working together — you cannot possibly read all of the code they write.
Seeing all of these as downsides is a choice.
And you end up rewriting this stuff yourself.
Humans not using their own brains and relying on AI to think for them creates a fragile code base.
I say that as a frustrated slop fighter.
we'll recalibrate eventually based on understanding what level of abstraction we can operate on. If these code bases become unmanageable then the trend will correct itself.
I can't imagine a broad movement of devs using AI more thoughtfully without a widespread incentivisation from employers. And I can't imagine the latter at all. We'll probably just have to cope with more brittle/fragile codebases.
> We'll probably just have to cope with more brittle/fragile codebases.
Is this not incentive enough to use AI more thoughtfully?
>we'll recalibrate eventually based on understanding what level of abstraction we can operate on...
This would be at the level of helper functions < 10 lines of code.
> I say that as a frustrated slop fighter.
That part was obvious, no need to explain it.
I do agree with some parts but not others. Reverting a flawed changed, e.g. should have never been as difficult as I have seen it been in some orgs before the advent of LLMs. Same for poor UX landing, both are issues that sure, may be thrown into sharper relief now, but were issues in some code bases and not others and remain that way today. More over, they are issues which can be permanently addressed in the former and in the later are one of the key sources of differentiation today.
On code readability, shallow tests and general quality, I can agree emphatically, though not universally. In other words, there are models which write the densest, hardest (for me) to parse code and tests that break with the lowest load/timing deviations yet proof less than nothing.
These do that regardless of how much one ships in my experience however so I wouldn’t attribute this to the velocity and more poor data at the heart.
I know this reads a bit like “you are using the wrong model” and I understand if someone testing e.g. an OpenAI models understandably extrapolates across all models and considers poor parse-ability in code a likely result of velocity, but you can always step back and work slower, plus, for what it’s worth, I struggle to parse OpenAI code when running their models through my evals after step 7 which is still a fairly measured in scope code base.
Essentially, I have seen LLMs, even the newest frontier, produce barely legible slop when building simple CRUD and I have seen a massive rewrite of the existing Firefox code base using APZ to enable an infinite canvas of browser tiles grow in a manner where, even at this stage having replaced a lot outside Places and Gecko, I can walk through changes made and explain the logic, as well as look at any part I haven’t been in for a while and find my bearing even without assistance.
Whatever model you use, however much you trust it, if you can get a grip and explain what something does, that puts you in great shape. It also, for what it’s worth, helps future changes by better models to land with higher token efficiency and accuracy. I have put Opus 5.5 into a GPT-6 Astra written code base and it could land features, but the rework the model did along the way was eye opening. I then repeated, explicitly enforcing no changes beyond the initial scope which Opus 5.5 still could succeed in, but took far longer, far more tool calls and significantly more tokens then that change should have taken. I also have examples where any model can be more error prone and slower than myself, though those are unique and I myself have been told I was using the wrong model and sucked at prompting.
Use models like any tech if you want for what you feel comfortable for or don’t, both can yield good or bad outcomes. Code was, for me, always a means to an end, enabling something. That hasn’t changed and never needed more LOC or massive scope.
The silent part is "undirected". You can patch these holes by observing them and the author us aware. By itself, these are the flaws.
I think speed is the biggest flaw though. If i could get variable speed while planning vs building, thatd change some things. I run local models, so i am mostly in the slow lane. When patching these flaws, i want it to read the code parts and diagnose quickly.
When its coding, i want to see the problems its encountering with the prompt. I usually observe its thinking a few rounds and if it misunderstands, i redirect.
But in all of this, i want a dial that just speeds up once i feel its doing the right thing.
SOTA today, to me, would put a model floor like qwen3.8-flash-next on a platform i can dial up the speed. Thats all. I think many of us will bring our own harness, so the only hard point is how dumb the engineers tools are.
Since im building local, my tools do a lot more management. So.e of tge opinions i see on HN trigger a "skill issue" reflex because we have a whole shopping mall now if tools and the incurious seem oblivious to how these models are used by cloud providers.
Learning about the raw capabilities of LLMs makes getting them to "do the right thing" is now just a job description.
Lastly, the last decade of tech oligarchy exposes how little education elites had about humanity and wicked problems. Elon musk reinventing public transportation several times ignorantly. The fact that a social program requires the consent of the people it helps. LLMs are a stark lesson in the difficulty of knowing all the constituent parts and still being unable to predict outcomes.
Welcome to Socioligy 101 tech nerds.
> Elon musk reinventing public transportation several times ignorantly.
In interviews, he admitted that the Hyperloop was intended to mess up the California High Speed Rail project because trains are boring. It's the opposite of ignorance, it's malice. Hanlon's inversion.