Who Reviews the Machine

A small team starts using AI coding tools, and work that had been waiting for months begins to move. Changes arrive faster. The demos look good. It feels as though the team has found some of the time it was missing.

Then more of those changes start waiting for review. The experienced engineer who understands the system spends less time improving it and more time checking what everyone else has produced.

The tools may be helping. The team also has a new question to answer: who has time to check the additional work?

Part 3 looked at engineers stretched across support, testing, incidents, and planned development. AI can help with parts of that workload. It doesn't automatically create room for the decisions and checks that come before a release.

Writing code is one part of delivery. Someone still needs to understand the requirement, check how the change fits the existing system, and decide whether it is ready for customers. AI can assist with those tasks too, but the team needs to know how well that assistance works.

DORA's analysis of responses from 1,110 Google engineers describes this shift: some developers reported spending time saved writing code on checking the results. That is useful context for a small team where the same people are already handling several responsibilities. DORA, Balancing AI tensions.

A study of open-source projects after Copilot's introduction found that core contributors reviewed 6.5% more code while their own original code productivity fell 19%. Much of the additional output came from peripheral contributors, with more rework falling on the core team. These are contributor roles in open-source projects, but the finding raises a relevant question: who is doing the extra work after the code is written? GenAI as a Coding Partner.

Faros found a similar tension in data from 22,000 developers using its platform. Comparing periods of lower and higher AI adoption within organizations, it reported roughly 34% more completed tasks per developer alongside a more than fivefold increase in median elapsed time in review. Those are observations from its customers, not a forecast for every team. They are a reason to look beyond how much code gets produced. Faros, The Acceleration Whiplash.

Code can be neatly written and still misunderstand a requirement. A reviewer needs enough context to notice that an invoice can be paid twice, an account can see another account's data, or a failed operation leaves the system in the wrong state. Formatting alone won't reveal those problems.

On a six-person team, fifteen proposed changes waiting for one reviewer can become a serious delay. People start asking whether a passing test run is enough to release. The reviewer feels pressure to move faster, while the rest of the team keeps starting new work.

That is worth addressing before it becomes the normal way the team operates.

It also changes the hiring discussion. Faster code generation doesn't make engineers interchangeable. Someone new to the profession, or simply new to this system, may need help recognizing the assumptions that deserve checking.

Junior engineers can contribute with these tools and learn from them. They still need opportunities to explain their choices, investigate failures, and work through unfamiliar problems with someone more experienced. Plan for that time when deciding how much work the team can take on.

Anthropic's randomized study illustrates why the learning process matters. Among 52 mostly junior engineers learning an unfamiliar Python library, the AI-assisted group averaged 50% on a follow-up quiz, compared with 67% without assistance. Debugging showed the largest gap. This was a short study of learning something new, and how participants used the tool mattered. It supports checking understanding rather than assuming that completing the task means someone has learned it. Anthropic, How AI assistance impacts the formation of coding skills.

The practical concern is a hiring plan that assumes more generated code removes the need for experience. If one engineer already reviews most changes, adding people who need their guidance can increase that workload. A junior hire may still be the right decision, provided the team makes room for coaching and review.

The same care applies to generated tests.

A test is useful because of the behavior it checks. If the tool writes both the implementation and the tests, the tests may repeat an assumption that was wrong in the first place. The same problem can occur in human-written tests. Someone needs to compare the expected result with what the business or customer actually needs.

VibeCheck, a small exploratory study of generated tests for fifteen student projects, found examples that ran successfully while missing important checks. In one case, a test could pass even when the expected error never occurred. That is a concrete reason to read what a test verifies. VibeCheck.

Security needs its own checks as well. Veracode's spring 2026 benchmark found that improvements in code that compiles had outpaced improvements in security. Results varied by model, and generated code still needed security checks. Veracode, Spring 2026 code security update.

I would spend the first week looking at the work waiting for review and a sample of what recently shipped:

1. Look at the size and age of proposed changes. For open pull requests, note when they became ready, when someone first reviewed them, and what is keeping them open. Distinguish time spent waiting from time spent actively reviewing. Several days in a queue doesn't mean several days of a reviewer's effort.

2. Find out who carries the review work. How much lands on one person, and what are they postponing to do it? A fall in that person's code contributions may reflect necessary review and mentoring. Count that work before drawing conclusions about their productivity.

3. Check how changes get approved. Review the last thirty days of merges. Which received human review, which had only automated checks, and which followed an exception? Ask whether people agree on what needs review and who is responsible for it.

4. Read the tests against the requirement. Choose a handful of important changes and check what the tests actually establish. Do they verify the expected result, rejected actions, and relevant failure cases? For a critical rule, deliberately introduce an error in a test environment and check that the test catches it.

5. Review incidents, rework, and repeated code. Compare similar periods before and after the tools were introduced, allowing for changes in release volume and the work being done. Look at specific failures and examples of duplicated logic. A rising count is a reason to investigate; it doesn't establish the cause by itself.

6. Ask how the tools are being used. Who checks generated code before requesting review? Can the person submitting it explain the change and its limits? Is there a shared agreement about what an agent may change or merge, or does every engineer have a different understanding?

It is also worth comparing the team's impression of speed with actual task and delivery times. In METR's early-2025 trial, sixteen experienced open-source developers took 19% longer with the available AI tools, despite believing they had become faster. Its 2026 follow-up suggested the tools were becoming more helpful, but selection and measurement problems made the size of the gain uncertain. The lesson for a small team is to measure its own experience as the tools change. METR's original trial, 2026 follow-up.

For the first two weeks, use what you learn to reduce the work waiting for review and make the checks more dependable.

Start with the checks that can run automatically. Tests, code checks, and security scans should give the author useful feedback before someone else begins reviewing. Define important expected behavior from the requirement, then check that the tests cover it. For invoice payments, that includes what should happen if a customer tries to pay twice or the payment fails partway through.

These checks can catch problems early. They don't cover everything a reviewer needs to consider, and the reviewer should know what remains to be checked.

Ask for smaller, coherent changes. Splitting a large task into useful steps can make each one easier to understand, test, and release. A line-count limit can prompt that conversation, but dividing a change into arbitrary pieces won't necessarily help. The author should explain what each step does and how it fits the larger job.

For this initial reset, I would require a second person's review of production code changes, with clear arrangements for urgent fixes. The person submitting a change should be able to explain why it is needed, how it works, and what they checked. A description generated by a tool can be a starting point; the author still needs to understand and stand behind it.

Share review according to knowledge and risk. Give the people who understand payments, permissions, data changes, or important connections between systems enough time to review those areas. Other changes can go to colleagues familiar with the work. Pairing on reviews helps more people build that knowledge, so the team gradually depends less on one person.

An AI review tool may help with this process. Check which useful problems it catches, which it misses, and whether its suggestions reduce the work left for people. More automated comments aren't, by themselves, evidence of a better review.

Then decide where additional time or staffing would help. The answer might be testing expertise, another experienced engineer, better automated checks, or relief from the support duties described in Part 3. Make that decision from the workload you found. Buying more tool access doesn't address every kind of delay, and neither does a particular job title.

At the end of two weeks, look at whether changes wait less, whether authors can explain them, and whether reviewers have time for careful work. Keep checking what happens after release. A shorter review queue is useful only if the team is still finding and fixing the problems that matter.

Across these four pieces, the recurring issue has been work the delivery plan didn't fully account for: navigating a difficult system, choosing the right improvements, handling daily requests, and checking what gets built.

AI changes how some of that work gets done. The team still needs a realistic plan for all of it, including who will understand the next change well enough to approve it.

The next piece, The First 30 Days, brings those investigations together into one month of work.

Related service: Team Turnaround