4 min read
Software teams spent years trying to shorten the time between an idea and a first implementation.
Coding agents changed that part of the system quickly. A plausible first draft can now appear before a planning meeting
would have ended. Several agents can work in parallel. Tests, documentation, and review summaries can arrive with the
code.
The obvious conclusion is that delivery should become faster by the same amount.
That conclusion misses the queue.
When generation becomes abundant, the scarce work moves to deciding whether the generated change is the right change,
whether its evidence is meaningful, and whether the team can safely own it.
The new queue begins after the answer
Stack Overflow’s 2025 Developer Survey gives this problem recognisable language. Among respondents who answered the AI
frustration question, 66% selected solutions that were almost right, and 45% selected more time spent debugging
AI-generated code.
These are self-reported survey responses. They do not prove that AI slows every team or that every generated change is
wrong. They show why the first answer is a weak unit of productivity.
Almost-right code is expensive because it looks familiar. It follows local naming. It may pass a quick test. It can
explain itself clearly. The reviewer must now detect the missing requirement, the unapproved assumption, the weak test,
or the boundary that moved.
The code was cheap to produce. The proof did not become cheap automatically.
Why ordinary review stops scaling
Traditional code review benefited from a useful speed difference. A reviewer could often read changes faster than
another developer could create them. The writing rate limited the queue.
Agents can reverse that relationship. One engineer can initiate several changes while the same small group of senior
people still owns architecture, security, product consistency, and production risk.
The result is not simply “more code to review.” It is more decisions hidden inside code:
- Which existing component should have been reused?
- Which interpretation of an unclear requirement became the implementation?
- Which dependency was selected and why?
- Which test was derived from the specification, and which merely mirrors the code?
- Which documentation became stale?
- Which finding is deterministic and which is model judgement?
If every reviewer starts from a diff and a confident summary, the queue will grow faster than the team can hire.
Redesign review around evidence
The answer is not to remove the human or require them to inspect every generated token.
The answer is to change what reaches the human.
Start with a stable target
Write observable behaviour, important invariants, and proof methods before implementation. A reviewer should be able to
compare the change with an approved target instead of reconstructing the request from code.
Separate maker and checker
The agent that implemented the change already carries its assumptions. Give a separate reviewer the specification,
diff, check results, and a clear job: find unproven promises, unwanted behaviour, and boundary violations.
Let scripts prove scriptable facts
Tests, types, lint, builds, schemas, package existence, file drift, and architecture rules can produce recorded results.
A model can interpret them, but it should not invent whether they passed.
Route review by risk
A copy change should not wait behind an access-control change with the same workflow. Use a light path for small,
reversible work and stronger specification, specialist review, and human decisions for sensitive changes.
Give the human a verdict packet
The final reviewer needs the promised behaviour, changed scope, deterministic results, judgement-based findings, open
uncertainty, decisions already made, and rollback information. They do not need the full transcript.
Measure the whole path
Generated lines and opened pull requests show activity. They do not show whether the queue improved.
Measure:
- time to accepted change;
- review time per accepted change;
- correction turns before acceptance;
- escaped defects;
- requirements without evidence;
- unrequested changed behaviour;
- documentation drift;
- changes a reviewer returns as inconclusive;
- team understanding of the affected area.
This is how a team learns whether AI created useful capacity or only moved work into a less visible queue.
Where paqad-ai fits
paqad-ai is designed around the whole feature-development path: risk routing, planning, specification, scoped
implementation, separate review, deterministic checks, documentation sync, human decision pauses, and a durable
evidence record.
It does not remove judgement. It prepares judgement.
The model can think and type. The workflow decides how work moves. Checks record what can be proven. A named human owns
the consequential verdict.
That is the change teams need when the first draft is no longer the bottleneck.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Stack Overflow Developer Survey 2025, AI, self-reported survey data on
trust and common frustrations. - Addy Osmani, Agentic Code Review, current practitioner analysis
of review as scarce work.
