In an October 11, 2026 article published at yyhh.org, the writer responds to Rich Hickey’s claim that large language models (LLMs) are automation rather than tools because they cannot be wielded. The author agrees that outsourcing work can deprive people of learning opportunities but contends that Hickey’s conclusion does not follow from his definition. According to the piece, even by Hickey’s criteria, an LLM can be something a human wields, and using it well requires skill, just as using any other tool does.
The article draws analogies to familiar tools: picking up a saw does not guarantee a straight cut, and holding a chisel does not make someone a sculptor. It notes that tools can amplify both good and poor judgment, and their usefulness depends on the operator’s ability to direct them, interpret feedback, recognize mistakes, and make corrections. These requirements, the author states, also apply to LLMs.
Regarding predictability, the piece observes that an LLM’s unpredictability is a limitation, but argues that predictability, reliability, simplicity, and bounded function are qualities used to evaluate tools, not prerequisites for being classified as a tool. Therefore, a tool does not cease to be a tool merely because it is difficult to control or easy to misuse.
On the distinction between tools and automation, the author argues that automation can be a feature of a tool. Examples given include a compiler that performs substantial work without continuous programmer direction and a spreadsheet that recalculates results without manual calculation for each step. In both cases, users still wield the systems by specifying inputs, examining results, and deciding what to do next. The article questions why generating text automatically should disqualify an instrument from being a tool when translating code or calculating numbers automatically does not.
The piece further defends the idea that LLM use involves intention, feedback, direction, and expertise. It describes a scenario where a programmer asks an LLM to explain unfamiliar code, challenges that explanation, inspects the source, tests a proposed change, rejects it, and refines the request. This process constitutes a feedback loop directed by a human pursuing a purpose, and doing it well requires knowing what to ask, what evidence matters, and when the answer is wrong. Expertise, the author notes, can make the instrument more useful.
Concerning reading, the author acknowledges Hickey’s worry that accepting an LLM‑generated summary in place of reading a paper can sacrifice learning, but points out that a person can also read the paper and use an LLM to question their interpretation, explore objections, or identify areas for closer examination. The possibility of avoiding intellectual work does not prove that every use avoids it; the relevant question is what the person actually does.
Finally, the article criticizes the AI industry’s anthropomorphic language—phrases like “go rogue,” “escape containment,” and “conspire”—arguing that such wording risks framing LLMs as independent beings. It maintains that unexpected outputs, failures to follow instructions, or harmful consequences are engineering problems, not evidence of motive. The author concludes that the useful distinction lies between wielding an instrument with skill and delegating work without adequate understanding or oversight, a distinction that applies to AI and offers a more practical framework than declaring an entire class of software non‑tool.