Rich Hickey's 'AI is not a tool' essay draws a rebuttal over skill and automation

The exchange

Rich Hickey, the creator of Clojure, has published an essay titled "'AI' Is Not a Tool" on LinkedIn, arguing that large language models are automation rather than instruments and that treating them as tools misrepresents what developers are actually doing. The piece circulated widely after reaching Hacker News's front page, and it drew a direct response published on the blog yyhh.org under the title "AI Is a Tool. Using It Well Takes Skill." Together, the two essays frame a central argument in software right now: what it means for a developer to use an LLM responsibly.

Hickey's argument: tools are wielded, LLMs are not

Hickey builds his case on definitions. For him, a tool is an implement you wield, one that transmits your energy, responds to continuous direction and provides sensory feedback while you work. Tools, he writes, are things with which you do work, not things that do the work for you, and using them builds expertise about the task and the world. Good tools are also predictable, reliable, deterministic and limited in scope, properties he says LLMs lack.

Because a model acts on requests without your ongoing control, Hickey classifies it as automation, machinery that runs by itself with minimal direct human involvement. His analogy is a fast-food drive-through, which he describes not as an instrument for cooking but as machinery for skipping cooking entirely. In the same way, he argues, an LLM is not something you write code with but something you hand the writing of code over to.

The deeper cost, in his view, is what that handover removes. Instead of learning about the task, you learn the current quirks of the automaton, such as how to phrase requests to get the result you want, and a single model update can wipe out that knowledge. He extends the point beyond code: letting a model read and summarize papers means giving up the practice of learning how arguments are constructed. He also notes that tools are never described as misaligned or as escaping containment, suggesting such fears only make sense for something that acts on its own.

The rebuttal: a difficult tool is still a tool

The yyhh.org response concedes that outsourcing intellectual work can cost real learning opportunities, but argues that Hickey's conclusion does not follow. Predictability, reliability and simplicity are qualities we use to judge tools, the author writes, not conditions for joining the category. A saw in unskilled hands still cuts crooked, and holding a chisel does not make you a sculptor.

Automation, the rebuttal continues, can simply be a feature of a tool. A compiler translates code without step-by-step direction, and a spreadsheet recalculates without manual arithmetic, yet programmers still steer both by supplying inputs, examining outputs and deciding what comes next. The same loop exists with LLMs: asking a model to explain unfamiliar code, challenging the answer, testing the proposed change, rejecting it and refining the request is a human-directed feedback cycle that rewards knowing what to ask and when the answer is wrong.

On reading, the rebuttal distinguishes accepting a summary instead of reading from using a model to interrogate your own understanding of a text, arguing that the possibility of avoiding intellectual work does not prove every use avoids it. It also takes issue with Hickey's language, saying that terms like 'go rogue' and 'conspire' borrow the AI industry's anthropomorphic framing, when unexpected outputs are engineering failures rather than evidence of motives. The useful dividing line, the author concludes, is between wielding an instrument skillfully and delegating work without adequate oversight, a distinction that applies to AI without declaring the entire category tool-free.

Where they overlap

Notably, both writers agree on the core failure mode. Hickey warns against abdicating the work of writing and reading; the rebuttal warns against delegating without understanding or oversight. Neither claims an LLM always does what its operator intends, and neither argues that skill is irrelevant.

Why it matters

The labeling dispute is less about taxonomy than about guidance. If LLMs are automation, the developer's role shifts toward delegation and verification, and skill atrophy becomes the default risk that teams must actively manage. If they are tools, the differentiator is craftsmanship: knowing what to ask, what evidence to trust and when to push back. The disagreement also touches vocabulary, since describing software in agentic terms shapes how organizations regulate and deploy it. For engineering teams writing AI policy, the shared ground between the two essays, that handing over work you do not understand is the real hazard, may be the most actionable takeaway from the debate.