There's a counterintuitive idea gaining traction in developer circles right now: the smartest way to use AI coding tools isn't to go faster. It's to go slower, and use the time you save to think harder about what you're actually building.
That argument, laid out by software engineer Nolan Lawson in a blog post published May 25, 2026, sparked a significant discussion on Hacker News — and it raises questions that matter well beyond senior engineers at large companies. If you're a freelancer writing code for clients, a small business owner relying on a developer, or a non-technical founder using AI tools to build your first product, this shift in thinking has real consequences for how you spend your time and money.
What Happened
Lawson's post, titled "Using AI to Write Better Code More Slowly," pushes back against the dominant narrative around AI coding assistants. That narrative — heavily promoted by tools like GitHub Copilot, Cursor, and Windsurf — is essentially: AI makes you faster, so you ship more, so you win.
Lawson's argument is more nuanced. He contends that the real opportunity AI offers isn't raw speed. It's cognitive offloading of the tedious parts of coding — boilerplate, syntax lookups, repetitive patterns — which frees up mental bandwidth for the harder, more valuable work: system design, code quality, edge case thinking, and understanding why something should be built a certain way, not just how.
According to the Hacker News thread, the post resonated strongly with working developers. Commenters described recognizing a pattern in their own work — using AI to blast through implementation, only to end up with code they didn't fully understand, that was harder to maintain, and that introduced subtle bugs they only caught weeks later.
This isn't just anecdotal. A 2024 study published by GitClear analyzed over 153 million lines of code and found that AI-assisted codebases showed a measurable increase in code churn — meaning code written with AI help was being rewritten or reverted at higher rates than code written without it, according to GitClear's annual report. Separately, a 2023 paper from Stanford researchers found that developers using GitHub Copilot were more likely to introduce security vulnerabilities, as reported by Stanford's Human-Computer Interaction group.
Lawson's prescription isn't to avoid AI. It's to use it differently: let AI handle the mechanical parts, then invest the recovered time back into reading the output carefully, refactoring for clarity, and building genuine understanding of what the code does.
Why It Matters for Small Businesses and Freelancers
If you're not a developer yourself, you might wonder why a blog post about coding philosophy applies to you. Here's why it does.
The "Vibe Coding" Problem Is Already Affecting Client Work
The term "vibe coding" — coined by OpenAI co-founder Andrej Karpathy in early 2025 and widely covered by outlets including The Verge — describes the practice of generating code with AI prompts without deeply understanding what's produced. It's become a genuine workflow for a growing number of freelancers and solo builders.
There's nothing inherently wrong with this. But if the developer or contractor you're paying is vibe-coding your business application, Lawson's post surfaces a real risk: they may be shipping fast, billing by the hour, and handing you code that looks fine until something breaks — at which point fixing it is expensive and confusing.
Freelancers face the mirror image of this problem. If you're using AI to ship client work faster, you may be inadvertently creating technical debt that comes back to you as scope creep, bug fixes, or lost client trust.
Speed-to-Ship Is Not the Same as Business Value
Small business owners are often told that speed is everything — ship fast, iterate, move on. AI coding tools are sold partly on this promise. GitHub Copilot's marketing claims developers see "up to 55% faster task completion," according to GitHub's own research blog.
But faster task completion is only valuable if the tasks are the right ones, and if the output is reliable. Lawson's framing reframes the benefit: the time AI saves you is an asset to be reinvested, not just pocketed as throughput. A freelancer who uses Copilot to finish a feature in two hours instead of four hasn't necessarily delivered twice the value — but they could, if they spend that extra time on documentation, testing, or genuinely understanding the architecture they've built.
For small businesses hiring developers or agencies, this is a legitimate question to ask: are your contractors using AI to deliver more value, or just to bill fewer hours while delivering the same (or lower) quality?
The Maintenance Cost Nobody Talks About
Building software is one cost. Maintaining it is another — and often larger over time.
According to a 2023 report from the Consortium for IT Software Quality (CISQ), poor software quality cost US organizations approximately $2.41 trillion in 2022. That figure includes costs from failed projects, technical debt, and operational failures. The majority of that cost comes not from the initial build but from ongoing maintenance of code that wasn't well understood or well structured when it was written.
Lawson's argument maps directly onto this: AI-accelerated development that skips the "slow down and understand it" phase is likely to contribute to this kind of downstream cost — especially for small businesses that don't have dedicated QA teams or large engineering budgets to absorb it.
What It Means Practically
So what does this actually look like in practice? For different people in your orbit — yourself, your contractors, your team — the implications of Lawson's framing cash out differently.
If You're a Non-Technical Founder Using AI to Build
Tools like Cursor, Replit, and various GPT-based code generators have made it genuinely possible for non-developers to build functional software. This is real and valuable. But Lawson's post is an argument for building slower habits alongside these tools.
Concretely, that means:
- Don't just run the code — read it. Ask your AI tool to explain what each section does. This is slower, but it builds the mental model you'll need when something breaks.
- Test before you ship, not after. AI can generate test suites quickly. Use that capability instead of skipping tests because shipping felt more urgent.
- Treat the first draft as a draft. AI output is often a reasonable starting point, not a finished product. Budget time to review and refactor.
If you're using Zapier or Make.com for automation workflows alongside coded solutions, the same principle applies — understand the logic of what you're connecting, not just whether it runs.
If You're Hiring Developers or Freelancers
The practical implication here is about how you evaluate the work you're paying for, not just whether it functions.
Ask for documentation. Ask contractors to explain their architecture decisions. Look for codebases with readable variable names, meaningful comments, and test coverage. These are all things a developer using AI thoughtfully — in Lawson's slower, more deliberate mode — will produce. A developer who has vibe-coded their way through your project often won't.
This isn't about being suspicious of AI use. Most experienced developers are using these tools now, and that's fine. It's about evaluating whether AI is being used to raise quality or just to raise throughput.
If You're a Developer or Technical Freelancer
Lawson's post is most directly aimed at you, and his argument is essentially a professional ethics case as much as a technical one.
The pressure to ship fast is real. Clients want quick turnarounds. Hourly billing creates weird incentives. AI tools make it easy to produce code that looks done before it is done. Lawson is suggesting that the developers who build sustainable practices around AI — using it to handle the dull work, then investing back in quality — will produce better outcomes and, over time, better reputations.
Practically, this might mean:
- Timebox your AI generation. Use it freely for boilerplate and repetitive patterns. Then stop and read what it produced.
- Refactor before you commit. AI output tends toward verbosity and repetition. Cleaning it up isn't pedantry — it's how you maintain understanding of your own codebase.
- Write the tests yourself. Or at minimum, read and understand the AI-generated tests line by line. Tests you don't understand aren't a safety net.
- Document your reasoning. A comment explaining why something is built a certain way is often more valuable than a comment explaining what it does. AI won't write those for you without prompting.
If you're managing projects in tools like Notion, ClickUp, or Asana, you can build these quality checkpoints directly into your workflow — a "code review" or "refactor" task that's a first-class part of the sprint, not an afterthought.
The Broader Shift in What "Productive" Means
There's a more philosophical point underneath Lawson's argument that's worth naming directly.
For decades, developer productivity was largely measured in output: features shipped, lines of code written (a flawed metric, but a persistent one), tickets closed. AI tools are collapsing the relationship between time and output — a task that took four hours now takes forty minutes.
That collapse forces a reckoning: if AI can produce the output, the human value-add has to come from somewhere else. Lawson's answer is that it comes from judgment — the ability to evaluate, critique, improve, and take responsibility for what's built.
This matters for small businesses because it changes what you should be looking for when you hire. Raw coding speed is becoming a commodity. Judgment, architectural thinking, and the ability to use AI without losing understanding — those are the skills that hold long-term value.
Key Takeaways
If you've skimmed this far, here's what you need to carry forward:
1. AI speed is most valuable when you reinvest it.
The point isn't to ship twice as fast. It's to use recovered time for the thinking work that produces better, more maintainable software. According to Lawson's framing, the developers who understand this will consistently outperform those who don't over the medium term.
2. Fast AI-generated code creates real downstream costs.
The GitClear 2024 report found measurably higher code churn in AI-assisted projects. The CISQ puts poor software quality costs in the trillions annually in the US alone. These aren't abstract concerns — they're budgetary ones for any business that runs on software.
3. Non-technical founders should slow down too.
If you're building with AI tools, budget time to understand what you're building. Test it. Read the output. This is slower upfront and cheaper over time.
4. Hiring questions are changing.
When evaluating developers or agencies, ask about documentation, testing practices, and architecture decisions — not just delivery speed. AI makes fast delivery table stakes. Judgment and quality are the differentiators.
5. The skill that holds value isn't coding — it's understanding.
As AI handles more of the mechanical production of code, the human premium shifts to comprehension, evaluation, and responsibility. For freelancers, this is the capability worth investing in. For businesses, it's what you should be paying for.
6. Build quality checkpoints into your workflow, not around it.
Whether you're managing projects in ClickUp, Asana, or a simple Notion board, treat code review, refactoring, and documentation as scheduled tasks — not optional extras when there's time. There's rarely time unless you make it.
The conversation Lawson started isn't really about AI tools. It's about what "done" means when building software, and who bears the cost when "done" turns out to mean "done for now." For small businesses and freelancers operating without large engineering teams or deep maintenance budgets, that question has direct financial consequences.
Slower, more deliberate use of AI coding tools isn't a rejection of the technology. It's arguably the more sophisticated adoption of it — and based on the response his post generated on Hacker News, it's a case that's landing with practitioners who've already felt the cost of going too fast.