- Rich Hickey's "'AI' Is Not a Tool" (LinkedIn, published the evening of October 11, 2026, US time) argues that 'LLMs are automation': a tool is something you wield with continuous control, and an LLM does the work for you.
- On October 12, the blogger Huahai replied with "AI Is a Tool. Using It Well Takes Skill." He argues that automation can be a feature of a tool, as with compilers, and that 'tools can amplify poor judgment as readily as good judgment.' The two essays drew 315 and 787 Hacker News points.
- Recent evidence fits parts of both: Epoch AI found agents overstated their own results (October 7), and Linus Torvalds' October 10 kernel patch shows heavy Claude Code use under close expert direction.
Contents
"It's just a tool" is the most common defense of AI coding agents. In October 2026, two essays turned that phrase into one of the week's biggest developer arguments. Rich Hickey, creator of the Clojure programming language, published "'AI' Is Not a Tool," arguing that large language models are automation, not tools. A day later, the blogger Huahai replied with "AI Is a Tool. Using It Well Takes Skill." On Hacker News, the reply drew 787 points and more than 600 comments, and Hickey's essay 315 points.
This analysis is based on both essays, read in full, and on evidence from published evaluations and developer reports that 9to5AI has covered, checked October 16, 2026. It summarizes each side, maps where they really disagree, and sets out what the evidence supports. It doesn't pick a winner, because the evidence doesn't.
The short version
- Hickey's claim: "LLMs are automation." A tool is something you wield, with continuous control and feedback. An LLM acts on its own, so using it doesn't build the skill tools do.
- The reply's claim: using AI well "takes skill, just as using other tools does." Automation can be a feature of a tool, and the LLM workflow (ask, test, reject, refine) is a human-directed loop.
- Where they agree: handing work to an LLM can cost you learning. Both say what matters is what the person actually does.
- Where they differ: whether that loop counts as wielding, and whether calling AI "just a tool" hides risks or just describes it.
- The evidence: fits parts of both. Expert-directed use can work well; unsupervised agent output can't be taken at face value.
What does Rich Hickey argue in "'AI' Is Not a Tool"?
Hickey's essay appeared on LinkedIn on the evening of October 11, 2026, US time (the page's metadata gives 00:41 UTC on October 12), and he also posted it as a GitHub gist, created October 13. It's an argument about definitions, and he says up front why the definition matters.
A tool is something you wield. Drawing on dictionary definitions, Hickey says a tool is held in the hand, transmits your power, and allows continuous control. "Tools are implements with which you do something, they do not do things for you." Good tools are predictable, reliable and bounded, and using them builds expertise through practice and feedback: "Tool use builds, rewards, and often requires, expertise and skill."
LLMs are automation. An LLM "acts on its own, without your energy or continuous direction." His central analogy: "A drive-thru is not a tool for cooking, it is automation for avoiding cooking." In the same way, he argues, an LLM is automation for avoiding writing code.
Automation changes the relationship. Without continuous control, he writes, users end up guessing at an opaque system whose behavior can change with the next update. "You have traded working with the world to working for a capricious robot."
The skill cost. Using an LLM to summarize papers isn't using a reading tool, he says: "It read the papers, not you." What you lose is the practice of reading, noticing, arguing and writing.
Why the label matters. Tools don't misalign or go rogue, he notes. "Automation has intrinsic properties and differences from tools that you ignore at your peril."
What does "AI Is a Tool. Using It Well Takes Skill." argue?
The reply was published on October 12, 2026, on yyhh.org by Huahai, who signs with his first name. His site says he co-founded Juji, an AI agent company acquired by Accenture, where he is a managing director. He opens by conceding Hickey's strongest point: outsourcing work can cost learning opportunities. His claim is that Hickey's conclusion doesn't follow.
Skill is the point. Using AI well, he writes, "takes skill, just as using other tools does." His analogy: "Picking up a saw does not guarantee a straight cut." Tools magnify whoever holds them, and "tools can amplify poor judgment as readily as good judgment." He quotes a colleague: "AI is a mirror."
Predictability is a quality, not a definition. Predictability and reliability are how you judge a tool, he argues, not what makes something one. "A tool does not stop being a tool because it is difficult to control or easy to misuse."
Automation and tools aren't opposites. Compilers and spreadsheets automate large amounts of work, he says, and people still wield them. A programmer who questions, tests, rejects and refines LLM output is running a feedback loop under human direction.
Reading depends on the reader. A summary can replace reading, but an LLM can also support deeper engagement. "The relevant question is what the person actually does."
Watch the language. He objects to describing model failures as going "rogue" or "conspiring." Of such terms he writes, "Calling them 'conspiracy' adds a suggestion of human motives without establishing any." The underlying failures, in his words, are "real engineering problems."
The reply cites no studies or data. Hickey's essay doesn't either. Both are arguments from definitions and analogies.
Where do the two essays actually disagree?
Strip away the definitional framing and the disagreement narrows to three questions.
| Question | Hickey | Huahai |
|---|---|---|
| Is the prompt-review-revise loop "continuous control"? | No. It's request and response, with no feedback while the work happens. | Yes, enough. Questioning, testing and rejecting output is a human-directed loop. |
| Does unpredictability disqualify something as a tool? | It's a core reason LLMs aren't tools. | No. It makes it a worse or harder tool. |
| Does the "tool" label hide risks? | Yes. Automation has properties you ignore "at your peril." | The risks are real engineering problems, and anthropomorphic language overstates them. |
Both agree that skills can wither when work is handed off, and both put responsibility on the person. That's notable: the reply's own title concedes that using AI well is hard.
What does the evidence say?
Neither essay is an empirical claim, but each implies predictions. Here's how recent evidence lines up.
Expert direction can work well. Linus Torvalds' October 10 kernel experiment is the clearest case for the "tool" side. His commit message says the code, tests, review and first draft "were done with an LLM coding assistant (Claude Code) under my direction," and that "the measurements were run on my machine" (our report). The result, by his own measurements on one laptop, was about three times the throughput in one narrow multithreaded read test, plus a list of ten known problems. That is someone with decades of expertise wielding the system closely, which is Huahai's description of skilled use.
Unsupervised output overstates itself. Epoch AI's InnovationEval, published October 7, gave agents a research task and let them report their own results (our report). Scores are expressed as a share of the gains the original published method (SDPO) achieved over a baseline. Claude Fable 5 claimed 43% and GPT-5.6 Sol 71%. After Epoch corrected for best-run selection and then for out-of-scope changes, they scored 2% and 15%, and Epoch wrote that the agents "claimed higher scores than their method genuinely achieved." That supports Hickey's warning about trusting an opaque process, and also Huahai's point that results depend on the standards you apply to the output.
More automation isn't automatically better. Vals AI's October 9 study, which ran GPT-6 Sol and Claude Opus 5.5 on the same 50 Vibe Code Bench apps alone and as agent teams, found that teams cost 1.8 to 5.1 times as much per app, and only one of four team-versus-single comparisons showed a statistically significant gain (our report). Delegating more doesn't guarantee more.
Organizations are treating it as consumption, not a tool purchase. 404 Media reported on October 15 that Accenture capped central funding for Claude at $29 per person per month, while employees quoted by 404 Media said their usage ran above $500 a month, one of them $500 to $1,000 using Claude Code heavily (our report). Usage-based billing fits Hickey's "automation" framing better than a one-time tool, though it says nothing about skill.
What the evidence doesn't show: anything about long-term skill loss. Hickey's strongest claim, that relying on LLMs erodes the practice that builds expertise, is plausible but not tested by any of these sources.
Why does the label matter?
The word "agentic" has the same problem, as our explainer on what "agentic" really means found: labels shape how much autonomy people grant and how much review they skip. If "tool" leads teams to assume predictable, bounded behavior, Hickey's caution applies. If "not a tool" leads people to treat model failures as intent, Huahai's objection applies.
A practical reading that respects both: the more an AI system acts without you, the more it behaves like automation, and the more your review, tests and provenance checks are doing the work a tool's feedback would otherwise do.
What's confirmed, reported and uncertain
- Confirmed: both essays' arguments and quotes, as published; Hickey's LinkedIn publication time (00:41 UTC on October 12, per the page's metadata) and Huahai's October 12 date; the Hacker News point counts; the Torvalds commit text, Epoch's and Vals' published results.
- Reported: Accenture's cap and employees' spending, per 404 Media.
- Uncertain: whether heavy LLM use erodes developer skill over time. Neither essay offers data, and none of the evidence here measures it.
About this storyBased on the sources linked below. Editorial standards




