AI writes more of the code now. Reviewing it is the job.

A year ago the question was whether to use AI for coding at all. That argument is over. Agents now open files, run tests and propose whole pull requests, and most developers use them every week. The new question is harder: if a machine writes the first draft of most of your code, how do you stay confident in what you ship?

My answer is that the job has moved. Writing code is no longer the slow part. Reading it, testing it and deciding whether it is right is. This post covers what the research says and the workflow I use on client projects.

What the numbers say

Adoption is close to universal. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools. Google's 2025 DORA report found AI adoption at 90% among software professionals.

Trust has gone the other way. In the same Stack Overflow survey, more developers distrust the accuracy of AI output (46%) than trust it (33%), and only 3% say they highly trust it. The most common complaint, picked by 66% of respondents, was 'AI solutions that are almost right, but not quite.'

Speed is also less clear than it feels. In a July 2025 randomised trial, METR gave 16 experienced open-source developers 246 real tasks in codebases they knew well. With AI tools allowed, tasks took 19% longer. The developers had expected a 24% speed-up, and even afterwards they believed AI had made them about 20% faster.

That study used early-2025 tools, and METR said in February 2026 that developers are probably sped up more now. They also said their newer data is only weak evidence of how much, because developers increasingly refused to work without AI. The takeaway is not that AI makes you slower. It is that it is easy to feel fast while the real time goes somewhere you don't notice: reviewing, fixing and re-explaining.

AI amplifies whatever is already there

The most useful finding comes from DORA. Their 2025 report describes AI as an amplifier. Teams with good habits get better, and teams with weak ones see their problems grow. AI adoption is now linked to higher delivery throughput, but also to more instability.

Two of the capabilities DORA says separate the teams that benefit are working in small batches and strong version control. Both are about review. If an agent drops a 900-line change on you, nobody reads it properly. If it hands you 80 lines with a test, you can.

'Almost right' is the real risk

Obviously broken code is easy to catch. It fails to compile, the test goes red, the page crashes. Almost-right code passes a quick look and fails in production. The patterns I see most often in AI-written changes:

• The happy path works but empty, missing or duplicate data breaks it.
• A check is done in the UI but not on the server, so anyone can call the API directly.
• A new dependency appears to solve something the codebase already handles.
• Tests that repeat what the code does instead of checking what it should do, so they pass by definition.
• A quiet change to something the task never mentioned, like a renamed field or a relaxed type.

None of this is exotic. It is what a rushed junior developer would do. The difference is volume: an agent can produce it faster than anyone can review it.

The workflow I use

1. 1Write the outcome before the prompt. Two or three sentences on what should be true when the change is done, including the edge cases. If I can't write that, the agent can't build it.
2. 2Keep project rules in the repository. Agents read files like AGENTS.md at the root of the project. That's where I put the stack, the conventions and the things not to touch. This site has one. It tells agents to read the installed Next.js docs before writing code, because the framework changed after most models were trained.
3. 3Ask for small, reviewable steps. One feature, one change, one pull request. If a change is too big to review in fifteen minutes, I split it.
4. 4Have the test written first, and read it before the code. A test that states the expected behaviour is the cheapest spec there is. If the test is wrong, the code will be confidently wrong too.
5. 5Review the diff, not the explanation. The agent's summary tells you what it meant to do. The diff tells you what it did. Deleted lines deserve the most attention.
6. 6Run it for real. Type-checking and tests catch a lot, but I still click through the change in a browser, because that's where 'almost right' shows up.

A review checklist for AI-written changes

• Does it do what was asked, and only that?
• Is every permission check enforced on the server?
• What happens with empty input, a slow network or the same request twice?
• Were any dependencies added, and are they needed and maintained?
• Would the tests fail if the feature broke?
• Could I explain this code to the client without saying 'the AI wrote it'?

The last question matters most. Clients don't pay for code. They pay for someone who stands behind it. AI makes me faster at producing a first draft, but responsibility for the result hasn't moved, and I think that's what good developers will be judged on from now on.