Bottom Line Studio
42% of your code is AI-written. Who checked it?
A passing build tells you the code runs. It doesn’t tell you anyone checked what it does. Here’s the review checklist I use on AI-written changes, including the one that got past me.
Passing isn’t checked.
Do any of these sound familiar?
- A 600-line change was approved in four minutes because every test was green.
- You ask who reviewed a change and the honest answer is “the AI wrote it, and I skimmed it.”
- Something broke in production that worked fine on the developer’s laptop.
Developers now say AI writes 42% of the code they commit. Almost all of them say they don’t fully trust it. Only about half always check it before it goes in. That gap is where the expensive surprises live.
The fix isn’t to stop using AI. It’s to know what your checks actually looked at. One of mine looked in the wrong place.
Developers trust AI code less than they ship it
Sonar, which sells code-quality tools, surveyed more than 1,100 professional developers for its 2026 State of Code report (January 2026). Three numbers stand out:
- 42% of the code they commit is AI-generated or AI-assisted.
- 96% don’t fully trust that code.
- 48% always verify it before committing.
The same survey found 38% say reviewing AI code takes more effort than reviewing a colleague’s. It’s a vendor’s survey, so read it with that in mind. But the shape matches what I see: the writing got fast, and the checking didn’t keep up.
My site passed every check and still crashed
My own website is built with an AI coding agent. In August it made a small change to how article images were wired together. The build was clean. The agent’s own checks passed in development mode. I published it.
The live site crashed. The change had created a circular import, two files that each needed the other to load first. In development the order happened to work. In production it didn’t. Nothing in the checks ran the code the way production starts it up, so nothing could have caught it.
Since then, nothing on the site ships until a separate verification pass runs a production build, starts every page the way the live site does, checks the import graph and reviews the changed code for security problems.
Review by what it can reach, not by how big it is
The change wasn’t big. Most review habits scale effort with the size of the diff: long change, careful read; short change, quick approve. AI-written code breaks that habit, because an assistant will happily make a three-line change in the one file everything else depends on.
Wide reach means imports, configuration, authentication, start-up code and package versions. A short change there deserves a line-by-line read. Narrow reach means one screen or one report, where good tests can carry most of the load.
Five questions for every AI-written change
None of these needs you to read every line. All of them need an honest answer before the merge.
- What can it reach that the tests don’t? If it touches imports, config or start-up code, the tests probably aren’t looking there.
- Did it run the way production runs? A production build and a real start-up, not development mode.
- What changed that nobody asked for? Package bumps, lockfile updates, a “small fix” to make a check pass. On my site, an agent once patched a type error outside the scope I gave it. It said so.
- What check would fail if it were wrong? If you can’t name one, nothing was checked. Something just ran.
- Who signs for it, by name? “The team” doesn’t count. Neither does the model.
Each way of reviewing misses something different
Most teams lean on one of three habits. Each catches a different kind of problem, and each has a blind spot.
| Read the diff | Trust the tests | Verify the behavior | |
|---|---|---|---|
| Catches | Logic you can see in the change | Regressions in paths someone tested | What happens when it runs like production |
| Misses | What the change reaches outside the diff | Paths nobody wrote a test for | Anything the check doesn’t look at, so name that too |
| Cost | Scales with diff size | Near zero per change | Minutes per change, set up once |
| Who signs | The reviewer | Nobody, in practice | A named person, on the record |
You want all three. The third is the one most teams skip, and it’s the one that would have caught my miss.
Keep the AI. Add the signature.
I still use an AI agent on my site every week. It writes faster than I do and it’s usually right. What changed is that “usually right” stopped being the standard for shipping. Every change now has a check that looks where production looks, and a person who signs for it.
Passing isn’t checked. Checked means someone can say what the check looked at, and what it would have missed.
What’s the last AI-written change on your team that shipped on a green build alone?