After extended use of AI coding assistants, found that the initial productivity gains masked a growing inability to deeply understand their own codebase. The post describes a pattern of dependency where debugging without re-consulting the AI became increasingly difficult — a realization that prompted a return to writing code by hand.
Argues that while AI-generated code is correct and conventional for common cases like CRUD endpoints, it optimizes for the median. For performance-critical paths, novel architectures, or codebases that need to evolve gracefully over years, this median quality acts as a ceiling rather than a floor, leading to accumulated technical debt.
The editorial frames the movement not as anti-AI Luddism but as a natural correction 18-24 months into adoption. The pattern across indie developers, staff engineers, and open-source maintainers is consistent: initial productivity euphoria followed by recognition that the tradeoffs — in comprehension, code quality, and developer autonomy — were poorly understood during the honeymoon period.
A developer writing at blog.k10s.dev published "I'm going back to writing code by hand" — a personal account of abandoning AI coding assistants after extended use. The post struck a nerve: it reached 737 points on Hacker News, placing it in the top fraction of a percent of HN submissions by engagement.
The timing matters. We're now 18-24 months past the initial wave of Copilot, ChatGPT, and Claude integrations into developer workflows. The honeymoon period is definitively over. What's emerging isn't a rejection of AI wholesale, but a reckoning with what was actually gained versus what was quietly lost.
The post joins a growing body of practitioner accounts — from indie developers, staff engineers, and open-source maintainers — describing a pattern: initial productivity euphoria followed by a creeping realization that their relationship with their own codebase had changed, and not for the better.
The argument against AI-assisted coding, when articulated by experienced practitioners rather than pundits, tends to converge on three concrete problems.
The comprehension gap. When you write code by hand, you build a mental model of the system line by line. When an AI generates a function and you review it, you understand *that* it works but not always *why* it was structured that way. Over weeks and months, these small comprehension gaps compound. Developers report finding themselves unable to debug their own codebases without re-consulting the AI — a dependency loop that would have been unthinkable two years ago.
The quality plateau. AI-generated code tends toward the median. It produces correct, conventional solutions optimized for the most common case. For CRUD endpoints and boilerplate, this is fine. For performance-critical paths, novel architectures, or code that needs to evolve gracefully over years, median quality is a ceiling, not a floor. Several practitioners have noted that AI-assisted codebases accumulate subtle design debt faster because each generated block is locally reasonable but globally incoherent — no AI has a taste for system-level aesthetics.
The skill atrophy problem. This is the argument that resonates most viscerally with senior engineers. Programming ability is a muscle. When you stop exercising the hard parts — the algorithmic thinking, the API design, the "how should I decompose this" decisions — those capabilities degrade. For developers early in their careers, outsourcing these decisions to AI may prevent the skills from forming at all. The industry hasn't grappled with what a generation of developers trained primarily as AI prompt-wranglers means for the long-term talent pipeline.
But the counter-arguments deserve their strongest formulation too.
The pro-AI-tooling camp, equally populated by serious practitioners, points out that nobody writes their own allocator anymore, either. Every generation of developers has outsourced previously-manual tasks to higher abstractions. Compilers replaced hand-optimized assembly. Frameworks replaced hand-rolled HTTP parsing. Garbage collectors replaced manual memory management. Each transition provoked the same "you're losing essential skills" anxiety, and each time, the net result was developers building more ambitious systems faster.
The strongest version of the pro-AI argument isn't "AI makes you faster" — it's "AI lets a solo developer build what previously required a team." Indie developers shipping complete products with AI assistance report capability multipliers that change the economics of what's worth building. When your iteration cost drops by 3-5x, projects that were economically irrational become viable.
There's also a survivorship bias in the backlash narratives. Developers who quietly integrated AI tools, calibrated their usage, and are shipping faster without drama don't write blog posts about it. The discourse is dominated by two poles: AI maximalists who claim 10x productivity, and AI skeptics writing manifestos about returning to hand-crafted code. The vast middle — developers using Copilot for autocomplete, Claude for rubber-ducking complex problems, and their own brains for architecture — is underrepresented.
The practical takeaway isn't "use AI" or "don't use AI." It's about developing an explicit policy for where AI adds genuine value in your specific workflow versus where it creates hidden costs.
Where AI coding tools earn their keep: boilerplate generation, test scaffolding, language/framework translation, regex writing, documentation drafts, and exploring unfamiliar APIs. These are tasks where speed matters more than deep understanding, and where the generated output is easily verified.
Where going manual pays off: core domain logic, performance-critical paths, security-sensitive code, architecture decisions, and any code you'll need to debug at 2 AM six months from now. If you can't explain every line to a junior developer without referencing the AI conversation that produced it, you don't understand your own system well enough.
Team leads should be particularly attentive. Code review processes designed for human-written code may not catch the failure modes of AI-generated code — which tends to be syntactically clean but occasionally semantically wrong in subtle ways. Consider whether your review process accounts for this.
The 737-point HN reaction suggests this isn't a fringe position — it's a mainstream recalibration. The AI coding tool market is entering its "trough of disillusionment" phase, which historically precedes the most productive period of any technology adoption. The developers who emerge from this phase with the clearest picture of when to use AI and when to think for themselves will have a genuine competitive advantage. The tools aren't going away. The question was never whether to use them — it's whether you're using them, or they're using you.
I've set a few rules for working with coding agents:1. If I use a coding agent to generate code, it should be something I am absolutely confident I can code correctly myself given the time (gun to my head test).2. If it isn't, I can't move on until I completely understand what it is t
When it was Copilot tab-completing lines, people would say, "yea, but you still have to make sure you're the one writing the whole functions".Then when it was completing functions, people would say, "yeah, but you still have to make sure you're the one writing the logic arou
That’s the same story I had.The swindle goes like this, AI on a good codebase can build a lot of features, you think it’s faster it even seems safer and more accurate on times, especially in domains you don’t know everything about.This goes in for a while whilst the codebase gets bigger and explorat
> The other change is simpler: I'm doing the design work myself, by hand, before any code gets written. Not a vague doc. Concrete interfaces, message types, ownership rules.That’s the hard part of coding. If you have an architecture then writing the code is dead simple. If you aren’t writing
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Yep. The only people I've heard saying that generated code is fine are those who don't read it.The problem is that the mitigations offered in the article also don't work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big