Your developers are approving code they didn’t write and didn’t read

Here is a hypothetical Thursday. At 4:50 p.m. a pull request lands: 640 lines, most of them written by a coding assistant. It changes how refunds are calculated. The tests are green. The reviewer has two more in the queue and a school pickup at 5:30. She scrolls, spots nothing odd, types “LGTM” and approves.

Three weeks later finance notices that partial refunds have been paid at full value since the release. Nobody was careless, exactly. The assistant wrote plausible code. The tests checked what the assistant thought mattered. The reviewer trusted the tests. Every step looked like diligence. Nobody actually read the code.

The story is made up. The pattern isn’t, and the uncomfortable question at its center is simple: when AI-written code breaks something that matters, whose signature is on it?

01Four in ten review everything. Then what?

In August 2026, BairesDev asked 705 developers what share of the AI-generated code in their current project reaches production without a specific human review of that code. 41% said virtually none. Every AI line gets a human look.¹

That is the good news. Here is the rest of the answer:

• 14% said less than 10% ships unreviewed.
• 12% said 10–25%.
• 12% said 25–50%.
• 6% said 50–75%.
• 4% said more than 75%.
• 11% said they had no visibility into it at all.

Add it up. For roughly half the developers surveyed, some AI-written code goes live without anyone reading it specifically. For one in ten, nobody can tell you either way.

02The volume went up. The reviewers didn’t.

The same survey shows why this is getting harder, not easier. A year ago, 12% of developers said AI wrote at least half their code. In Q3 2026 it was 42%. And 67% said they now spend more time reviewing AI-generated code than they did a year earlier.¹

So the code arrives faster, in bigger pieces, written in a style nobody on the team chose. The reviewer is the same person with the same eight hours. Something has to give. Usually it’s the careful read, and it gives quietly. There is no alert for “approved without reading.”

Leadership has noticed. 78% of the CTOs BairesDev surveyed said they had increased spending on code review, QA and validation to support AI-generated work.¹ That money only helps if it lands on the code that can hurt you.

03A button color is not a refund

The instinctive fix is a blanket rule: every line of AI code gets a full human review. It sounds safe. It won’t survive the first deadline. Teams will route around it, and you’ll have the rule on paper and nothing behind it, which is worse than an honest exception.

A better approach is to admit that code isn’t equally dangerous and draw the line on purpose.

Can ship on tests and automated checks: layout and styling. Copy changes. Internal dashboards with no production data. Test scaffolding. Prototypes that will be thrown away. If these break, someone notices, files a ticket and fixes it. Annoying, not expensive.

Never ships without a named person who read it:

• Money. Pricing, refunds, invoicing, payouts, anything with a currency field.
• Personal data. Anything that reads, stores, exports or logs customer, student, patient or employee records.
• Access. Login, session handling, password reset, roles, permissions, API keys, encryption.
• The public record. Anything that files with a regulator, publishes to citizens or writes to an official system.

The test is blunt. What does a mistake cost, and who pays for it? A wrong shade of blue costs a ticket. A wrong permission check can cost a breach notice, and the people who pay for that aren’t on your team. They’re your customers.

04“LGTM” is not a review

The hardest part isn’t drawing the line. It’s making the line hold on a Thursday at 4:50 p.m. A rule in a wiki is a suggestion. These are controls:

• Code owners on the dangerous folders. Changes to payments, auth and data-access code need approval from a named owner, not whoever is free.
• A size cap where it counts. Nobody reads 640 lines properly. Keep changes to sensitive paths small enough that a real read is possible in one sitting.
• Say what you checked. Ask the approver for one line: “Read the refund calculation, checked partial amounts and rounding.” It takes thirty seconds and changes behavior more than any policy.
• Tag AI-assisted changes. If you can’t say what share of your AI code gets reviewed, you’re in the 11%. Tagging is how you find out.

05The signature is still yours

When the refund bug surfaces, nobody will ask which model wrote the code. They’ll open the pull request and look at the approval. The tool doesn’t carry accountability. The person who clicked the button does, and so does the leader who set up a process where clicking without reading was the easy option.

That isn’t an argument against AI-written code. Most of it is fine, and much of it is good. It’s an argument for deciding, before the next release, which code you will never let through unread.

06What to do Monday

1. List your “never unread” paths. Thirty minutes with your lead engineers: the folders and services that handle money, personal data and access. Write them down.
2. Put code owners on them. Most code platforms support this out of the box. Name a person, not a team.
3. Ask one question in your next stand-up: “Of the AI-assisted changes we shipped last month, which touched those paths, and who read them?” If nobody can answer, that’s your baseline.

The refund story is invented. Make sure it stays that way.