Write Better Code More Slowly with AI: Hacker News Lessons

A Hacker News post by Nolan Lawson titled "Using AI to write better code more slowly" sparked a massive discussion (558 votes, 210 comments). The central idea is contrarian: instead of chasing speed, use AI to deliberately produce higher-quality code through iteration, review, and careful prompting. The community's response reveals a nuanced reality worth unpacking for anyone building software today.

What's the story?

Nolan Lawson's article argues that the typical AI coding workflow—ask for a complete feature and accept the first output—leads to mediocre code. He proposes a slower, more iterative process: use AI to draft implementations, review them thoroughly, have another AI model review the review, and then refine. The goal isn't to generate code faster but to produce code that is more correct, maintainable, and well-architected. He focuses on using AI for code review, not generation, suggesting the real power lies in catching corner cases and suggesting improvements.

Why it's blowing up on HN

The HN thread is a goldmine of real-world experiences. Many commenters resonated with the "slow but better" approach. One described a multi-step pipeline:

I'll use AI to design the implementation... then implement with a slower, more thorough model like Claude... then review with a faster model like GPT-4 for catching corner cases. Have Claude fix those—Claude is better at writing intuitive, maintainable code.

This aligns with Lawson's thesis but also surfaces friction: managing multiple AI models with different strengths adds complexity. Another commenter pointed out the loss of micro-architectural decisions when using agentic tools:

When using Claude Code or similar agentic tools, that's all gone. The agent is extremely eager to reach the end goal to the point that it feels like a fever dream to write code with it.

This sentiment—that AI agents can bulldoze through design decisions—was a recurring theme. Skeptics found the iterative process slower than writing by hand but acknowledged quality improvement: "Spending the time to personally review and direct the LLM through several iterations... on average results in higher quality code written in about the same time as I would have written it." So the slow approach isn't necessarily slower overall—it shifts effort from writing to reviewing.

My take

I've been using AI coding tools for over two years, and I agree with Lawson's core insight: the default mode—"generate and accept"—rarely produces great code. The real win is in the loops: prompt, review, critique, repeat. But the article underplays a practical challenge: most developers aren't disciplined enough to follow a rigorous multi-model review process. It's mentally taxing, and the temptation to shortcut is huge.

What I've found works is to separate responsibility: use AI for exploration and pattern matching, not for final production code. For example, when I need to traverse a complex data structure, I might ask Claude to sketch three approaches. Then I pick one, write the implementation myself, and ask GPT-4 to review for edge cases. The key is to stay in the driver's seat.

The comment about losing micro-architectural decisions resonates deeply. When you let an agent code end-to-end, you lose the incremental understanding from making those small choices. Code becomes a black box—dangerous for long-term maintainability.

But the slow approach has a hidden superpower: it forces you to read code. Reading AI-generated code is like reading code written by a junior engineer who knows all the syntax but not the conventions. You catch things. That reading practice makes you a better reviewer overall.

What this means for builders

If you're building with AI today, here are concrete practices inspired by the article and the HN discussion:

1. Use different models for different tasks. Claude (Anthropic) tends to write cleaner, more readable code. GPT-4 (OpenAI) often excels at review and catching bugs. Direct the right tool at the right job.

2. Iterate on design first, then implementation. Before generating code, prompt the AI to produce a design document or pseudocode. Review it. Then generate. That reduces the chance of wandering off course.

3. Adopt a review habit. Use AI to review code you wrote, not just to write code. This flips the dynamic: you own the code, AI is the critic. After implementing a function, paste it and ask: "Find any edge cases, performance issues, or violations of [your style guide]."

Here's a quick prompt template I use:

# After writing a function, use this prompt:
"""
Review the following code for:
1. Off-by-one errors or boundary conditions
2. Thread safety or concurrency issues
3. Adherence to the single-responsibility principle
4. Missing error handling (exceptional cases)
Suggest specific fixes.
"""

4. Be aware of context window limits. Slow, careful prompting helps avoid hitting context limits prematurely. Break large tasks into smaller, self-contained chunks.

5. Time-box the iterations. It's easy to fall into an endless loop of "one more fix." Set a limit (e.g., three iterations) and then manually finalize.

Should you care?

If you're a developer who values code quality over raw output speed, this approach can elevate your work. If you're shipping throwaway prototypes or doing exploratory work, the fast-and-dirty approach is fine. But for production systems, especially those you'll maintain for years, the slow, iterative path is the safer bet. The HN community's consensus is clear: AI can produce great code, but only when you treat it as an intelligent but flawed collaborator, not a replacement for your own judgment.

---

For more context, see the original HN thread, Anthropic's Claude documentation, and OpenAI's GPT-4 documentation.