Coding agents changed the bottleneck.
For a long time, the bottleneck was writing code. Now, in many workflows, the bottleneck is reviewing what the agent did.
That sounds like a small difference. It is not.
When a coding agent works well, it can touch dozens of files, run tests, chase errors, update dependencies, and produce a branch in minutes. The human then has to answer the uncomfortable question:
Do I actually understand this change well enough to merge it?
That is where the fatigue shows up.
Agentic Coding Is Not Autocomplete
Autocomplete keeps the human in the loop at every token.
Agentic coding moves the human up a level:
- assign a task
- wait
- inspect a diff
- check tests
- ask for revisions
- decide whether to merge
This is closer to reviewing a junior developer who works at impossible speed. The output can be useful, but the review burden is real.
Why Review Gets Hard
1. The Diff Is Larger Than The Intent
A small request can produce a large diff.
Sometimes that is appropriate. Sometimes it is abstraction drift. Sometimes it is a test rewrite hiding a behavior change.
The human has to separate:
- necessary change
- incidental cleanup
- style churn
- generated noise
- actual bug
That takes attention.
2. The Agent Can Be Locally Correct And Globally Wrong
Agents are good at making a test pass. They are less reliable at preserving the unwritten contracts of a codebase.
Examples:
- changes a public API because it simplifies the patch
- fixes one provider path but breaks another
- introduces a helper that does not fit local patterns
- updates snapshots without understanding the UI
- catches an exception too broadly
The code compiles. The tests pass. The product is still worse.
3. Velocity Creates Psychological Pressure
When agents can produce branches quickly, every hour not spent merging can feel like falling behind.
That pressure is dangerous. It rewards shallow review.
Good engineering teams will need cultural norms around agent output:
- small branches
- clear task boundaries
- no unrelated refactors
- tests tied to the bug
- human-owned merge decisions
What Good Agentic Coding Workflows Look Like
Use Containers And Branches By Default
Agents should work in isolated branches or worktrees. The human should be able to inspect, test, and throw away work without drama.
Ask For Evidence, Not Confidence
Do not ask the agent, "Are you sure?"
Ask:
- what files changed?
- what behavior changed?
- what tests did you run?
- what did you deliberately not touch?
- what risks remain?
Evidence beats vibes.
Keep Tasks Narrow
The best agent tasks are specific:
- fix this failing test
- add this missing type
- reproduce this bug and patch it
- update this endpoint to support this field
The worst tasks are vague:
- improve the codebase
- make this production-ready
- refactor this module
Agents can do those too. But the review cost explodes.
Build Review Tools For Agent Output
This is an underbuilt category.
We need tools that summarize:
- behavior changes
- risk hotspots
- public API changes
- test coverage delta
- generated-code churn
- dependency changes
- security-sensitive edits
The future of coding agents may depend as much on review UX as model capability.
The Takeaway
Coding agents are not replacing engineering judgment. They are increasing the amount of code that demands it.
That can be a superpower if teams design around review. It can also become a treadmill.
The winning teams will not be the ones that generate the most code. They will be the ones that merge the right code with the least confusion.
Sources Worth Reading
- Hacker News: "Claude Code and the Great Productivity Panic of 2026" https://news.ycombinator.com/item?id=47467922
- Hacker News: "Building Effective AI Agents" https://news.ycombinator.com/item?id=44301809