AI adoption leaves teams with a review bill

In Stack Overflow's 2025 survey, 84% of respondents used AI tools or planned to use them. Only 3% reported highly trusting their output.

The difference leaves teams with a review problem: widespread use can produce more drafts than developers are prepared to accept without checking.

Read the survey categories precisely

The 84% figure combines current use with plans to adopt AI tools. Among professional developers, 51% reported daily use. These categories describe different levels of adoption.

On accuracy, 33% trusted AI output, while 46% distrusted it. The most common frustration concerned solutions that were almost correct; 66% selected that response. These figures describe respondents' assessments of the tools they used.

Debugging generated code was another reported frustration: 45% selected it as more time-consuming.

Those responses give teams a reason to measure review time alongside generation. The survey alone cannot determine which part of a particular team's process is failing.

Plausible code can conceal a defect

An obvious error is often easier to reject. The cost begins with the time needed to recognize it, then produce a replacement.

A less obvious error can survive review when the main path works. Familiar naming can make the implementation look consistent with the codebase, even if an untested edge case will fail later. By then, the reviewer may have lost the context needed to diagnose it quickly.

I lost an afternoon to a generated data table that included plausible tests. It looked finished until an edge case broke pagination. The apparent saving during the first hour became debugging work for the rest of the day.

METR's study of experienced developers found slower completion on its realistic tasks with AI assistance, despite participants expecting a speedup. The result concerns that study's conditions. It gives a team a reason to measure completed work instead of estimating productivity from how fast generation feels.

Assign generation tasks with review in mind

Give the assistant work whose assumptions a reviewer can inspect.

An assistant can draft scaffolding or test skeletons. It can also explain unfamiliar code before a developer checks that explanation. System boundaries require more application context; decisions about concurrency or the data model need someone who understands their consequences.

Use generation for drafts that have explicit constraints. Keep responsibility for the application's invariants with the team.

Put checks around generated changes.

Throughput depends on how the review process handles the extra code. A team needs to know which checks run before a generated change reaches a person:

• Write acceptance tests before generation when the expected behavior is known. They can expose an almost-correct implementation before manual review.
• Supply architecture notes with the relevant API contracts. Existing examples can show how the repository handles the same task. Missing context is one possible source of bad output.
• Keep generated pull requests small enough to inspect. Label their origin if the team needs that information to compare outcomes.
• Automate repeatable checks. Static analysis can inspect patterns that a reviewer might skim; dependency checks can cover licence requirements. Duplication detection needs its own check.

Reports of increased duplication or churn give teams specific behaviors to look for. Local measurements are needed to establish whether generated changes are producing them in the repository.

Record the context a model lacks.

Problem framing depends on the application. Integration decisions need that context too. Performance constraints depend on the application, as do security requirements. A developer needs enough context to choose between plausible implementations for that particular team.

Record recurring decisions in repository instructions. Documented patterns give later drafts a concrete reference, while review checklists keep acceptance requirements visible. Existing examples help only when they reflect the standards the team actually wants to apply.

Check where work waits

If review has become the bottleneck, generating more code adds to its queue. Measure that waiting time before increasing the amount of generated work.

The following questions can locate the work that needs attention:

• Can the team distinguish AI-drafted changes in its merged history? That information is needed to compare their defect rates with other changes.
• Has review capacity changed with the volume of submissions? If submissions doubled while review stayed the same, measure the resulting queue.
• How much senior-developer time goes into design? Compare it with time spent repairing generated drafts to see where that effort is going.

Count the repair time

The survey describes adoption alongside reported distrust. It leaves the cost of each team's review process to be measured in that team's work. Debugging belongs in the result even when generation was quick.

A team can judge its setup by following drafts through to accepted software. The person designing that process needs to account for the defects reviewers find after the first plausible answer.

I help teams measure AI's effect on engineering work, then examine the review process behind the result. That can require architectural decisions whose cost becomes apparent only later.

Source: Stack Overflow Developer Survey