Essay answers Rich Hickey: LLMs are tools, and using them takes skill

A blog post responds to Rich Hickey's October 11, 2026 article, "'AI' is Not a Tool," in which Hickey argues that LLMs are automation rather than tools because they cannot be wielded. The post's author agrees on one point: outsourcing work can cost us opportunities to learn. But the author says Hickey's conclusion does not follow. Even by Hickey's own definition, an LLM can be something a human wields, and using it well takes skill, just as using other tools does.

The author builds the case in several steps. First, tools do not guarantee results: picking up a saw does not guarantee a straight cut, and holding a chisel does not make you a sculptor. Tools amplify poor judgment as readily as good judgment, and their usefulness depends on the operator's ability to direct them, interpret feedback, recognize mistakes and make corrections. Those requirements apply to LLMs too.

Second, unpredictability is a meaningful limitation of LLMs, but predictability, reliability, simplicity and bounded function are qualities by which we evaluate tools, not prerequisites for being one. A tool does not stop being a tool because it is difficult to control or easy to misuse.

Third, the author calls Hickey's split between tools and automation a false division, because automation can be a feature of a tool. A compiler does substantial work without the programmer directing each operation, and a spreadsheet recalculates results without anyone doing every calculation by hand. We still wield them by specifying inputs, examining results and deciding what to do next. The author asks why generating text should disqualify an instrument when translating code or calculating numbers does not.

Fourth, the claim that LLM use lacks intention, feedback, direction and expertise is, in the author's words, especially difficult to defend. A programmer can ask an LLM to explain unfamiliar code, challenge the explanation, inspect the source, test a proposed change, reject it and refine the request. That is a feedback loop directed by a human with a purpose, and doing it well means knowing what to ask, what evidence matters and when the answer is wrong. Expertise makes the instrument more useful.

The author grants that Hickey's concern about reading is valid for one use: accepting a summary in place of reading a paper can sacrifice much of what reading teaches. But someone can read the paper and then use an LLM to question their interpretation, explore an objection or find something to examine more closely. The possibility of avoiding intellectual work does not establish that every use avoids it. What matters is what the person actually does.

What disappoints the author most is the reliance on the AI industry's anthropomorphic vocabulary: "go rogue," "escape containment," "conspire." Repeating those expressions risks accepting a framing that makes these systems sound like independent beings. Unexpected outputs, failure to follow instructions and harm from access to consequential actions are real engineering problems, the author says, and calling them a "conspiracy" adds a suggestion of human motives without establishing any.

The author does not claim an LLM always does exactly what a human tells it to do; it plainly can fail. But failing to obey perfectly does not stop it being a tool, any more than successful use proves the operator has surrendered their judgment. The post closes on a practical distinction: wielding an instrument with skill versus delegating work without adequate understanding or oversight.

Key facts

• The post answers Rich Hickey's October 11, 2026 article "'AI' is Not a Tool," which argues LLMs are automation because they cannot be wielded.
• The author concedes that outsourcing work can cost learning opportunities, but says Hickey's conclusion does not follow: even by his definition an LLM can be wielded by a human.
• Unpredictability and misuse risk are criteria for judging tools, not conditions for being one; automation can be a feature of a tool, as with compilers and spreadsheets.
• Accepting an LLM summary in place of reading a paper can sacrifice what reading teaches, but using an LLM to question your reading of the paper is a different use.
• The author's proposed dividing line is wielding an instrument with skill versus delegating work without adequate understanding or oversight.

Why it matters

The argument is about how people frame LLMs, and framing shapes how they are used and judged. If an LLM is automation that cannot be wielded, skill has no place in using it. If it is a tool, then skill, judgment and oversight decide whether the result is good. The post argues for the second view and offers a practical line: wielding an instrument with skill versus delegating work without adequate understanding or oversight. It also pushes back on the industry's anthropomorphic vocabulary such as "go rogue" and "conspire," which the author says frames software as independent beings.

Who it affects

Programmers who use LLMs to read, explain and change code are the author's main example. Readers and researchers who use LLMs around papers are the second: the post separates replacing the reading with a summary from using an LLM to test their own interpretation. More broadly it speaks to anyone following the debate over whether LLMs are tools or automation.

How to use it

The post is an argument, not a product or a method, but it sketches a working pattern. A programmer asks an LLM to explain unfamiliar code, challenges the explanation, inspects the source, tests a proposed change, rejects it if it fails and refines the request. A reader reads the paper first, then uses an LLM to question their interpretation, explore an objection or spot something worth a closer look. In both cases the human keeps the intention, the feedback loop and the final judgment.

How solid is it

This is an opinion essay. Its reasoning rests on analogies (saw, chisel, compiler, spreadsheet) and one worked example of a programmer's feedback loop, not on studies, benchmarks or measurements; no numbers appear in it. The post summarises and partly paraphrases Hickey's article rather than reproducing its full argument, so Hickey's side is seen through the author's reading. The post's author is not named in the source text.

Risks and caveats

The author does not claim LLMs are easy to use well. Unpredictability is called a meaningful limitation, and an LLM can plainly fail to do what it is told. Unexpected outputs, failure to follow instructions and harm from access to consequential actions are described as real engineering problems. The author also accepts that the learning cost of outsourcing is real: accepting a summary instead of reading a paper can sacrifice much of what reading teaches. The post's point is that these concerns describe particular uses, not a category error about what an LLM is.

“The useful distinction is between wielding an instrument with skill and delegating work without adequate understanding or oversight.”

— From the blog post responding to Rich Hickey's article