Using AI to Write Better Code More Slowly

The detail most people skip in Nolan Lawson's post is not the argument itself but the specific admission buried inside it: he found himself understanding his own codebase better after slowing down to review AI-generated code than he had when he wrote the equivalent sections himself quickly. That is a strange outcome. The tool that supposedly automates your thinking ended up forcing more of it.

The number behind the claim: how long "slowly" actually takes

Lawson does not frame his post around throughput metrics, but the implicit number in his argument is worth pulling out and examining. The workflow he describes adds a review loop to every AI-generated block. If you treat that loop as overhead, you might assume it costs 20 to 30 percent more time per feature. His actual finding is that it costs more than that, sometimes significantly, but the defect rate on merged code drops enough to make the trade worthwhile over a project's lifetime. The question worth asking: what happens if you double that overhead? If careful review takes 80 percent longer than vibe-coding, the argument for it depends entirely on downstream savings. Bugs found in review cost minutes. Bugs found in production cost hours or days, plus user trust. The math holds, but only if your review is actually catching things, not just adding theater to the process. The thing that breaks this calculation is context. A solo developer shipping a side project has a different failure cost than a team maintaining a production API. Lawson is writing primarily about the former, and that limitation matters when evaluating whether his advice scales.

Where the "write code faster" workflow actually falls apart

The failure mode Lawson is responding to is not imaginary. It has a well-documented shape: a developer uses Cursor or GitHub Copilot to generate a block of code, sees that it looks plausible, accepts it, and moves on. The code works in the happy path. Two weeks later, an edge case surfaces that the model never considered because the prompt never mentioned it. This is not a critique of any specific tool. It is a critique of the workflow pattern. AI code generation tools are trained to produce code that looks correct and compiles. They are not trained to ask whether you have thought through your error handling, your concurrency model, or what happens when the third-party API returns a 429 at 2 AM on a Sunday. The specific failure Lawson identifies is that speed encourages acceptance. When a tool produces 40 lines in 3 seconds, the psychological pressure is to keep moving. Slowing down on purpose - reading each function, questioning each assumption - runs against the grain of what the tool is optimized to make you feel. That tension is the actual problem, and no model update fixes it. It is a behavioral issue with a behavioral solution. Cursor and GitHub Copilot are both capable of producing the same class of plausible-but-wrong output. The difference between them in this context is marginal.

Three approaches to AI-assisted code review

Approach	Time cost per feature	Defect catch rate	Requires what from the developer
Accept AI output directly	Lowest	Low (happy path only)	Ability to write a prompt
Skim and accept	Low	Medium (obvious errors caught)	Pattern recognition, some domain knowledge
Lawson's deliberate review loop	High (~40% overhead)	High (logic, edge cases, architecture)	Full understanding of what the code should do

For a developer shipping internal tooling with low failure cost: skim and accept is probably the right trade. For a developer maintaining a library with public API contracts or a production system with real error budgets: the deliberate review loop is not a nice-to-have. It is the minimum viable process. For someone new to a codebase they did not write: Lawson's approach also functions as a forcing function for learning the codebase, which is a secondary benefit the post underplays.

A short argument about what "faster" means

Skeptic: The whole point of tools like Copilot is to ship faster. If you're spending 40 percent more time reviewing, you've eliminated the benefit. Builder: The benefit was never raw lines-per-hour. The benefit was reducing friction on boilerplate and well-understood patterns. The friction was already low on that work. Skeptic: So you're saying AI is only useful for the easy stuff? Builder: I'm saying AI makes the easy stuff almost free, which means the hard stuff - the design decisions, the edge cases, the review - now takes a larger share of total time. That's not a flaw. That's the actual value redistribution. Skeptic: Developers under pressure to ship are not likely to slow down voluntarily. That pressure doesn't go away because you read a blog post. Builder: Correct. Which is why this is a team policy question, not an individual productivity question.

What Hacker News said, and what it missed

The irony is that AI has made me a better code reviewer because I can no longer assume I understand the code just because I typed it. - HN commenter on Lawson's post

That observation is sharper than it first appears. When you write code yourself, you carry the context of every decision in your head. The code and the mental model arrive together. When AI writes the code, the mental model has to be reconstructed from the output, which is closer to how you review someone else's pull request than how you write your own feature. That reconstruction is slower, but it is also more rigorous, because you are actually reading the code rather than recognizing patterns you already know. What the HN discussion largely missed is that this changes what skill matters most. The premium used to be on the developer who could write complex logic quickly. The premium now shifts toward the developer who can evaluate complex logic accurately - catching not just syntax errors but intent mismatches, missing requirements, and subtle architectural problems. Those are different skills. Not everyone who was good at the first one is automatically good at the second. This connects to a broader question about how agents change developer workflows - tools like Claude Code are starting to generate longer and more interconnected blocks of code, which makes the review surface larger, not smaller, over time.

A prediction that will be testable by November 2025

At least one major developer tooling company - Cursor, GitHub, or JetBrains - will ship a feature explicitly designed to slow down acceptance of AI-generated code. Something like a mandatory review delay, a structured checklist before commit, or an inline "did you read this?" gate. The productivity narrative has been dominant for two years. The quality narrative is now visible enough that a tool which markets itself on slowing you down thoughtfully will find buyers. If no such feature ships by November 2025, the market signal is that developers are not yet asking for it, which would itself be an interesting data point about whether Lawson's argument is landing with the people who most need to hear it.