AI coding slows down when review becomes the product

Nolan Lawson’s post argues against the default framing of AI coding as a race to produce more code faster. The more interesting use case is slower: ask LLMs to inspect pull requests, compare findings across models, and let humans decide which issues are real. In that workflow, the gain is not raw output. It is earlier detection of defects, missing tests, accessibility problems, and architectural drift.

The suggested pattern is deliberately redundant. A team can run several reviewers over the same change, such as a Claude sub-agent, Codex, and Cursor Bugbot, then synthesize the findings into one human-reviewed report. The point is not to accept every model complaint. It is to use disagreement and overlap as a filter. If multiple systems find the same failure mode, it deserves attention. If one model invents a problem, the human review step should catch it.

The Hacker News discussion added practical texture. Some developers described a workflow where they first talk through architecture, turn that into a spec, implement against smaller tasks, and then ask separate model sessions to inspect error handling, concurrency, and edge cases. Others pushed back that agentic coding can erase the small design decisions programmers normally make while writing. That objection matters: a tool that reaches the goal too eagerly can still leave maintainers with low confidence in how the code fits the project.

The takeaway is to split “AI coding” into distinct jobs. Drafting code, reviewing code, designing tests, checking security, and challenging architecture are not the same task. Models may be mediocre at autonomous end-to-end implementation while still being useful at targeted critique. Slower loops can look inefficient in the moment, but they make the cost visible before defects reach production.

Source: Nolan Lawson’s post. Community context: Hacker News discussion.