Rich Hickey’s AI Argument Reignites Debate Over Tools, Automation and Human Judgment

Rich Hickey’s argument starts with a definition: a tool is a device or implement that a person actively wields to perform a particular function. Under that standard, he argues, large language models are better understood as automation than as tools. The distinction matters because calling AI a tool can make its social and technical effects sound familiar, manageable and mainly dependent on user intent.

The debate has spread beyond Hickey’s original essay. Critics and commentators describe AI as an environment, an automated service, or a system that changes the conditions under which people learn and work. Across those views, the central dispute is less about whether AI produces useful output than about what happens to human judgment when the production process is delegated.

Hickey’s case rests on the difference between wielding an instrument and requesting a result. A saw, chisel or programming language remains under the operator’s direction at each meaningful step. An AI system instead accepts an instruction and returns a completed artifact, often without exposing the reasoning, intermediate decisions or failures that produced it.

That separation makes AI resemble an automated service, Hickey argues, rather than a conventional implement. His broader philosophy of software development emphasizes spending time understanding states, transitions and failure modes before writing code. A system that supplies instant code can shorten the visible work while also removing the struggle through which developers build the context needed to inspect and repair it. Karangoyal’s discussion connects this concern to Hickey’s “Hammock Driven Development” idea, while the original essay frames usefulness as too broad a definition for the word tool.

A competing view holds that automation and tool use can coexist. An LLM can be directed, tested, rejected and corrected by a human, and those activities require real skill. The quality of an AI-assisted result depends on how well the operator frames a problem, evaluates feedback, detects mistakes and revises the request.

That argument compares language models with familiar tools whose value also depends on the user. A saw doesn't guarantee a straight cut, and a chisel doesn't make someone a sculptor. The analogy gives AI users a clear responsibility for verification, but it also has limits: software that generates a finished answer can conceal more of its internal process than a physical instrument. The disagreement therefore turns on where agency sits, and whether oversight after generation preserves the learning that came from doing the work directly.

The strongest challenge to the tool metaphor treats AI as an environment rather than an object. Michael Sacasas describes people as operating inside an AI-shaped setting, alongside the wider network of digital media technologies. That framing shifts attention from individual prompts to institutions, defaults and habits that influence what work gets assigned, measured and rewarded.

Other critiques make a related point from software practice and public accountability. Describing AI as “just a tool” can shrink questions about training data, labor, energy use, generated code, corporate responsibility and the consequences of deploying unreliable systems. The phrase also places moral responsibility almost entirely on the user, even when product design and commercial incentives steer behavior. For developers, the practical issue is whether AI remains an optional instrument or becomes infrastructure that quietly sets the pace and shape of work.

The stakes are highest where producing an answer and learning how to produce it are different goals. AI can reduce the time needed to draft code, text or analysis, but speed doesn't guarantee understanding. When generated work fails, the person who accepted it still has to diagnose assumptions, trace dependencies and explain the result to colleagues or customers.

That creates a split between short-term productivity and long-term capability. Hickey’s position emphasizes the lost opportunity for deliberate thought; the opposing position emphasizes the skill involved in directing and reviewing a model. Both place judgment at the center, though they locate its most valuable moment differently. One prioritizes reasoning before generation, while the other treats prompting, feedback and correction as a new form of craft.

Developers need to distinguish assistance from delegation. AI-generated code can support exploration, boilerplate production and routine transformations, but teams still need clear ownership of architecture, testing, security and maintenance. Review practices that inspect only whether code runs will miss errors in assumptions, interfaces and future behavior.

The broader debate also points to a design question for AI products: should systems expose more intermediate steps, constraints and uncertainty, or optimize mainly for polished outputs? Rich Hickey’s critique favors preserving the thinking that precedes implementation. The tool-use response favors disciplined interaction and verification. The practical conclusion is that AI adoption should be judged by whether it strengthens a team’s understanding and control, not simply by how many keystrokes it removes.