Rich Hickey on AI: Why It Is Not a Tool?

Introduction: When the Father of Clojure Talks About AI

In the tech world, the name Rich Hickey is almost synonymous with "simplicity" and "deliberate thought." As the creator of the Clojure language, he rarely makes off-the-cuff comments on tech trends, but every time he speaks, it's worth chewing over carefully. Recently, his view that sparked discussion on Hacker News — "AI is not a tool" — at first glance looks like an attention-grabbing assertion, but in reality it touches on a fundamental question that is repeatedly muddled in today's AI discussions: what framework are we actually using to understand this technology?

(The current Hacker News original post only provides a title and a small amount of metadata. This article analyzes and elaborates based on the typical discussion directions of this viewpoint in the tech community.)

The Word "Tool" May Have Been Wrong from the Start

Hickey's core argument is not complicated: a tool is passive, predictable, and fully controllable. A hammer won't change its shape without your knowledge, and a compiler won't suddenly decide to interpret your code in a different way. The essence of a tool is to extend human intention, not to have its own intention.

The problem is that when we call AI a "tool," we are actually implying that it can be seamlessly embedded into existing engineering and management frameworks — as simple as calling an API. But Hickey hints that the behavior of AI systems has characteristics of emergence, nondeterminism, and being difficult to fully explain, and these characteristics are in tension with the classic definition of a "tool." You use a hammer, and the hammer won't give you an "approximately correct" nail.

Looking at AI's "Non-Tool-Ness" from the Philosophy of Clojure

To understand Hickey's position, we need to return to the design philosophy he has advocated throughout his life. Clojure emphasizes immutable data, pure functions, and explicit state management — the core goal is to make system behavior reason-able and predictable. Under this framework, an ideal tool should be deterministic: given the same input, it must produce the same output.

Current mainstream AI systems, especially large language models, stand exactly on the opposite side on this point. The same prompt may produce different answers; the model's internal decision-making process is difficult to trace layer by layer; its capability boundaries "emerge" as scale expands, rather than being specified item by item by the designer. Hickey's criticism is not a denial of AI's value, but a reminder: using the metaphor of "tool" to manage AI will lead to wrong expectations, wrong governance methods, and wrong allocation of responsibility.

Consequences for Engineering Management

If AI is not a tool, then the procurement mindset of "buying AI tools" is worth being wary of. Tools can be accepted according to specifications; AI systems cannot. You cannot test a model the way you test a wrench — you can only evaluate its statistical performance on a specific distribution, and failure modes outside the distribution are often unpredictable. This poses entirely new requirements for software engineering management processes, quality assurance, and risk assessment.

Out-of-Distribution Failure is a risk pattern unique to AI systems: the model performs well within the distribution covered by the training data, but once it encounters inputs that are rare in training, its behavior may degrade sharply, and this degradation often comes without warning. By contrast, traditional software usually manifests as crashes or errors outside boundary conditions — at least detectable failures. AI failures, however, are often "confidently giving the wrong answer," which is especially dangerous in high-risk scenarios such as healthcare, law, and finance. This explains why Hickey emphasizes that "AI is not a tool": a tool's failure modes can be enumerated and defended against, while AI's failure modes can only be statistically estimated and managed.

Consequences for Responsibility Attribution

When a tool fails, the responsibility lies with the user. But if AI's behavior has autonomy that cannot be fully predicted, "who should be responsible" becomes blurred. Hickey's view indirectly points to a deeper question: when we deploy AI as a tool, are we inadvertently avoiding ethical and legal considerations regarding the system's autonomous behavior?

Emergence here refers to: the system's macro-level capabilities are not specified item by item through programming by the designer, but spontaneously arise from the interaction of a large number of simple components after scale expansion. Taking large language models as an example, capabilities such as translation, reasoning, and code generation are not explicitly written into the code, but "grow" out of massive amounts of data during training. This means that the boundaries of these capabilities cannot be inferred by reading the source code, but can only be probed through empirical testing. For engineering practice, this directly impacts the traditional "specification—implementation—verification" process: if a system's behavior cannot be fully specified, then the acceptance criteria themselves lose their deterministic basis.

Nondeterminism is usually regarded as a defect in software engineering — the same input producing different outputs means the system is not reproducible and not debuggable. But the nondeterminism of large language models is not a bug, but part of their working mechanism: sampling strategies (such as the temperature parameter) allow the model to choose outputs over a probability distribution, thereby gaining creativity and diversity. This poses a fundamental challenge to quality assurance: traditional unit tests assume that fixed input corresponds to fixed output, while testing AI systems can only be built on statistical evaluation, requiring large numbers of samples, confidence intervals, and out-of-distribution detection. Understanding this point is a key prerequisite for understanding Hickey's criticism.

Community Divergence: Is This a Profound Warning, or a Semantic Game?

The discussion on Hacker News shows two typical positions.

Supporters believe that Hickey has grasped the most dangerous simplification in current AI discourse. Calling AI a tool is like calling the internet an "information superhighway" — it sounds harmless, but it conceals complex systemic effects. This way of naming directly affects policy making, corporate strategy, and public expectations.

Skeptics believe that this is merely semantic nitpicking. In human history, almost all powerful technologies were initially called "tools," and only later gradually developed independent governance frameworks. Saying AI is not a tool does not provide an alternative framework, so its practical significance is limited.

Both views have merit, but what makes Hickey unique is that he is not playing a conceptual game, but pointing out the practical consequences of a metaphor from the perspective of system design. A wrong metaphor leads to a whole set of wrong engineering decisions.

If AI Is Not a Tool, Then What Is It?

Hickey himself did not give a complete answer in his brief statement, but along his line of thought several possibilities can be inferred.

One understanding is that AI is more like a collaborator or participant, rather than a passive instrument. This means the interaction mode should be conversational and iterative, rather than command-based. Another understanding is that AI is a kind of environment or infrastructure, permeating every part of the system like electricity or the network, and its behavior needs to be monitored and governed rather than "used."

Either understanding points to the same conclusion: the existing "tool" mental model is insufficient to support engineering practice in the AI era. We need new vocabulary, new management methods, and new responsibility frameworks.

Conclusion: The Power of Naming

The reason Rich Hickey's view resonates on Hacker News is not because it provides an answer, but because it raises the right question. At a time when AI capabilities are rapidly evolving, we are accustomed to fitting new technologies into old frameworks in pursuit of psychological security. "AI is a tool" is a typical product of this sense of security.

But if this framework itself is wrong, then everything built on it — product design, team organization, regulatory policy — may need to be re-examined. Hickey's reminder is restrained, yet sharp enough: before discussing what AI can do, first think clearly about what we are treating it as.

One-line Summary

Rich Hickey argues that AI is not a tool because it has characteristics of emergence, nondeterminism, and being difficult to explain, which requires us to re-examine engineering management and responsibility frameworks.

Paragraph Summary

Rich Hickey proposed the view that "AI is not a tool," sparking widespread discussion in the Hacker News tech community. The article's analysis points out that the essence of a tool is passive, predictable, and fully controllable, while current large language models exhibit emergence, nondeterminism, and difficulty of explanation, creating a fundamental tension with the classic definition of a tool. Based on Clojure's philosophy of predictable design, Hickey warns that using the "tool" metaphor to manage AI will lead to wrong expectations, governance methods, and responsibility allocation. The community is divided on this: supporters see it as a profound system design warning, while skeptics see it as mere semantic nitpicking. The article further explores that AI may be better understood as a collaborator or infrastructure, and emphasizes the profound impact of naming frameworks on product design, team organization, and regulatory policy.