The Paradox of Precision: Why Writing Better Code Means Writing It Slower

A seductive fantasy has taken hold of the software industry: AI will make us faster. Faster to prototype, faster to ship, faster to fix bugs. Speed is the metric venture capitalists worship, engineering managers optimize for, and developers internalize as the ultimate signal of competence. But what if the entire premise is backward? What if the most valuable thing AI can teach us is not how to write code faster, but how to write it slower?

This uncomfortable, almost heretical argument emerges from a corner of the developer community that has paid close attention to how large language models change the craft of programming. The core insight, articulated with surgical precision in a recent editorial by engineer Nolan Lawson [1], is that AI-assisted coding introduces a fundamental tension between velocity and quality. The developers who will thrive in this new era are not those who accept AI's output at face value, but those who deliberately slow down to interrogate it.

The timing of this argument is not accidental. Just days before Lawson's piece went live, Anthropic hosted its "Code with Claude" event in London—a two-day spectacle that ran concurrently with Google I/O and showcased the cutting edge of AI-assisted software development [4]. At that event, Anthropic engineer Jeremy Hadfield asked a question from the main stage that would have been unthinkable just two years ago: "Who here has shipped a pull request in the last week that was completely written by Claude?" [4] The audience response, according to MIT Technology Review's coverage, was telling. The vibes were strong, the enthusiasm palpable, but the deeper implications of shipping code you didn't write were left largely unexplored [4].

This is the gap that Lawson's analysis fills, and it deserves far more attention than it has received.

The Cognitive Load of AI-Generated Code

To understand why writing code more slowly might produce better results, we first need to understand what happens when a developer accepts AI-generated code without rigorous review. Lawson's argument rests on a deceptively simple observation: reading code is fundamentally harder than writing it [1]. When you write code yourself, you build a mental model of the system in real time. Every variable, every function call, every edge case you handle is a deliberate act of cognition. You know where the bodies are buried because you buried them yourself.

AI-generated code inverts this relationship. The developer becomes a reviewer, not an author. Reviewing code—especially code that appears syntactically correct and plausibly functional—requires a different, arguably more demanding, cognitive skill set. You are not building a mental model from scratch; you are reverse-engineering one from an opaque artifact. This is not simply a matter of "checking for bugs." It involves understanding whether the AI's solution actually fits the problem, whether it handles edge cases the AI never considered, and whether it introduces subtle performance regressions or security vulnerabilities that a superficial read would miss.

The danger is that AI-generated code looks correct. It compiles. It passes the initial test suite. It even follows your project's style guide. But as Lawson points out, the real problems with AI-generated code are often invisible to automated checks [1]. They live in the assumptions the AI made about your data model, in the library versions it hallucinated, and in the architectural patterns it chose because they were statistically common in its training data rather than appropriate for your specific use case.

This is where the "slow down" imperative becomes not just a philosophical preference but a practical necessity. Lawson argues that developers using AI coding assistants need to adopt a fundamentally different workflow—one that deliberately introduces friction into the acceptance process [1]. Instead of treating AI output as a draft to be lightly edited, developers should treat it as a proposal to be rigorously challenged. This means reading every line of generated code with the same skepticism you would apply to a junior developer's pull request, but with the added awareness that the AI has no understanding of your business logic, your users' needs, or the long-term maintainability of your codebase.

The irony is that this slower, more deliberate approach may actually reduce the productivity gains AI coding tools promise. But Lawson's argument suggests that the alternative—accepting AI output uncritically in pursuit of speed—leads to a different kind of cost: technical debt that compounds exponentially as AI-generated code accumulates in a codebase without proper human oversight [1].

The Synthetic Certainty Problem

The risks of uncritical AI adoption extend far beyond software development, and the parallels are instructive. Consider journalist and author Steven Rosenbaum, whose new book The Future of Truth: How AI Reshapes Reality explores how "Truth is being bent, blurred, and synthesized" by "fast-moving, profit-driven AI" [3]. In a deeply ironic twist, a New York Times investigation found that Rosenbaum's own book contained what he now acknowledges as "a handful of improperly attributed or synthetic quotes" [3]. Rosenbaum, despite having more reason than most to distrust AI, still fell victim to the very phenomenon he was warning about.

This is the synthetic certainty problem. AI systems generate output that is statistically plausible but factually unreliable. They produce text—and code—that looks authoritative but is built on probabilistic pattern matching, not genuine understanding. The danger is that the more fluent and convincing the output, the less likely humans are to scrutinize it. Rosenbaum wants to keep using AI despite the synthetic quotes incident [3], which suggests that even when we know the risks, the productivity gains are too tempting to abandon.

The same dynamic plays out in software development. An AI coding assistant that generates a 50-line function that perfectly handles the happy path but silently fails on three edge cases is arguably more dangerous than one that generates obviously broken code. The obvious failure gets caught in review. The subtle failure ships to production and manifests as a bug that takes days to diagnose because no one suspects the AI-generated code that "looks fine."

Lawson's editorial implicitly addresses this by advocating for a workflow that treats AI-generated code as inherently suspect [1]. This is not about Luddism or resistance to technological progress. It recognizes that the cognitive biases making us vulnerable to synthetic text—fluency, authority, plausibility—are amplified when the output is code, because code has the additional property of being executable. A synthetic quote in a book is embarrassing. A synthetic function in a production system can be catastrophic.

The Anthropic Paradox: Speed vs. Craft

The "Code with Claude" event in London showcased exactly this tension. Anthropic's engineers demonstrated impressive capabilities—entire pull requests generated by Claude, complex refactoring tasks completed in minutes, boilerplate eliminated at scale [4]. The event was designed to inspire, and by all accounts it succeeded. But the framing of the event, as reported by MIT Technology Review, raises questions that the celebratory atmosphere may have obscured [4].

When Hadfield asked the audience who had shipped AI-written pull requests, the implicit message was that this is the future, and you should be part of it. But what about the pull requests that were not shipped? What about the AI-generated code that looked correct but introduced subtle bugs that only manifested weeks later? What about the developers who accepted AI output without understanding it, creating a codebase that no human fully comprehends?

This is the Anthropic paradox. The company is building tools that are genuinely impressive—Claude's coding capabilities represent a genuine leap forward in what AI can do for software development. But the very success of these tools creates new challenges the industry has not yet grappled with. The faster AI can generate code, the more important it becomes to slow down the review process. The more fluent the output, the more rigorous the scrutiny must be.

Lawson's argument provides a framework for resolving this paradox. Instead of measuring productivity by lines of code written or pull requests merged, developers should measure it by the quality of the code that survives review [1]. This shifts the metric from speed to correctness, from throughput to understanding. It also implies a different role for AI in the development process—not as a replacement for human judgment, but as a tool that augments it by generating proposals that humans then evaluate with full attention and care.

This is not the vision that Anthropic or any other AI company is likely to promote. Their business models depend on demonstrating dramatic productivity improvements. But the developers who actually ship production code know that productivity is not the same as progress. A thousand lines of buggy code merged in an afternoon is not a win. It is a liability.

The Business Case for Deliberate Development

The argument for writing code more slowly is not just a technical preference; it has real economic implications. Consider the cost structure of modern software development. The most expensive bugs are not the ones caught in code review or testing. They are the ones that make it to production and require emergency fixes, data migrations, or customer communications. They are the security vulnerabilities that get exploited because an AI model used an insecure pattern that happened to be common in its training data.

Lawson's editorial suggests that the true cost of AI-generated code is not the time saved in writing it, but the time spent debugging it later [1]. This is a classic trade-off familiar to any engineer who has inherited a legacy codebase: code written quickly but without understanding will need to be rewritten. The difference is that AI allows developers to generate incomprehensible code at unprecedented speed, accelerating the accumulation of technical debt.

The business case for deliberate development is straightforward: invest more time in understanding and reviewing AI-generated code now, or invest much more time later in fixing the problems it creates. This is the same logic that drives investment in testing, code review, and architectural planning. AI does not eliminate these needs. It amplifies them.

There is also a human capital dimension to consider. Developers who rely too heavily on AI coding assistants without developing their own understanding of the codebase risk becoming what one might call "prompt engineers"—people who can generate code but cannot reason about it. This is not a sustainable career trajectory. The developers who will be most valuable in the AI era are not the ones who can generate the most code with the fewest prompts, but the ones who can evaluate, critique, and improve AI-generated code with deep technical understanding.

This is where the "slow down" imperative becomes a competitive advantage. Developers who take the time to understand every line of AI-generated code, who challenge its assumptions, and who refactor it to fit their mental model of the system will build robust, maintainable software. They will also be the developers least replaceable by AI, because their value lies not in their typing speed but in their judgment.

The Hidden Curriculum of AI-Assisted Development

The sources for this analysis converge on a theme rarely discussed in the breathless coverage of AI coding tools: the importance of human judgment in an AI-augmented workflow. Lawson's editorial provides the technical framework [1]. The Rosenbaum case offers a cautionary tale about the dangers of accepting AI output uncritically [3]. The Anthropic event provides the context of an industry racing ahead without fully grappling with the implications [4].

What emerges is a picture of an industry in transition. The tools are powerful. The potential is real. But the skills that matter are changing. The developer who succeeds in this new environment is not the one who can write the most code the fastest, but the one who can read code critically, evaluate AI proposals with rigor, and maintain a deep understanding of a system even as the code within it is increasingly generated by machines.

This is the hidden curriculum of AI-assisted development. It is not taught in the documentation for Claude or Copilot or any other coding assistant. It is not measured by the benchmarks AI companies publish. It is learned through experience, through the painful process of debugging AI-generated code that went wrong, and through the discipline of refusing to merge code you do not fully understand.

Lawson's editorial is valuable precisely because it articulates this hidden curriculum [1]. It gives developers a vocabulary for what they may already be feeling: that AI tools are making them faster but not necessarily better, that the code they are shipping is more voluminous but not more robust, and that the craft of software development is being transformed in ways that are not entirely comfortable.

The alarm clock company Dreamie recently launched a product that got people to stop using their phones in bed by doing something laughably simple: it can play podcasts [2]. The lesson is that sometimes the most effective solutions are not the most technologically sophisticated. They address the actual human problem, which in Dreamie's case was not the lack of a smart alarm clock but the inability to put down a phone.

The parallel to AI-assisted coding is striking. The actual human problem is not that developers cannot write code fast enough. It is that they cannot evaluate code carefully enough. The solution is not a better AI model. It is a better workflow—one that deliberately introduces friction, forces deliberation, and prioritizes understanding over speed.

The developers who internalize this lesson will not be the fastest. But they will be the best. And in the long run, that is the only metric that matters.

---

References

[1] Editorial_board — Original article — https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

[2] TechCrunch — The Dreamie alarm clock got me to stop using my phone in bed — https://techcrunch.com/2026/05/24/the-dreamie-alarm-clock-got-me-to-stop-using-my-phone-in-bed/

[3] Ars Technica — AI put "synthetic quotes" in his book. But this author wants to keep using it. — https://arstechnica.com/ai/2026/05/ai-put-synthetic-quotes-in-his-book-but-this-author-wants-to-keep-using-it/

[4] MIT Tech Review — Anthropic’s Code with Claude showed off coding’s future—whether you like it or not — https://www.technologyreview.com/2026/05/21/1137735/anthropics-code-with-claude-showed-off-codings-future-whether-you-like-it-or-not/