AI Coding Is Not Always Faster. Use It Where Slow Review Pays Off

Updated May 27, 2026. The strongest current signal for this topic is not another model launch. It is a developer argument that went straight to the top of Hacker News on May 26: Nolan Lawson's "Using AI to write better code more slowly." The May 26 Hacker News front page snapshot listed the post with more than 1,100 points and 433 comments, which is a clear demand signal for a narrow but important question: what if the best use of coding agents is not speed, but review?

The short answer is that AI coding can be useful even when it slows a team down. That is not a contradiction. A tool can reduce typing, increase inspection, surface hidden bugs, and still make the calendar time for a pull request longer. The useful decision is not "AI or no AI." It is where to place the tool: generation, review, explanation, test design, or final merge control.

For teams already using coding assistants, this is the moment to stop measuring only how quickly a prompt turns into a diff. Measure how much code is understood, tested, reviewed, and safely merged.

When To Speed Up, When To Slow Down

Use AI for speed when the task is small, familiar, and easy to verify. Use AI for slow review when the task touches architecture, permissions, data migration, security-sensitive paths, or code nobody fully understands.

The practical split looks like this:

Work type	Best AI role	Human gate
Small refactor	Generate first draft or tests	Confirm behavior did not change
Bug fix in known code	Suggest cause and candidate patch	Reproduce, patch, and add regression test
Large generated PR	Review independently before merge	Read the final diff and reject unclear changes
Security or auth path	Ask for failure modes and threat cases	Verify with tests, logs, and owner review
Unfamiliar legacy code	Ask for explanation and diagrams	Confirm against actual code and runtime behavior
High-churn prototype	Generate fast, then throw away bad branches	Keep only what can be maintained

The pattern is consistent: the less you personally understand the change, the more AI belongs on the review side of the workflow rather than the merge side.

Why This Became A Hot Developer Topic

Lawson's post landed because it says the quiet part plainly. Many AI coding demos make the tool look valuable by compressing the visible act of writing code. A prompt goes in, a patch comes out, and the demo ends before the maintenance work starts.

Real development does not end there. Someone has to read the patch, understand the side effects, run tests, handle edge cases, and explain the change six months later. If the generated diff is large enough, the time saved at the keyboard can reappear as review debt.

That point also fits the broader evidence record. METR's early-2025 randomized study found that experienced open-source developers working on familiar mature repositories took longer when AI tools were allowed, even though they expected the opposite. METR later said its newer measurement work became harder to interpret because AI adoption, task selection, and concurrent agent use changed the shape of the experiment. That update matters: it keeps the lesson narrow. The 2025 result does not prove AI coding is always slower, and the 2026 update does not prove it is always faster.

What it suggests is more useful: "faster" depends on task selection, verification cost, prior codebase knowledge, and whether the tool is being used to replace typing or to increase inspection.

Stack Overflow's 2025 survey points in the same direction from a different angle. Developers were using AI heavily, but trust in output accuracy was weak. That is the working condition most teams now live in: useful tools, low trust, high pressure to ship.

The Speed Trap: Counting The Wrong Part Of The Work

The easiest metric to see is time from prompt to code. It is also the least complete metric.

Imagine a developer facing a 700-line AI-generated pull request. The feature works on the happy path. The assistant explains the design convincingly. The branch has tests, but many were written by the same assistant that wrote the implementation. The developer can merge it in an hour or spend a day asking awkward questions.

The quick merge looks productive until a hidden assumption fails in production. The slow review looks inefficient until it catches a permissions bug, a stale cache path, or a migration case that the generated code never considered.

That is the trap. AI can make one part of software development feel almost free while raising the importance of the parts that remain stubbornly human: judgment, ownership, and tradeoff decisions.

The better move is to split the workflow into two clocks:

Draft time: how long it takes to produce a plausible patch.
Confidence time: how long it takes to trust the patch enough to maintain it.

For some tasks, AI reduces both. For others, it reduces draft time and increases confidence time. For the riskiest tasks, the increase is worth paying.

A Slower Review Workflow That Actually Makes Sense

The workflow implied by the popular discussion is not "let the agent code, then believe it." It is closer to adversarial review.

Start with a small enough pull request that a person can still read it. If the agent creates a sprawling diff, cut the task down or ask it to split the change before review begins. Then run independent review passes with different prompts, tools, or models. Do not let the first review result frame the whole discussion. Ask one pass to find correctness bugs, another to look for security and permission mistakes, and another to challenge test coverage.

After that, deduplicate findings. Treat repeated high-severity findings as worth serious attention, but do not blindly accept every warning. AI reviewers can be useful and wrong at the same time. The human job is to prove which is which.

Finally, fix only the issues whose risk justifies the change. A medium edge case that requires a fragile rewrite may not be worth it. A critical path that reveals the design is wrong may mean the right answer is to abandon the branch.

That last option is uncomfortable, but it is real engineering. Sometimes the most valuable AI review is the one that gives a team enough evidence to throw away a tempting patch.

When Slow AI Coding Is Worth The Cost

Slow AI-assisted review is most useful when the code has asymmetric risk. Authentication, authorization, billing, deletion, notification fan-out, import jobs, data exports, migrations, and privacy settings all fit that pattern. A small mistake can reach many users or become hard to reverse.

It is also useful in old code. Legacy systems often have behavior encoded in tests, comments, naming conventions, and forgotten edge cases. An agent can help map the territory, but it can also hallucinate a cleaner design than the code actually has. The safest role is to make the agent explain the existing paths, generate candidate tests, and list failure modes before it writes the fix.

AI can also be useful when a developer is tired. That does not mean the agent should merge code at the end of the day. It means the agent can prepare a review brief, summarize the diff, point to suspicious functions, and leave a cleaner handoff for the next morning.

The common thread is not speed. It is reducing blind spots.

When AI Speed Still Wins

There are plenty of places where a fast coding assistant is the right tool.

Boilerplate, mechanical migrations, test scaffolds, documentation outlines, one-off scripts, and simple UI wiring often benefit from fast generation because the result is easy to inspect. If the failure cost is low and the verification path is short, there is no need to turn every prompt into a tribunal.

The danger is using the same fast path for every change. A generated docs update and a generated authorization change do not deserve the same level of trust. A throwaway prototype and a production payment workflow do not deserve the same review burden.

Teams can keep the speed benefits by naming lanes:

Fast lane: small changes, low blast radius, easy verification.
Review lane: larger changes, unfamiliar code, business-critical paths.
Stop lane: changes the author cannot explain after AI assistance.

That third lane is important. If the person submitting the PR cannot explain what changed, why it changed, and how it fails, the team has not bought productivity. It has borrowed confusion.

The Team Policy Hidden Inside The Debate

This is where GitHub branch protection and required reviews become more than administrative settings. A team that uses AI-generated code needs merge rules that match the new failure mode.

Required status checks can catch obvious regressions. Required pull request reviews can slow down risky merges. Code owners can force sensitive areas through people who understand them. None of those controls prove a patch is correct, but they keep AI-generated confidence from becoming the only gate.

The policy does not need to be hostile to AI. It should be hostile to unclear ownership.

A reasonable rule for small teams is:

AI may draft code, tests, summaries, and review notes.
The PR author owns the final diff, not the model.
High-risk paths need human owner review even if AI reviewers agree.
Generated tests do not count as independent proof unless a human checks what they assert.
Large AI-generated PRs must be split or justified before review.

This makes AI part of the engineering system instead of a shortcut around it.

What To Do Now

If your team already uses coding agents, do not start by banning or celebrating them. Start by classifying the work.

Pick three recent AI-assisted pull requests. For each one, ask whether AI reduced draft time, confidence time, or both. Then look at review comments, test changes, follow-up bug fixes, and whether the author could explain the final design without rereading the chat transcript.

Next, add one slow-review ritual to high-risk changes. Before merge, ask an assistant to produce a failure-mode review and a test-gap review. Then make a human decide which findings are real. Keep the report attached to the PR only when it helps future maintainers; do not bury the team in AI noise.

Finally, protect the fast lane. Do not turn every simple task into a committee process. The point is not to make AI coding painful. The point is to use the tool at the part of the workflow where it actually changes the risk.

The current developer discussion is useful because it breaks the shallow productivity story. AI coding is not one workflow. It is a set of choices about where machine output enters human responsibility.

Sometimes the best AI-assisted code is slower because the team finally looked closely enough to understand it.