- cross-posted to:
- programming@programming.dev
- cross-posted to:
- programming@programming.dev
cross-posted from: https://feddit.org/post/36615673
Forgive the smelly domain.
This is a fantastic short essay by Rich Hickey.
That’s like saying stoves cannot be considered as tools because all you need to do with it is to either turn it on or off.
While Rich is absolutely correct that LLMs are a form of automation, I’d hazard to guess that his experience with programming is rather different from that of most software developers. Rich works on developing his own language where most of the work he does is novel and interesting, almost by definition.
However, the elephant in the room is that code mot people write day to day is rote and repetitive. Any given application will have to do some IO to talk to the filesystem, services, or a database, It’s going to need some service endpoints to expose its functionality. It might have a UI with some menus and buttons, it probably needs to do auth, and so on. It’s all just boilerplate that you have to write over and over.
This can be fun and exciting at the start of your career when you’re just learning how these things work, and you’re doing them for the first time. But once you’ve written enough of these things, it just becomes a chore that provides no intellectual stimulation. And this is precisely the kind of code that is ripe for automation. I don’t care to be intimately familiar with every line of code that goes into making a button or reading a record from a database. I’m perfectly happy to have this tedious work automated so I can focus on things that are interesting to me.
It seems to me that a lot of people create a dichotomy where you either use LLMs and farm off all your thinking to them, or you’re doing everything by hand artisanally. The reality is that you can reach for LLMs for things that don’t interest you but need to be done nonetheless, and spend your time learning and understanding things that you see value in.
all true, but you cannot hold a job with that approach. you will be fired.
this works well for people who have agency and can do this stuff for fun or have time before they lose their home to find a revenue stream.
That’s big news to me given that I’ve been using these tools at work for over a year now.
I ain’t going to that cursed place, someone copy paste the post please
‘AI’ is Not a Tool Rich Hickey
(I keep delivering this as a quip, here’s a bit more)
First order of business - is ‘tool’ going to have an interesting, distinguishing and thus illuminative meaning or be a mere platitudinous stand-in for “anything useful”?
We’ll save tool as “anyone/thing that can be exploited” for the AI titans, for whom VCs, politicians, wannabe-titan-CEOs, software devs, rural towns etc are all ‘tools’. The pockets on the front of my shirts are useful (I need to keep my reading glasses handy), but they are not tools. Similarly, fast food drive-thru windows are useful, but are not tools (more later).
Some definitions of ‘tool’:
a device or implement, especially one held in the hand, used to carry out a particular function an instrument (such as a hammer or saw) used or worked by hand : an instrument used by a handicraftsperson or laborer in their workWhat I like best - A tool is something you wield.
wield - to use (as a tool or instrument) especially with full command or power : handle, manipulate, controlEspecially useful in that are:
Held in your hand - a source of both control and feedback, and an indication of the intimacy of the act of use Power - force, energy transmission and direction, leverage etc Control - intention and continuous directing of the course of eventsTools are implements with which you do something, they do not do things for you. Tool use builds, rewards, and often requires, expertise and skill. The continuous application of technique and energy, and sensory feedback, are essential to the buildup of expertise (from experiri - “try”).
Good tools have many properties LLMs lack - they are predictable, reliable, deterministic, of bounded function, hopefully simple etc.
What you learn while wielding a tool is something about the world, the task, the physics, logic etc of what you are trying to do or the situation you are trying to overcome. And often, something about yourself. Recommended by LinkedIn
As a lifelong tool builder and user, I know what tools are. LLMs are not tools.
Control, sensory feedback, intention, intimacy, continuous direction, expertise etc are all missing from LLM use. LLMs are not wielded. LLMs are automation.
automation - (of a device or process) working by itself with little or no direct human control.A drive-thru is not a tool for cooking, it is automation for avoiding cooking. LLMs are not tools with which you write code - they are automation with which you avoid writing code, to which you abdicate writing code.
You don’t direct the action of an LLM - you make requests and it acts on its own, without your energy or continuous direction. This request/automation cycle is not wielding, it’s not control, it’s not continuous, it’s without feedback.
What you are doing while using automation, instead of learning real-world truths, is attempting to divine the details du jour of some automaton. And striving to game them - e.g. ordering a custom burger (no onions) in order to get a freshly made one. Or filling voodoo.md with just the right incantations. You are only a software update from everything you’ve ‘learned’ being rendered obsolete by the latest algorithm. (A soggy cold burger from which the onions have been removed) You have traded working with the world to working for a capricious robot.
It is a mistake to be haphazard about “tools” being equivalent to utility, e.g. saying - “the LLM didn’t write my paper, I just used it as a tool to read and summarize some research papers”. But you didn’t wield it to read those papers (as you might a Kindle). It read the papers, not you.
What do you miss by abdicating doing the reading? Pretty much everything. First and foremost, you miss learning how to write from those who can. You miss learning how to formulate an argument. You miss noticing things. You miss loading your background mind with fodder for novel ideas. You miss building trust in some authors and suspicion of others. You miss all the jokes. You miss all of the edges. You miss learning how to think.
Tools don’t get “misaligned”, they don’t “go rogue”, they don’t “escape containment”, “conspire” etc.
LLMs are not tools. I know many people use the phrase “just tools” simply to indicate “they are what you make of them”. Except that’s not true. Automation has intrinsic properties and differences from tools that you ignore at your peril.
Rich
I’m for being against LLM, but I am also for using logically sound arguments. I find a far better argument against using it as a developer is: https://arxiv.org/pdf/2506.08872
Some logical fallacies I see in that writeup:
- Gerrymandered definition
- False dichotomy
- Strawman
- Slippery slope
- Appeal to authority
I won’t go into all of thwm cquse most are boring. But here is some of my thinking.
This one irks me personally the most:
“As a lifelong tool builder and user, I know what tools are.” This is an irrelevant conclusion. Expertise in building tools doesn’t settle a definitional question, and the essays argument still has to stand on its own criteria.
For now, lets accept his definition of a tool and some of the arguments he uses and apply them to some other aspects of computing:
A computer is not held in the hand in any meaningful sense, transmits none of your force, and involves no continuous direction. You enter an expression and it “acts on its own.” By Hickey’s definition, a comouter is “automation for avoiding arithmetic.” or “automation for decoding a binary stream from the internet wire and rendering it in your own mind as a website”. Nobody that uses computers has hesitated to call it a tool for computation. And nobody thinks it makes the user less of a professional while using them.
Lets do another one, closer to the topic of programming: A compiler. You hand it source code, it acts entirely on its own, and under Hickey’s logic it is “automation for avoiding translating to machine code.” Yet the compiler is the pardigmatic programmer’s tool, and nobody claima programmers who use compilers failed to learn programming. If “acts on its own after a request” disqualifies an LLM, it disqualifies half the toolchain that built the software the essay was presumably written in.
Good tools have many properties LLMs lack - they are predictable, reliable, deterministic, of bounded function, hopefully simple etc.
These are all things that LLMs have but are typically stripped or hand-waved away for the sake of convenience or ease of use.
Predictability? Reliability? Deterministic, bounded function? The same seed pushed through a model’s weights ends with the same output. You can change the behavior for how the weights are processed, what tokens are more important than others, etc.
Simple they are not and likely won’t be, but most models are way more controllable than most people realize. The problem is the thing that makes them interesting in novel isn’t what we can control about them, it’s about what’s not controlled. The fact that they can produce seemingly novel information is the thing everyone wants to sell, and what everyone thinks they want to buy.
AI (in as far as an LLM is concerned) is a tool being sold, bought, and discussed as if it was something more than what it is, and articles like this don’t help the fantasification and anthropomorphization of them.
LLM by nature, cannot be, and are not deterministic.
LLMs are a stochastic tool that generalizes patterns imprinted into the neural network during training. And then these patterns are expressed in the given context during inference. The stochastic aspect is what makes it possible for the LLM to adopt generalized training to the specific problem being solved. So, the outputs LLMs produced are not random in a sense of playing bingo because randomness is not the dominant property of the system. It is predicting the most likely next token within the given context.
I think this is a gross misunderstanding of the underlying tech. The probability distributions are fixed at training time. That is why the weights are static. When doing inference, models are selecting from a top-k of probable tokens at each autoregressive loop for your typical LLM. When you adjust top-k to 1 or simply set the “temperature” to 0, it will always give you the same result from the same input.
Something is deterministic if given the same conditions and inputs it produces the same output.
If you give an LLM the same parameters, seed, and prompt, it will produce the same output.
That’s certainly deterministic. As deterministic as any other procedural generation of content.
I appreciate he’s upset with novel tech and tooling but after reading that: he’s the tool.
Agreed, by his definition a word processor or IDE, or even an operating system is not a tool because you aren’t directly controlling it.
Or filling voodoo.md with just the right incantations. You are only a software update from everything you’ve ‘learned’ being rendered obsolete by the latest algorithm.
Ok but software engineering is filling voodoo.cpp or whatever with the right incantations, and if a new c++ version with drastic changes comes out, much of what you learn can and will be rendered obsolete.
If he wanted to focus on anything it should have been the non-deterministic property of LLMs. How the same input does not generate the same output.
His tool claims here a bit weird in contrast:
https://www.linkedin.com/posts/richhickey_state-of-clojure-2025-activity-7409248120905076736-7fXW
We seem very much into the world of old men shouting at clouds.
He should wrestle Iris on the matter:
https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool
Yeah, the text reads horrible, I had a feeling he wanted to write something profound, but wrote a total slop instead (there is an irony in there)…
I do not want to cite Hickeys text because it is brilliantly written and grabbing some phrases would diminuish it. Go and read it.
The tl;dr of his argument is this: “Tools” are something that we fully and directly control and that enhances our abilities. Large Language Models are neither.
I think that is the whole issue. AI should be used as a tool to enhance our skill, instead people are using it as self sufficient entities, the result of which are burnt tokens and unmaintainable and buggy code. Same is valid for other areas. Instead of letting it generate an email - a wall of text that has to be interpreted by another llm - maybe use it to check on your grammar or suggest changes in the text you write.
Is it true that more experienced / knowledgeable / capable people, if at all, have more of an advantage from it, than juniors?
And on the other hand, it seems to me that these things are designed to take things out of our hands - “let me write that difficult email for you”, and so on…
Yes it is true. AI gets better if you know the right questions to ask. Inexperienced people ask the wrong questions because they don’t know the pitfalls.
It’s such a bad experience to have to read ai written emails. I would rather read short grammatically incorrect email than formally well written novel from llm. Write your email, ask ai to fix grammar or check formal vs informal phrases and send it, you will do a favor to your recipient and on top of that you will learn something.
Is it true that more experienced / knowledgeable / capable people, if at all, have more of an advantage from it, than juniors?
100% true. The kids using clankers to write code didn’t cut their teeth on all of the subtle code flaws that can creep into your own hand-written code if you didn’t have a good understanding of the problem to begin with. Clankers pick the most pedestrian, mediocre solutions possible if you let them because the vast majority of code that can be scraped for training data is pedestrian and mediocre.
At work, I review what the juniors generated with the clanker and constantly find shitty things they missed (eg. I found they had added a boolean argument to a function and passed it all the way down a very long call chain so they could do a branch somewhere stupid. note that boolean wasn’t used anywhere else). These are also the kind of people that will create single call site private methods in classes that makes it impossible to grok a piece of code without the doorway effect because they cargo culted the idea of DRY. All of this shit is in the training data because most of your software engineers are also on a normal distribution and most of them suck. So yeah, giving kids access to clankers is a recipe for shitloads of re-work and wasted tokens. Kids can’t catch the clanker fuck ups because they’ve never seen them before.
I would say yes. I have colleagues who have a hard time solving some tasks with an agent. Then I take a stab at it and succeed almost immediately. We both have the same freedom to choose and customize the available tools, but apparently my setup and usage is better.
“let me write that difficult email for you”
Honestly I like this one because people don’t appreciate the brief nature that I write in. I draft a message and then let AI rewrite all the feel good stuff people want to see.
What are they then? A medium?
Thanks for the tldr; As a semantic argument I agree with the first commenter in the article, it goes too far.
Managers sometimes refer to their employees as tools, and they don’t fully control them either. Plenty of more cleanly defined tools (explosives, guns, chemicals) can have unintended consequences if used without proper controls, training or care.
I used the term “AI is a tool” at a meeting yesterday, and I will again.
(Minor grumble: Eww, Linkedin. Having visited the site again I know I’ll get a bunch more spam and targetted adverts for a few weeks)









