When AI-built software breaks.
AI-built software does not break randomly. It breaks in a small number of recurring shapes. AI writes fluent code, and fluency is not correctness: the code reads right and runs in the demo, then fails in the one path nobody forced open. These are the shapes we keep finding, in our own code and in the projects people hand us to fix. Each one is a note: a real bug, the investigation, and the public commit that closed it.
The shapes it breaks in
- 01
The silent break
It passes every test and is still wrong.
The code does what the test imagined, not what the user needs. If the test drives a mock entry point and checks that the parts exist rather than that the right thing happened, it stays green while the product is broken. Green is a fact about your test, not your software.
Read the full note - 02
The confident misconfiguration
It runs, so it looks configured. It runs wrong.
Setup code that reads as correct and quietly defeats itself: a worker that never actually threads, a cache that never actually clears. It does not error, so nobody looks twice. The expensive bugs are the ones that run.
Read the full note - 03
The wrong frame
Fluent reasoning, aimed at the wrong problem.
When the mental model underneath is wrong, more AI reasoning does not help. It produces more convincing wrong answers, faster, fixing symptom after symptom of a cause it never names. This is the most dangerous property of AI coding: it is persuasive in the wrong direction.
Read the full note - 04
The debt at typing speed
AI writes code at the speed of typing, and debt at the same speed.
The thousand-line file, the dead code regenerated on every prompt, the abstraction nobody chose. It ships fast and reads fine until someone has to change it. The bill comes later, and it is paid in refactors.
Read the full note - 05
The hole in the boring place
The risk hides where people stop reviewing.
Not in the auth flow everyone scrutinizes, but in the toast, the loader, the helper that just shows a message. That is exactly where an unescaped string or an unsafe default survives, because it looked too small to check.
Read the full note
The notes
Three crashes, three patches, one cause none of them named.
Three separate crashes got three separate guards. Every guard held. None of them was the bug. Here is the commit that finally named it.
The canvas rendered once. The phone threw it away.
On mobile, a page you had already viewed went blank when you scrolled back to it. The canvas was fine. The phone had quietly reclaimed its memory. Here is the commit.
One feature looked broken. Nothing had initialized.
Signature upload did nothing. The real problem was that the whole app never started, because a DOMContentLoaded listener was attached after the event had already fired. Here is the commit.
Can you trust AI-generated code?
Fluent is not the same as correct, and they look identical on screen. Here is where to point the distrust, drawn from the bugs we found in our own AI-built code.
How to tell if your software was built too fast.
Rushed software runs and demos well, then breaks in a handful of recognizable ways. The tells, each one a real shape we found cleaning up our own code.
The tool that passed every test and was quietly broken
A file-replace flow rendered a blank page for weeks. The tests were green the whole time. Here is why, with the commits.
Your tool isn't slow. It's misconfigured.
PDF.js ran on the main thread for two months because one helpful-looking line disabled the very thing it looked like it enabled. Here is the commit.
What it costs to unbuild what an AI wrote.
An AI grew one file to 3,634 lines. Taking it back apart, and deleting the two thousand dead lines it left behind, is the bill nobody quotes up front. Here are the commits.
The security hole an AI left in a helper function.
A filename rendered straight into the page through a toast message. It was AI-written, it just showed a message, and nobody reviewed it. Here is the commit that closed the XSS.
Why does AI-generated code work in the demo but break in production?
The demo is the path the AI optimized for. AI-written code and its AI-written tests both describe the happy path, so they agree with each other and can be wrong in the same direction. The break lives in the path nobody exercised: the real entry point, the second file, the input the demo never sent.
What are the most common ways AI-built software fails?
A small set of recurring shapes: silent breaks that pass every test, confident misconfigurations that run but run wrong, wrong-frame bugs where fluent reasoning fixes the wrong problem, debt from code written at typing speed, and security holes hidden in the boring helper functions nobody reviews.
Is AI-generated code reliable?
It is fluent, which is not the same as reliable. It reliably produces something that looks right and usually runs. Whether it does the right thing depends on whether anyone tested the real path and read the parts that just work. Reliability is a property you add by reviewing, not one the fluency hands you.
How is fixing AI-generated code different from ordinary debugging?
The failures are quieter. There is usually no crash and no red test. The skill is knowing which green lights to distrust, and recognizing the recurring shapes, instead of chasing each symptom as though it were new.