AI coding produced more code, and less checking

AI coding tools clearly make building faster. Checking what was built has not sped up with them. Across 22,000 developers observed over two years, checking did not just slow down — it started getting skipped. This post looks at where that gap comes from, and where each of the three common approaches to ai code testing runs out.

What AI coding tools raised and what they broke

The engineering analytics company Faros AI published its AI Engineering Report 2026 on April 12, 2026, drawing on two years of telemetry from 22,000 developers across 4,000 teams, comparing each organization's lowest and highest periods of AI adoption.

First, what improved.

• Task throughput +33.7%
• Epics completed +66%
• Pull request merge rate +16.2%

Build speed went up, and the numbers say so plainly. The problem is what moved in the same organizations over the same period.

• Median code review time +441.5%
• Pull requests merged with no review at all +31.3%
• Incidents per pull request +242.7%
• Bugs per developer +54%

Build throughput rose while checking broke down in the same organizations

Look at one number again. Pull requests merged with no review rose 31.3%.

That is the line that matters most here. The common framing is that AI turned review into a bottleneck. What the data shows is not a bottleneck. A bottleneck would mean code piling up while it waits. What actually happened is that teams tilted toward shipping without checking.

Checking needs one more input

Why does building get faster while checking does not?

Writing code and checking it do not need the same inputs. Writing needs one thing: what to build. That is exactly what AI coding tools are good at. Checking needs one more — a standard for what counts as the correct state.

• Should the confirmation dialog appear below 30,000 won, or above it?
• Should an expired member be blocked, or routed to a renewal screen?
• Should this item show on the first screen, or only after sign-in?

None of these answers are in the code. Code records what currently happens; it does not record whether that matches intent. The answers live in a policy someone wrote down, or more often only in the head of the person who built it.

Checking requires a standard for what counts as correct, which the code does not contain

So no amount of improvement in AI coding tools makes checking follow automatically. Not because the tools are weak, but because the standard sits outside them.

Three ways people handle ai code testing today

So how do people check today? Broadly, three ways.

1. Click through it yourself

The most accurate. A person looks at the screen and judges it, standard already in their head. The cost is time. A three-minute change takes thirty minutes to verify, and it starts over on every release. That is where the rise in unreviewed merges comes from — not people getting lazy, but volume arriving faster than human pace can absorb.

2. Ask AI to check it too

The natural choice. AI wrote the code, so let AI check it. This is where the standard problem returns. AI can confirm what the code currently does, but it has no basis for judging what it should do. So a passing result arrives without telling you what the pass means.

Keep readingAI Testing Tools: Why AI Can't Test the Code It Just WroteAI testing toolsno-code testing6 min

3. Write test code

The most reliable route, and the right one if you are a developer. Tools like Playwright open a real browser and reproduce what a person would do, and AI can draft that code, so the cost of starting has dropped sharply.

Keep readingWhat Is Playwright MCP? 7 Strengths and 3 Ways to Chooseplaywright mcpplaywright8 min

Two things remain. You have to be able to read and edit code, because the tests move whenever the UI moves. And here too, a person decides what gets checked. The tool checks what it was told.

All three approaches stop at the same place: deciding what to check

All three stop in the same place. Deciding what to check. Do it yourself and it costs time; hand it to AI and there is no standard; move it into test code and someone has to maintain that code.

What this series will cover

This is not something one post settles, so the rest of the series takes it a piece at a time.

• Why deciding what to check stays a person's job — what changes when you separate setting the standard from running the check
• Checks that pass today and fail tomorrow — a check whose result wobbles loses its authority
• What should be left behind when something fails — "it failed" alone fixes nothing
• How we know our own checks actually catch things — a pass rate is not a defense rate

How we see it

Building Specnote, we landed on one conclusion. Separate setting the standard from running the check.

A person decides what gets checked. That judgement cannot be moved. Running the approved checks in a real browser, over and over, is not work a person needs to do. Specnote lists what AI built, a person reviews and approves that list, and only the approved scope runs in a real browser. Reading code is not required, because reading a list of what was built is something the builder can already do.

This does not fit every case. If you can read and edit code, writing tests yourself is more precise. What we aim at is the case where nobody has the time or the person for that.

---

Figures in this post come from the AI Engineering Report 2026 published by Faros AI on April 12, 2026 — two years of telemetry from 22,000 developers across 4,000 teams, comparing each organization's lowest and highest AI adoption periods.