The impact of AI tools and AI-generated code on software development cannot be overstated. Lately I’ve heard a lot of chatter ranging from “save us from drowning in AI slop” to “we are all going to be unemployed in a year”. For those old enough to remember, or at least to have read about it, this is not the first time we have tread these waters. When the first high level language compilers were built back in the 1950s, many similar arguments were floating around.
The complaints worth arguing about
The slop complaint does have some traction. A widely circulated r/ClaudeCode post shows what AI-generated code looks like when it piles up unchecked. The poster describes a three-month-old repository with 220 handlers, only about 20 of them actually reachable, more than 40 secrets where two were required, and 309,000 lines of code buried under 240,000 lines of documentation. The author rewrote it smaller in a week. Treat that as an anecdote rather than a measurement, but it is the kind of anecdote that shows up constantly right now, and it is worth keeping in mind while reading the following.
Let’s start with the complaints about AI-generated code that actually have legs. Don’t focus on the hallucinated APIs or invented function signatures. Those gaps are real today, but they are closing at a visible rate. The ones that matter are structural, because they are about what happens to your codebase and your team rather than about how good the model is:
- Maintainability of AI-generated code nobody fully understands
- Review overhead consumes the time the tool promised to save
- Junior engineers never building the underlying skill
- Security defects appearing in AI-generated code and surviving into production
The evidence against AI-generated code
The first two have real evidence behind them. GitClear’s analysis of 623 million code changes from 2023 through 2026 found refactoring line moves down 70%, cross-file function calls down 35%, and legacy maintenance down 74% against 2022, while block duplication rose 81% and error-masking constructs rose 47%. Throughput is soaring upwards, but the structural habits that keep a codebase workable are eroding underneath it.
On review overhead, METR ran a randomized controlled trial in early 2025 with 16 experienced developers across 246 real tasks in repositories they had worked on for an average of five years. Developers forecast that AI would cut completion time by 24 percent. But when they actually measured, using AI increased completion time by 19 percent. Afterward, those same developers estimated they had been sped up by 20 percent. The perception and the measurement differed by nearly 40 points.
That is the strongest version of the case against using AI to write code. Keep that in mind as we take a trip down memory lane.
The same objections, in 1957
John Backus started the FORTRAN project at IBM in 1954 and the first compiler shipped on the IBM 704 in April 1957. The systems that came before it produced programs typically five to ten times slower than hand-coded equivalents. Efficiency became the primary design objective for the project, rather than just an included feature. The claims made for and by FORTRAN met widespread skepticism among working programmers, and that skepticism was not ignorance. Machine time was expensive and programmer time was cheap. A tool that wasted a factor of five was not labor-saving, it was a way to make your program too slow to run.
The maintainability complaint was there: compiler output was code no human wrote and no human intended to read, running on machines people were accountable for. The review complaint was there in concrete form, because you pulled the assembly listing and checked the compiler’s work, since you did not yet believe the compiler could do the work.
And the skill complaint was the loudest. Backus later described the pioneering programmers of that era as a priesthood guarding skills and mysteries considered too complex for ordinary people, and that plans to make programming broadly accessible met considerable hostility and derision, along with disbelief that a mechanical process could do the inventive work required to produce an efficient program.
The priesthood was right that the knowledge would be lost but they were wrong about how long they had! A 1958 survey found that more than half of all code running on IBM computers was being produced by the FORTRAN compiler.
Security has no 1957 analogue, because nobody was thinking about it back then. Its parallel comes later and it is less comfortable… but more on that later.
What a for loop actually turns into
Here is a function any second-year CS student can read:
int sum(const int *a, int n) {
int s = 0;
for (int i = 0; i < n; i++) {
s += a[i];
}
return s;
}
Ask an engineer to predict the compiled output and you get something like: zero a register, load an element, add it, increment the index, compare against n, branch if less. Load, add, increment, compare, jump.
Here is what GCC 13 actually emits at -O3 on x86-64 with AVX2. These are the first 25 lines of 88:
sum:
endbr64
mov r8, rdi
mov edx, esi
test esi, esi
jle .L7
lea eax, -1[rsi]
cmp eax, 6
jbe .L8
mov ecx, esi
mov rax, rdi
vpxor xmm1, xmm1, xmm1
shr ecx, 3
sal rcx, 5
add rcx, rdi
.L4:
vpaddd ymm1, ymm1, YMMWORD PTR [rax]
add rax, 32
cmp rax, rcx
jne .L4
vmovdqa xmm0, xmm1
vextracti128 xmm1, ymm1, 0x1
mov ecx, edx
vpaddd xmm0, xmm0, xmm1
and ecx, -8
The tradeoff
Five lines of C, 88 lines of assembly. There is no loop counter. The variable i does not exist. The accumulator lives across eight vector lanes and gets folded down at the end by a cascade of shifts and adds that appears nowhere in the source. I cut 63 lines, most of which are a fully unrolled scalar tail handling the up-to-seven leftover elements that did not fill a vector, plus a separate path for arrays too short to vectorize at all.
The architecture is beside the point. Compile it for ARM and you get something tamer that still looks nothing like the sketch. What matters is the asymmetry: the student reads the C without effort, and a PhD with twenty years of experience cannot tell you what the assembly does unless compilers are their specialty. That is not a provocative claim… it is the ordinary condition of the industry… and has been for decades.
The key is that nobody minds. We accepted total illegibility at the layer below, permanently, and not one person experiences it as a loss!
Why two complaints about AI-generated code dissolve
Maintainability of code nobody understands dissolved because nobody maintains it… you maintain the source code, not the ASM. The generated artifact is regenerated, not repaired, and no one even asks if anyone understands it. Which is why nobody has ever inherited 309,000 lines of unmaintainable compiler output from a departed colleague. That failure mode requires the generated artifact to be the thing of record, and for compiled languages that stopped decades ago. The complaint was not solved… it was made irrelevant by moving the artifact of record up one level.
That gives you the sharpest available test of where AI tooling actually stands. Right now, the AI-generated code is what you version, review, and maintain, and you throw away the prompt. That is the exact inverse of a compiler relationship. When teams start maintaining the specification and regenerating the implementation from it, the transition has happened. Watch for that, not for benchmark scores!
Review overhead went the same way, and the mechanism is worth being precise about. It did not go away because review got faster… it went away because review stopped! What every abstraction layer actually purchased was never accuracy, it was permission to stop looking, and that permission was earned with a specification, decades of test surface, and failures that reproduced when you hit them.
The AI Parallels
Language models have none of those things yet, which is the honest core of the objection. Same prompt, different output. No specification of what the input language means. Some of that overstates the compiler side, since undefined behavior means the C standard explicitly declines to specify large classes of program behavior, and changing optimization levels can break code that appeared to work. But mostly it stands. Trust was always the deliverable and determinism was just the mechanism that happened to be available. A different mechanism has to be built, and it will look like verification and property checking rather than inspection.
Here is the part that should get your attention. METR started a second experiment in August 2025 with 57 developers across 143 repositories and more than 800 tasks, and then announced in February 2026 that they were redesigning it, because a significant number of developers declined to participate at all rather than work without AI, and 30 to 50 percent of those who did participate said they were withholding tasks they did not want to do unassisted. METR’s own read is that developers are likely more sped up now than their 2025 estimate suggested, though selection effects make the size of that change weak evidence.
The study did not just find a different number… its methodology stopped working because people would not give the tool up! That is the adoption curve showing up as a measurement problem, and it took about eighteen months.
The two that do not dissolve
The skill complaint was correct and stays correct. Working developers cannot reason about what the machine does, and this shows up as performance blindness, surprise at undefined behavior, and an inability to debug below the layer they work in. The 1950s priesthood was right that the knowledge would go but they were wrong about how much it would matter. The honest answer is that it mattered less than they predicted and considerably more than zero.
Expect the same shape here: a real loss, absorbed, leaving a residue of problems only the people who kept the old skill can solve. A small cadre will always need to understand C just like a small group still has to understand ASM today. But the bulk of software engineers in the future won’t know a for loop any better than today’s know a processor instruction set.
Security
Security is the one I would not wave off. The compiler parallel exists and it does not run in a reassuring direction. Higher-level languages eliminated entire vulnerability classes, and memory-safe languages eliminated more. They also created new ones the industry took decades to notice. The canonical case is a compiler observing that a memset clearing a key buffer just before that buffer leaves scope is a dead store, and removing it, leaving the secret sitting in memory. Correct by the standard… correct by inspection… but wrong in the binary. It has its own entry in the CWE catalog as CWE-14, and the fix was to add functions the compiler is forbidden to optimize away.
So the accurate statement is not that abstraction improves security. It is that abstraction changes which failures are possible. It deletes some categories wholesale, and introduces others that are harder to see precisely because the abstraction is working. Expect AI-generated code to follow that pattern rather than to be simply better or simply worse.
Maintenance
The maintainer-burnout problem sits alongside this and is not going away on its own either. Ghostty has banned AI-generated code outright, tldraw now auto-closes external pull requests, and curl ended its bug bounty after AI-generated submissions reached 20 percent of the total. Compilers never generated a review load the ecosystem could not absorb. This does, and that is a genuine disanalogy rather than a temporary inconvenience.
What already stopped being a problem in nine months
The state of the art tools are advancing at a ridiculous rate. I wrote up my working practices for LLMs in embedded development in late 2025 and a meaningful fraction of it is already obsolete.
In November 2025, forcing the model to build its own output was a hard requirement. You had to construct the workflow so it could not simply assert that code compiled, because it would make that assertion, and it would be wrong. But that is default model behavior now. The same goes for maintaining external context files which was necessary because the tools had no durable memory of their own. Now they all have multiple ways to store and feed persistent context.
Both were workarounds for model limitations and both evaporated. What survived is the part that was never about the model: self-instrumentation and log analysis, which I still use every day. Describing a failure mode, having a system instrumented to expose the relevant signals, and feeding tens of thousands of log lines back for trend analysis is as useful now as it was then.
That split is this article in miniature. The techniques that existed to compensate for what the tool could not do died on schedule. The techniques that encoded engineering judgment about what to measure and what a failure looks like did not, because the judgment was never the model’s to supply. If you want a heuristic for which of your current practices will still be useful in a year, that is the one I would use.
The job when coding is commoditized
Nobody has to decide what the compiler emits… but somebody still has to decide what the program should do.
That is where the work goes. Writing a specification precise enough to compile is programming. It is programming in a language with a fuzzier grammar and a stochastic backend, but the cognitive labor is the same: decompose the problem, define the interfaces, enumerate the edge cases, and decide what happens when things fail. This transition will be brutal for people whose value was fluency and mild for people whose value was judgment.
Verification becomes a critical in-line piece rather than a phase at the end. If you are not reading the output, something else has to establish that it is right. That something has to be designed by someone who knows which invariants must hold and which failure modes are worth engineering against. Cheap code means more code, and more code means more surface area for the failure nobody considered.
There will be escape hatch work permanently, because there always has been. Inline assembly never went away… it just lives in startup code, interrupt vectors, context switches, cycle-exact timing, and errata workarounds. That fraction is larger in embedded software than elsewhere, because half the specification lives in the hardware and the hardware is not in the repository. A model reading a web service can see nearly everything that determines correct behavior. A model reading firmware cannot see the timing relationship, the errata, or the peripheral that ignores its own datasheet.
In Conclusion
AI-generated code will end up like assembly: unread, not understood, and not missed. That happens on one condition, which is that the specification and verification layer around it matures the way the one around C did. It has not yet… but building it is the interesting engineering problem of the next decade, and a considerably better use of anyone’s time than arguing about whether the tools are good enough today.
In the projects we get called into, the bottleneck usually turns out not to be the model, it is that the requirements and test coverage were never precise enough to hand to anything, human or machine. If that sounds like your project, get in touch through Getting Started and we will work through where your specification and verification gaps actually are.
FAQ
Is AI-generated code just the next layer of compiler output?
Functionally a compiler and a code-generating model solve the same problem, turning a human description of intent into machine-executable code. The difference is that a compiler has a specified input grammar and reproducible output, while a model accepts ambiguous natural language and can produce different results from identical input. The comparison is a claim about trajectory and about which problem is being solved, not a claim that the two are equivalent today.
How do you maintain AI-generated code that nobody on the team understands?
Today you maintain it like anything else, which is the problem, because the person maintaining it did not write it and cannot reconstruct the reasoning. The structural fix is to move the artifact of record so you maintain the specification and regenerate the implementation rather than patching output. That only works once verification is strong enough to make regeneration safe, which is the precondition most teams have not met.
Does AI-generated code introduce security vulnerabilities?
It changes which vulnerabilities are possible rather than simply adding or removing them. Moving up an abstraction layer has historically deleted entire defect categories while creating new ones that were harder to spot, such as compilers optimizing away a memset intended to clear sensitive data. Treat AI-generated code as needing security review against your threat model rather than assuming the abstraction protects you.
How do you review AI-generated code without reading every line?
You replace inspection with verification, which means defining tests and invariants before generating the implementation rather than after. On embedded targets that also means instrumentation, since a host-side test suite tells you much less than you want about behavior on real hardware. The practical test is whether you can state what correct means independently of the code, because if you cannot, review is your only tool and it will not scale.
Will AI coding tools stop junior engineers from learning to code?
They will change what junior engineers learn, the way compilers produced a generation of competent people who cannot read assembly. Something real is lost and it surfaces later as difficulty debugging below the abstraction. The skills worth deliberately building now are specification, verification, and system-level reasoning, because those are the parts that do not compress when code generation gets cheap.
