Lawson argues that AI tools like Claude and Copilot have not increased his output velocity, but have improved his code quality. He reinvests the time saved on first drafts into writing tests, exploring alternative designs, reading adjacent code, and documenting — the work engineers typically skip under deadline pressure. The gain shows up as lower defect rates and better maintainability, not as more PRs per week.
The editorial frames Lawson's piece against industry data: GitHub claims 55% speedups, METR's 2026 study found closer to 20% on greenfield and negative on mature codebases, and Stack Overflow shows 67% daily usage but only 41% trust. The combination of high usage and low trust describes a workflow that is structurally broken when speed is the only KPI, validating Lawson's reframing of the productivity question.
The top-voted comment on the HN thread calls Lawson's piece the only honest writeup of the year, arguing that everyone else discussing AI coding tools is either selling something or coping. This reflects a broader community fatigue with vendor-driven productivity claims and an appetite for practitioner accounts that don't match the marketing narrative.
On May 25, longtime web platform engineer Nolan Lawson — the person behind PouchDB, Pinafore, and a decade of unusually clear-headed writing about the browser — published a post titled *Using AI to write better code more slowly*. It hit Hacker News at 1,157 points and the comment thread sprawled past 800 replies before the day was out. The thesis is one sentence long, and contrarian enough to be worth quoting directly: AI coding tools have not made Lawson faster. They have made his code better, because he uses the time they save to do work he was previously skipping.
Lawson is specific about what that means in practice. He uses Claude and Copilot to generate first drafts, then spends the recovered time writing the tests he would have hand-waved past, exploring two or three alternative designs instead of committing to the first one, reading adjacent code more carefully, and writing documentation he would have promised to do later. The productivity gain doesn't show up in lines-of-code or PRs-per-week; it shows up in the defect rate, the maintainability, and the absence of the 2am Slack message six weeks later.
This is not the framing the AI vendors are selling, and the HN thread reflects that mismatch. The top comment, from a staff engineer at a payments company, simply reads: "This is the only honest writeup I've seen this year. Everyone else is either selling something or coping."
The industry has spent eighteen months measuring AI coding tools the wrong way. GitHub's own studies report Copilot users completing tasks 55% faster. METR's March 2026 study put the speedup closer to 20% on greenfield code and *negative* on mature codebases. Stack Overflow's developer survey shows 67% of professional developers now use AI daily, but only 41% trust the output without review. Those two numbers together — high usage, low trust — describe a workflow that is structurally broken if speed is the only metric you care about.
Lawson's reframing dissolves the contradiction. If you stop treating AI as a velocity multiplier and start treating it as a budget transfer — fewer keystrokes on boilerplate, more cycles on the parts that actually fail in production — the trust gap stops mattering. You were going to review the code anyway. The question is whether the time you saved gets spent on review and design, or on the next ticket.
The HN thread surfaces the failure mode this avoids. Multiple commenters describe what one calls "LGTM debt": PRs that look clean, pass tests the AI also wrote, and ship with subtle bugs that take three sprints to surface. A Shopify engineer wrote that their team's incident rate dropped only after they instituted a rule that AI-generated diffs over 50 lines require a written design note before merge — the same gate they'd apply to a human submission, finally applied consistently. Another commenter, a tech lead at a Series C fintech, said they measure their team on "PRs that don't get reopened" rather than throughput, and AI tools made that metric move only after they stopped optimizing for speed.
There is a counter-position in the thread worth taking seriously. A handful of staff-level engineers argue that for truly mechanical work — schema migrations, CRUD endpoints, test fixtures — AI is a pure speed win and Lawson is overcorrecting. The honest synthesis is probably that AI is a velocity tool for code you don't care about and a quality tool for code you do, and the skill is knowing which is which before you start typing.
The deeper point Lawson makes, almost in passing, is about the shape of senior engineering work. The parts of the job that distinguish a senior from a mid-level — design exploration, naming, error handling, deciding what *not* to build — are exactly the parts AI cannot do for you. They are also the parts that get cut first when deadlines tighten. AI gives back the time deadlines used to take. Whether you spend that time being senior or just shipping more mid-level work is a choice, and most teams have not made it consciously.
The operational implication is concrete. If your team has adopted Copilot, Cursor, or Claude Code and not also tightened your review standards, you are running a worse version of last year's process at higher cost. The tooling generates more code per engineer; the review bandwidth has not scaled with it. The math ends badly.
Three things to check this week. First, what is your median PR size since adopting AI tools? If it's gone up meaningfully and your review-to-merge time has gone down, you have an LGTM-debt problem forming. Second, are your AI-generated tests testing behavior or testing the implementation the AI just wrote? The latter is worthless and the AI is very good at producing it. Third, does your team have an explicit norm about when AI-generated code requires a design note? If not, you're relying on individual judgment at exactly the moment individual judgment is under the most pressure to wave things through.
The second-order question is hiring. If senior work is now disproportionately about exercising judgment over AI output, the skills that make a junior promotable have shifted. Reading code carefully, holding a mental model of a large system, and resisting plausible-but-wrong suggestions are now first-class skills, not background ones. The teams that figure out how to train for that — rather than just hiring people who learned it the slow way ten years ago — will have a real advantage in 2027.
The Lawson post is going to be cited the way Joel Spolsky's "things you should never do" got cited: not because it discovered something new, but because it named something everyone was half-thinking and gave the industry a shared phrase for it. Expect to hear "better code more slowly" in standups within the month. The interesting question is whether the AI vendors notice that their best users are the ones ignoring the speedup metric — and whether any of them have the nerve to market a coding assistant on quality instead of throughput. The first one that does will probably win the enterprise segment that the current crop is leaving on the table.
This article doesn't address writing code with AI, just code review. My issue with agentic coding is that I make numerous micro-architectural decisions while programming. I almost never have a full spec up front and develop one as I consider what I am writing.When using Claude Code or Codex, th
I find myself spending on average more time in LLM review/resolution loops than it would take for me to write the code by hand. Partially because once I'm in the flow I write very very quickly and the code pours out sometimes faster than I can write. But also because the LLM code on the fi
As a junior, i do actually enjoy going back and forth with the AI discussing different ways to implement something and exploring alternatives.More often than not, I'd have an architectural idea that I'm not that confident in. The process of talking with the LLM takes a long time but it hel
The linked article about getting LLMs to critique each others' code review[1], the magpie tool[2], and also this recent article from Cloudflare about their code review stack[3] are all quite compelling.I'm fairly AI-skeptical not on grounds of "do they work" but "are they go
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I've hit this point with AI where it's not a simple process, but a long drawn out back and forth.I'll use AI to design the implementation of a medium sized, cross cutting feature. Review all the details, maybe iterate on just that. Then implement with Claude 4.7 Max - which runs slowe