I Will Never Use AI to Code: Why This Argument Still Matters

Every so often, a variation of the same argument resurfaces on Hacker News: AI should have no place in a programmer's workflow. The latest example comes from an article titled "I Will Never Use AI to Code", published on May 9, 2026. It accumulated few upvotes and comments at indexing, but that doesn't make it irrelevant. Rather, it represents a position many professionals hold privately and rarely articulate publicly.

It deserves attention precisely because it goes against the grain. In an ecosystem where Claude Code, MCP servers, and subagets have become routine parts of many engineering teams' workflows, someone saying a reasoned "no thanks" forces us to make explicit the things we usually take for granted.

The Core Argument

The original article (which we recommend reading directly) contends that outsourcing code or text writing to AI means externalizing the exact capacities a professional must exercise to keep them sharp. The reasoning isn't new, but it's not exhausted either. The strongest version of the argument has two parts:

• Cognitive degradation through disuse. If a model generates the code and you review it, you're training a different skill than writing it yourself. Over time, the gap between the two can grow without you noticing.
• Shallow understanding of the output. Accepting generated code without understanding it in detail introduces technical debt of a kind that's hard to audit: you don't know what you don't know you don't know.

These are legitimate objections. They're not irrefutable, but they deserve an honest response rather than quick dismissal.

What Actual Practice Shows

Those who work daily with tools like Claude Code typically distinguish between uses that substitute reasoning and uses that amplify it. There's an operational difference between asking a subagent to refactor a complex module while you define the criteria and review the result, versus asking it to write a function you have no idea how should work.

The article's criticism points more accurately at the second case. And in that case, it has a point.

Where the argument weakens is in the implicit assumption that any use of AI in code necessarily falls into that category. In practice, the level of supervision, the programmer's prior domain knowledge, and the task type determine whether the result reinforces or erodes understanding. A senior developer using Claude Opus 4.7 to explore architectural design alternatives is doing something qualitatively different from a junior accepting unread autocompletion suggestions.

Who This Debate Matters For

This type of article reaches a broader audience than its modest initial traffic suggests. It's relevant for:

• Teams with junior developers, where uncritical adoption of generation tools can substitute for learning rather than accelerate it.
• Educators and bootcamps, redesigning curricula and needing arguments from both sides to make informed decisions.
• Software engineers working solo without the natural friction of code review to catch code they don't fully understand.
• Anyone using Claude Code who hasn't explicitly asked themselves: am I using this to think better or to think less?

What the Debate Usually Misses

Public discussion about AI and programming tends to polarize between enthusiastic adoption and categorical rejection. What's almost always absent is granularity: what type of task, with what level of supervision, at what project phase, with what developer profile.

The article in question opts for total rejection as its position, which has the virtue of consistency but the cost of ignoring that granularity. "Never" is a policy easy to defend and hard to justify in absolute terms.

---

From our perspective, the most useful position is neither friction-free enthusiasm nor principled rejection. It's the one that requires each professional to be explicit about what they delegate, why, and with what oversight. That uncomfortable exercise is worth more than any predetermined stance.