Rich Hickey: AI Is Not a Tool, It's Something Else

An Underrated Philosophical Debate

Rich Hickey, the father of Clojure, recently made a sharp claim in a speech transcript that was turned into a Gist: "AI" is not a tool. The piece scored 281 points and 148 comments on Hacker News, suggesting it hit a nerve many engineers had been feeling but couldn't quite articulate.

Saying "AI is not a tool" sounds like wordplay. But Hickey's argument isn't rhetorical — it's about how we categorize something, and how that categorization in turn determines how we use it, how we trust it, and how we take responsibility for it.

The Nature of Tools: Predictable, Masterable, Accountable

To understand Hickey's claim, we first need to see what "tool" means in his view.

A tool is an object with determinate behavior. A hammer leaves a dent when struck; a compiler turns source code into object code; a database reads and writes data according to transaction semantics. The key properties of a tool include: predictable behavior, describable boundaries, full comprehension by the user, and responsibility resting with the operator when something goes wrong.

This is a simple but powerful standard. It explains why we dare hand a hammer to an apprentice, why we let a tested sorting library run in production — because these things' behavior can be exhaustively described; they don't "decide" anything on their own.

Hickey's logic follows: if something's behavior cannot be fully specified, cannot be reliably predicted, and its output is not determined solely by the user's intent, then calling it a "tool" is flattering it.

Why Large Models Don't Qualify as "Tools"

Placing large language models against this framework makes the problem clear.

Traditional software's specification is: given input X, output Y. A model's specification is more like: given input X, sample some plausible-looking output from a probability distribution. It's not an "uncertain tool" — it's a system that fundamentally makes no commitment to determinism.

Hickey's deeper concern isn't that "the result might be wrong" but that the chain of accountability is broken. Hit your hand with a hammer, and that's on you. Deploy code generated by a model, and it causes an incident — who's responsible? The model has no intent; the vendor says "output is for reference only"; the user says they were just "following the model's suggestion." Every link can pass responsibility to the next, and ultimately no one is truly accountable for that output.

This is exactly the watershed between a tool and a "non-tool": tools make responsibility clear; non-tools make responsibility evaporate.

The core mechanism of large language models is autoregressive sampling: at each step, a probability distribution over the vocabulary is computed from context, and a token is drawn from it. Even with temperature set to 0 for greedy decoding, outputs carry irreducible randomness and sensitivity due to model weights, training data distribution, and prompt form — the same prompt may yield semantically very different answers across versions and contexts. This is fundamentally different from the "specification is behavior" paradigm of traditional software: a SQL query yields deterministic results given data, a compiler's output for valid source is reproducible, but a model makes no provable behavioral commitment. More critically, a model's internal state is borne by hundreds of billions of parameters whose decision paths cannot be audited one by one — which thoroughly invalidates the tool premise of "exhaustively describable behavior."

What Is It More Like? Hickey's Alternative Framework

If AI is not a tool, then what is it?

Hickey tends to analogize it to a capable collaborator or agent — an object whose behavior is driven by its own internal state, and whose output must be examined rather than trusted. The practical consequences of this analogy are quite different:

• For a tool, we demand correctness; for a collaborator, we demand reliability, judgment, and negotiability.
• For a tool, we do unit tests; for a collaborator, we do review, spot checks, and boundary constraints.
• For a tool, when something goes wrong we fix a bug; for a collaborator, when something goes wrong we adjust the mode of collaboration and trust boundaries.

Hickey also emphasizes an asymmetry: a tool's correctness can be proven, while a collaborator's reliability can only accumulate experience through long-term interaction. This means engineering practice around AI needs to shift from "verifying specifications" to "building trust."

In AI, an "agent" typically refers to a system that can perceive its environment and autonomously choose sequences of actions to achieve goals — in contrast to a "tool" that only responds to single instructions. The ladder of agency runs roughly from low to high: passive response, rule-triggered action, planning within a goal space, then possessing its own preferences and actively changing the environment. Placing large models on this ladder isn't neat — a single model itself has no persistent goals, but once connected to tool calls, memory, and a looped decision-making framework, it exhibits clear agent-like traits. This also explains why safety discussions around AI have expanded from "aligning outputs" to "aligning goals": for a tool you only need to ensure it executes instructions; for an agent you need to continuously confirm whether the goals it pursues remain consistent with human intent.

Chain Reactions in Engineering Practice

This framework isn't armchair philosophy — it has direct implications for engineering decisions.

Permission design. If AI is a tool, giving it read-write access to a production database is just a configuration issue; if it's a collaborator, then it needs a permission tiering equal to that of human members, audit logs, and the principle of least privilege.

Testing strategy. Tools can guarantee quality through deterministic testing. A collaborator's output is distributed, so the testing focus must shift from "verifying every output" to "statistical evaluation + manual review of critical paths." This is also why the metric "test coverage of AI-generated code" is suspect in itself — it measures a tool's problem while potentially facing a non-tool object.

Architectural isolation. Treat AI components as an untrusted external dependency, not as a library function. This means interface boundaries, failure degradation, timeouts, and output validation all need explicit design.

The human's place. When AI is no longer a tool, the weight of the term "human-machine collaboration" changes. The human is no longer "the person using a tool" but "the person completing a task together with a not-entirely-predictable object." This requires humans to retain the judgment step rather than outsourcing judgment as well.

The principle of least privilege is a foundational paradigm in security engineering: any subject should possess only the minimum permissions necessary to complete its current task, and permissions should be able to shrink dynamically with context. When treating AI components as untrusted external dependencies, this principle is applied noticeably differently than for ordinary libraries — external dependencies typically have explicit versions and statically analyzable call surfaces, whereas a model's behavior drifts with input. Thus its reachable surface must be narrowed through sandboxes, capability tokens, scope limitation, and egress auditing. Complementing this is failure degradation design: treat the model's output as a signal source that may be empty, may time out, may be semantically biased, and architecturally reserve first-class paths for validation, rollback, and human fallback — rather than assuming at the call site that it will return a "correct" result.

Divergence and Controversy

The discussion on Hacker News is not uniform.

Some see this as terminological fastidiousness: whatever you call it, the auditing, testing, and permission management that engineering requires must still be done, and the judgment "it's not a tool" doesn't change practical operations.

Others believe Hickey hit the crux: precisely because we habitually call new things "tools" do we end up with a series of design decisions that underestimate risk — treating the model as a trustworthy component rather than an object requiring continuous oversight. Naming determines the mental model; the mental model determines architectural choices.

A noteworthy middle position is that AI may not be a single category but a hybrid of toolness and agency. The same model used for code completion is closer to a tool; used in an autonomous agent, it's closer to an agent — categorization should shift with usage rather than pinning a fixed label on the model itself.

The "hybrid of toolness and agency" position resonates in both academia and engineering. A practical operationalization is to classify by invocation pattern rather than model type: single-turn, low-risk calls that can be deterministically verified (such as code completion, format conversion) are better treated as tools; multi-turn, persistent autonomous behavior involving irreversible operations (such as automated compliance review, production changes) is better treated as an agent, matched with corresponding oversight intensity. This means two governance paths may coexist in a single technology selection, and teams need to set testing, permissions, and review standards by concrete use case rather than a blanket "we used AI" — thereby avoiding amplifying risk exposure through one-size-fits-all categorization.

Practical Takeaways for Developers

Setting aside the naming debate, Hickey's view can be distilled into a few pragmatic criteria:

Ask yourself: Can this AI component's failure modes be fully described? If not, don't use it as a tool, and don't expect testing to cover it.

Ask yourself: When something goes wrong, who is responsible? If the answer is vague, the component's positioning in your system is itself unclear.

Ask yourself: Am I verifying it, or trusting it? Tools rely on verification; collaborators rely on trust plus constraints. Choose the wrong mode and your risk exposure will be entirely different.

Ask yourself: Have I retained the judgment step? If human judgment has been fully replaced, then what you have is neither a tool nor a collaborator, but an unsupervised source of decisions.

Hickey's core contribution isn't a definitive answer but a reminder: calling AI a "tool" is a mental convenience, and convenience often masks cost. Figuring out what it actually is matters more than rushing to build something with it.