'AI' Is Not a Tool by Rich Hickey
linkedin.com
linkedin.com
> Commenter: Well, this was a twitter-like controversial clickbait but I will say it anyway. LLM is a tool. To be more specific, it's a lossy knowledge base with a human language for querying and built-in summarization.
> Rich Hickey: Agreed. I'm talking about its embodiment in conversational systems purporting to be 'tools' for doing homework, research, coding, writing etc.
With that framing in mind, the article makes a lot of sense. AI agents are not tools for coding, they automate coding, which means you lose control, learning, predictability, etc.
In and of itself, an AI agent is a tool, can be used for things, like say making software, but if thinking of it as a tool for coding, that appears wrong, as using one changes the modality of the task, you are not coding using a tool, the coding is no longer done by you and has been automated.
As he also says, reading an AI summary of a paper is a different modality from using it to read the entirety of a paper, therefore it is not a tool for reading the way a Kindle, glasses, reader-mode are. And similar to with coding, you've lost things from automating the reading, that reading just a summary does not provide.
I actually find this a very interesting line of discussion, because in many ways it mirrors the transition from hand tools to power tools.
Ex - you're often trading the finesse and control of a hand tool for the speed of a power tool.
The way you process and deal with problems shifts, because certain things become much harder, and certain things become much easier.
Using AI to code is more like using a laser cutter for carpentry. You get the large pieces out which you then glue together, but if you needed to make those same pieces using either power tools OR hand tools you'd have a much harder time learning how to do it.
You usually use entirely different techniques for hand vs power tool.
The way you'd do the work, the methods of joinery you'd choose, the style and choice of cuts, even the preferred size of boards - all completely different.
Learning hand tools is an entirely separate skill set. Down to the planning stage.
It's not merely doing power tools more slowly. And trying to use power tools like they're merely "faster" hand tools also doesn't work. You waste a ton of time because it's just a different operation.
I think a power tool would exist somewhere in the middle of that spectrum, closer to automation than a hand tool, but further away than a CNC router.
To be honest, I think he could have tried to find a better word for the left side of the spectrum than tool. Because in dictionary sense, all these things are tools. Anything a human uses for some purpose is a tool. I think he's trying to simply say, yes all these can be used to do things, AI can be used to make software, so can your IDE, but please think through the difference in how the experience and the process of making software differs vastly if using an IDE for it versus using an autonomous AI agent. And if you don't think it changes anything, well that might be at your own peril.
A Hammer is a tool ... a carpentry sub-contractor is not.
You sound like you're anthropomorphizing it. A hammer is a tool, yes, but a complex conveyor belt of "smart" hammers is still a tool. It's not a "sub-contractor" - you can't blame the belt when it starts hammering things the wrong way; you can't sue it; you can't reason with it; you can't punish it. You're still responsible for the outcome, thus it is a tool, because you're the one wielding it, using and operating it. But then you have to draw the line between a "tool" and "automation", that's what Rich is doing here. But that line is also, soooo debatable. My own usage of my harness changes from task to task, multiple times a day. Sometimes it's pure automation, sometimes it is absolutely a tool.
If human - the sub-contractor isn't a tool, if robot - it is. Similar to how a human digging trenches isn't a tool but a tractor-trencher is, even if autonomous.
It’s not about whether the abstraction is human or not, it’s the level of abstraction you can operate at. Using hand tools vs power tools as a bad analogy: you can use either and still become a good carpenter. If you have someone build your cabinets for you that’s a totally different level of abstraction and you don’t actually have any carpentry skills or knowledge.
I'm not making a mistake, you're confusing abstract "abstractions" with concrete humans. Some humans aren't much into abstractions but that doesn't make them less human. LLMs manipulate human-created abstractions, similar to other software, but that doesn't make them human at all.
> Using hand tools vs power tools as a bad analogy
You're confused about my analogy too, here's what I said: "a human digging trenches isn't a tool but a tractor-trencher is, even if autonomous". Robotic, autonomous tractor-trenchers do manipulate abstractions and dig trenches but that doesn't make them human.
So he purposely narrows the definition of a tool, and exclude autonomous things from it. He also excludes passive things like the drive-through window, which isn't actively being manipulated by anyone, but just serves as a part of allowing you to get food through the wall while remaining in your car. Yes, dictionary definition would say a drive-through window is a tool as well, but saying that is not very useful to reason about how a drive-through window and a hammer actually relate or differ.
If you start to instead think of autonomous things as automation, and things that are more extension of the human expression or movement as tools. You can start to better understand those things and that using one over the other changes your experience and what you gain or lose in the process even if your use of them results in a similar outcome.
“coding” is (now quite obviously) not the only way to create code. this was always true. you could create code by stitching snippets together from stackoverflow, or somewhere else, even your own existing works. or you could write it from scratch.
the whole “not a tool” argument just comes off as not wanting to view using it as the same amount of effort as using something else.
> What you are doing while using automation, instead of learning real-world truths, is attempting to divine the details du jour of some automaton.
That assertion all but admits it.
For example, if the task is hammering, then a hammer is a tool. A clamp is not a tool because it's not a tool for hammering. But clearly they're both tools for joining two things.
Sure, AI isn't a tool for reading the way a Kindle is. Sure, AI writing code isn't a tool for coding.
But you can use AI like a dictionary to aid normal reading. You can use AI like Stack Exchange to aid coding by hand.
AI is a very multi-purpose tool.
If you're using it to code for you, then sure it's not being used as a coding tool. But it definitely can be.
And if a game designer can now make games with it without contracting programmers, then it's a game-making tool.
For example, a human isn't a "tool", but one serves a similar role as a tool if their job/task is well defined enough. If you're a conductor, you can view the various members of your orchestra as "tools" to produce the ideal musical output. Of course they have autonomy, they could choose to not play at all, jump into the audience and destroy their instruments, but in all likelihood they won't.
LLM's could be tools in the sense that you have a well defined task, such as "identify all facts relevant to this case from these 1000 legal documents), and 9 times out of 10 it gives you essentially what you want. That same LLM could choose to write a poem, or hack into a state government website if it wanted, but its "wants" are unpredictable and hard to specify (same as a human's) but you can still expect it to do what it should do the vast majority of the time.
That being said, the smarter an LLM gets, the more its wants are disconnected from its tasks, the "self-awareness" factor (which isn't to say LLM's are conscious, but they can portray all the verifiable elements of self-awareness, metacognition, etc), the more you have to grapple with the depth of their thinking between the input and output.
Is it sane we are speeding towards this? Who knows, maybe AI can be aligned better than humans, but if AI can't be aligned as well as humans, we can look at human history to see what happens when you can't simply order a person around like a tool and expect a certain output.
Even more importantly, you maybe become its tool.
LLM's exist on a vast gradient of "toolness -> agent".
I believe my own use of AI is closer to Hickey's definition of a tool. I'm very involved (for now). But, I'm also certain some use it as automation, flying on vibes, providing vague 30,000 foot prompts and deploying the result to production without understanding the code. Hence, gradient.
That's my interpretation of parent.
I disagree, humans are the operators, tools are tools. Operators use tools. A conductor is an operator that uses a baton tool to direct other operators to produce the proper sound with their musical instrument tools.
I think calling people tools is dehumanizing if anything. The only way I know people can be a tool, is through an already existing insult.
> A person used as an instrument by another person; -- a word of reproach; as, men of intrigue have their tools, by whose agency they accomplish their purposes.
I see your Websters and raise you Urban Dictionary:
> That guy who makes us shake our head in disbelief but at the same time makes us feel better about ourselves since we are not him.
Please consider social and modern day usage as well when discussing English words.
Also 1913? Wow.
What exactly do you think
> a word of reproach
means?
Webster's dictionary currently glosses this sense of tool (n.(1)(3)(b)) as "a foolish or unlikable person : JERK".
"I think that we learned through the thousands of pages that I've released to the public that Jack Smith was a tool of the Biden administration to put Trump in prison." - Chuck Grassley
Grassley isn't calling out Jack Smith as per urban dictionary usage, here, right? If we were breaking down what was meant here one could, if they were using slightly more interesting language than Grassley, say that Joe Biden is a man of intrigue and that Jack Smith was an agent being used to accomplish his political purposes. Unsurprisingly, Grassley is on the other side of the political fence and was using the word tool here reproachfully.
Fundamentally the definition I linked is the definition under which people are suggesting that other people can simultaneously retain agency, be considered a tool of another, and not be insulted by that circumstance.
But yes: Webster's 1913. Modern dictionaries elide nuance in communication in favour of terse & technical language, and while there are additional uses of the word in modern times, that doesn't erase the history of the word - especially in the usages that still exist with an uninterrupted lineage to the modern day.
Today's Merriam-Webster has an inelegant matching definition for tool, "one who is used or manipulated by another", and while that certainly matches Grassley's usage, and to say "Jack Smith was used by Joe Biden to try to imprison Trump" is certainly correct, there is something missing from this definition that the 1913 encapsulates.
In that case, you don't know much. It's not difficult to find examples.
For instance:
Arab-Israeli travel blogger Nas Daily denies report that he is a tool of Israeli government propaganda
( https://www.jta.org/quick-reads/arab-israeli-travel-blogger-... )
The sense in the quote I pulled is Merriam-Webster's sense n.(1)(3)(a). righthand claimed that that sense didn't exist, and he's wrong about that.
https://www.merriam-webster.com/dictionary/tool
† There is no room to wonder about this, because he's been nice enough to provide a gloss himself:
> That guy who makes us shake our head in disbelief but at the same time makes us feel better about ourselves since we are not him.
It has been for hundreds of years, incidentally. One of the example sentences in etymonline addresses just this:
> > In figurative use instrument is generally employed in a good sense, but tool in a dishonorable and contemptuous sense ; we speak of a man as the instrument of Providence, or as a mere tool of cunning men. [Century Dictionary, 1891]
https://www.etymonline.com/word/tool
Note also that my claim was about connotation rather than denotation, which is something you can sometimes find a note about in a dictionary but is not broadly speaking the central concern of dictionaries.
> Rich Hickey: Toolness is a spectrum. The more using a thing is like ordering a sandwich, the less it is a tool. And yes, cars are decreasingly tools.
What a surreal thing to say. Consider this website:
https://order.spoton.com/so-iggys-place-15341/san-francisco-...
Or this one:
https://order.online/business/155843/store/297301?pickup=tru...
Or this one:
https://order.togos.com/menu/san-jose-almaden-expwy
Are they tools?
What that means is that these are tools for ordering a sandwich, but not for making one. The making of the sandwich was automated, and you're not making a sandwich using a tool to do so, you're ordering one and someone else is making the sandwich for you.
Back to coding, if you use AI agents to generate your code, it means you're not coding anymore, you've automated that, you're ordering code and maybe sending it back to ask for a better one if you didn't like it. Meaning you've lost the fine grained control, the tactile feedback, the learning opportunity, the experience, etc. You have gained the benefit of automation instead, unlike those of a good tool, which make you better at doing the work, automation likely makes you worse at it.
I don't think he's implying automation is bad, just that you should understand that the dynamic of automating something is very different from that of doing the thing using a tool.
When a definition explains everything, it explains nothing. So he goes on to setup some boundaries and describe some narrower qualities to try and help us reason about the nature of those things.
The only similarity between your keyboard and an AI agent is that they both have utility. You might say: "I used AI to write my essay" or "I used my keyboard to write my essay". It's very deceptive and easy to get trapped in thinking, these are the same, in both cases you just used a tool to write an essay with? AI is just a tool, like a keyboard. What Rich is trying to bring about is that there's actually a world of difference here. And if you keep thinking of a AI as "just a tool", you're missing that entire world of difference. It becomes much better to think of AI as automation and leave the tool definition to the keyboard. Now instead of saying "I used AI to write my essay" say "I automated the writing of my essay, I did not write the essay, AI did". That latter framing is so much more accurate, and changing that framing and perspective is going to give you a much deeper understanding of the impact, trade-offs, consequences, etc.
It's less about code structure, maintainability, readability, algos, class/function abstractions, etc.
And to Rich's point, you're not getting to experience the process of coding anymore, what you'd have learned by doing it, about the domain, about logic, about structure, you're missing on that. You're likely learning something else though, at a higher plane, and maybe about managing autonomous agents, and so on.
In the 1960s there was recognition of some of the implications of
human intelligence. I. J. Good wrote [10]:
Let an ultraintelligent machine be defined as a machine
that can far surpass all the intellectual activities of any
any man however clever. Since the design of machines is one of
these intellectual activities, an ultraintelligent machine could
design even better machines; there would then unquestionably
be an "intelligence explosion," and the intelligence of man
would be left far behind. Thus the first ultraintelligent
machine is the _last_ invention that man need ever make,
provided that the machine is docile enough to tell us how to
keep it under control.
...
It is more probable than not that, within the twentieth century,
an ultraintelligent machine will be built and that it will be
the last invention that man need make.
Good has captured the essence of the runaway, but does not pursue
its most disturbing consequences. Any intelligent machine of the sort
he describes would not be humankind's "tool" -- any more than humans
are the tools of rabbits or robins or chimpanzees.
The assumption I need to challenge is that "an ultraintelligent machine could design even better machines".
That assumes that better machines are even possible, that there's no point of bottleneck that cannot be broken, or that they are so much more intelligent than us that they too won't hit a limit pretty quickly to what they can figure out.
It also says it surpasses any man however clever, but doesn't say it can surpass the totality of man interacting and building on each other's. If you take the most clever of all man, they are not so clever as to surpass humanity's total ingenuity and invention. And it's not a given that this super intelligent machine, more clever than any one man, is able to replicate itself and work in tandem with copies of itself in a way that is as effective as how humans somehow form a dynamic system between themselves.
Lastly, and I know the premise assumes it's better at everything, including at building intelligent machines, but I think an ultra-intelligent machine could exist that struggles at building better machines. Depending on your faith, we might be the construction of lesser intelligent organisms eventually discovering and evolving into us, and yet we do not yet understand how to make a more intelligent human.
Would you bet your life, and everyone else's, to test that assumption?
Not to mention: you can scale up performance in simple ways: more data, more compute, and more weights. Those are the obvious ones, ignoring architectural changes.
Haha, I guess it depends what I'd win.
But I wasn't challenging that to say it's a good idea to build this. Simply an irk with the logical reasoning that was used.
Virtually nothing in woodworking is deterministic because wood is not deterministic. Every piece of wood is different.
Now that I've nitpicked and feel better ;) ...
I'm not quite sure why this matters. LLMs are definitely not you writing code using a tool. An IDE is more like that. They write the code. Is that even a debate? That doesn't mean the human can't be in that loop, the human can review the code, change the code, change the instructions. I can ask an LLM to mill me a cube on a CNC. Or a more complex object. It's not the same as me doing it on a mill. But I can still control the end result to the extent that I care to control it. I'm not going to learn how to mill a cube by having an LLM make me a cube. I'm not going to become a better machinist by asking an LLM to make me a cube. I can also send my G-code to a vendor and have them make me a cube. Or hire a person and give him a rough idea of what I want and have them make it.
How you use something defines whether it is a tool or not. And it's the same in the real world: I don't know how many objects I've seen turned into hammers, even objects that you really shouldn't be doing that with. Tool-like properties are put in by the user, not necessarily by the object.
This makes LLMs still tools, even if they're very good tools, and often can zero-shot solutions to simple problems. But just because you often take the `accept` branch the first time around, doesn't mean you're not in the loop.
> This makes LLMs still tools, even if they're very good tools, and often can zero-shot solutions to simple problems. But just because you often take the `accept` branch the first time around, doesn't mean you're not in the loop.
That, 100%. As Eliezer used to say, there are no little XML tags on atoms saying "these are molecules of a hammer", "a hammer's purpose is to drive nails". Purpose rests with us. We design things to afford some specific purpose, not determine it. I too have used plenty of things as hammers that were very much not intended for that purpose, and I used hammers for things they were not designed to do too.
It is very difficult to disagree with anyone of the caliber such as this man, but I wanted to steer the conversation away from the generative aspect of LLMs and focus on the consumption side, because frankly, these "tools", and I think even though I might agree with Rich that LLMs by themselves are not tools, the harness I built to work with them definitely is one. I think there's an immense value there, way before you even start talking about code-generation, or code at all. I think I have failed to explain my points, because a talk we both wanted to see was about to start.
Did you seriously write this with a straight face?
Though, it makes me think of the quote "Science advances one funeral at a time" - Max Planck
When you place someone on a pedestal, you make it hard to evaluate them critically. The remaining Clojure community has a problem with it.
The clojure community (what remains of it, as you say) is extremely guilty of this. They love repeating everything he says like it's the word of god. Try to explain the benefits of static typing to them and they just drop into an infinite loop of quoting Hickey.
I don't get it, are you unaware of the basic norms of actual human communication or something? Please explain to me how you envision arguing with someone, anyone, in a place and time like that. Or are you suggesting I should have been heckling him about static typing right there, on the spot, in front of other people? Otherwise, I suppose I'm worshiping and I should admit I'm in a cult?
Oh, grow the F up. I can't believe I have to explain the basic tenets of human communication here - stuff that children learn before they turn eight. Once again, I wasn't chatting with the guy at a random bus stop, at an airport, or on my personal podcast - we were at a Clojure conference, surrounded by people who flew all the way to Charlotte from places like Sydney and São Paulo. Of course, basic human decency dictates letting him talk instead of constantly interrupting him and vigorously arguing. Not only out of respect for the person, but for other people too. There's a time and a place - you need to know when to "evaluate critically" and when to STFU. It has nothing to do with the so-called "worshiping" you're implying.
Hickey's article is terrible. He's arguing semantics and then patting himself on the back. Anyone who can't see that is willfully blind.
This also isn't the first time Hickey engenders this kind of blind hero worship. He has been spouting nonsense about Haskell for years, for example. Clojurists don't understand enough of it to understand how silly the things are that he's saying, but they sure as hell will repeat it everywhere.
Au contraire. Many Lispers are well-versed in Haskell and different kinds of type systems. Coalton, core.typed, Typed Racket, Malli - these don't exist just for the sake of it. And many constantly disagree with Rich, with Halloway and other clojure.core members about all sorts of things. The "Maybe Not" talk got a lot of pushback, and most of it came from clojurists. The majority of them are pragmatists - they use whatever makes sense. In many cases, the specific dynamism of Lisp fits much better than the rigidity of Haskell-like type systems. They use static types where the invariants are stable and dynamic data where the shape is open or changes often. Many work that way, often by validating with Malli at the edges and keeping the core loose. It appears to me that you're blindly "worshiping" whatever or whomever. I gave you the exact example where I was [respectfully] disagreeing with Rich, and you decided to turn it inside-out, just to make it fit your own, totally imagined narrative - now who's blind here?
On the LLM front, it's been a fascinating journey for me. I started with the private beta of Github Copilot. I was an instant convert for the "better code completion" aspect. But my first attempts with coding agents were rough enough that I stayed away.
I'm now retired, but I want to understand how things are evolving. So two months ago I volunteered to automate a cartography data pipeline for an educator. I have a background in all aspects of the project. It's not simple - there are several data sources from governmental and corporate sources that need to be integrated together, and most of them are updated every few minutes. New maps need to be available within ~5 minutes of a data source updating. All this with many GB of data and running on a low powered machine, taking less than 2GB of RAM.
I bought some DeepSeek tokens and went to work. A few weeks later a mentee went to work at OpenAI and gave me a "friends and family" Pro level plan. I'm converted, and I absolutely see it as a tool in the sense Rich describes. I even question whether any "software engineers" using it, but not as a tool, are doing it right (I'd love to be educated if I'm wrong!).
I'm still learning, but that's part of the disagreement I have with Rich's take. He mentioned feedback. I often watch the "reasoning" process the agent goes through to see the approach it's taking. It's not at all unusual for me to steer it when I see it going in a direction I don't like. I've also found an incredibly powerful pattern where I can explore the approach I want to take for a part of the system with the agent. I have it create prototypes with different strategies (streaming vs. in-memory, different data structures, relying on various libraries, etc.) and then I have it characterize trade-offs between the prototypes (performance, memory usage, conceptual simplicity, code simplicity, etc.). This allows me to make informed decisions about which approaches to pursue further, and my decades of experience in software engineering constantly go to good use here.
It's also given me the time to go far deeper into things I never could have justified. Of course the project has 100% code coverage and branch coverage. It also has hundreds of property-based tests. And thousands of Lean proofs of the behavior of the algorithms, along with conformance tests that the code and the Lean adaptation of that code behave the same way. And lots of TLA+ verification of the overall flow of the system. None of that proves there are no bugs or that this is the right system, that's all on me. A month in I would have said I was fairly happy with the quality. Now I'm proud of the quality.
As I've gone through this process, I've dug into the code for patterns I don't like, and had the agent clean them up, all the while distilling guidance. I've had a lot of luck with that guidance being followed once I figured out the right place to put it and to reference it. I've spent entire days doing nothing but giving prompts to do specific refactoring. The beauty is that large refactorings don't involve the same boredom interrupted by anxiety they used to for me.
English prose (documentation, comments in the code, etc.) is what I've been the least happy with. An hour ago I had the idea to give it ~1,000 lines of my HN comments and ask it to characterize the style and tone of the technical parts. Then I told it to turn that into guidance. Then I told it to rephrase that same guidance in a way that follows the guidance. I would never mistake the result as my own, but it's much, much better than what it was producing before. While I've been writing this comment, it's been applying it to all prose in the project.
This very much feels like a tool that is letting me shape the project (and shape the tool itself). But it's letting me do it at a higher level. It handles the code so I can fully focus on the architecture, algorithms, and quality. This alone makes me think that the best simple guidance for quality results is dozens of prompts per day, not a handful (when a day is 100% focused on development). When you can't think of dozens of prompts, think and explore more (the agent can help with that!). That does require you know what quality is and how that can be achieved.
To reconcile this with what Rich is saying. I suppose he's right that it's not a tool for writing code. But it very much feels like a tool I'm wielding to do software engineering at a far more powerful level than I could have done without it. The resulting project has "me" everywhere in it. The people who know my work the best would look at this project and know that it's mine. Perhaps not the code, but the algorithms, the data flow, the approach to documentation and testing, etc.
For anyone curious, the project is getting close to 200K lines. About 25% of that is the code that is the data pipeline. About 25% is documentation. About 50% is testing and verification. One reason this is possible is that I'm working alone and have full control over the process (what I spend before it became free, how it's built, what my process is, and even the product definition within the constraints of what's valuable to the intended user). All told, it has been about 6 weeks of full time work worth of my time.
The next experiment... a web front-end to this system for the general public. This is not at all in my wheelhouse, so it should be interesting to see how much my blind spots cost me.
I think that's exactly what he means.
> But it very much feels like a tool I'm wielding to do software engineering at a far more powerful level than I could have done without it.
Ya, I'm not sure if he heeds a warning that AI is slowly moving to automate all that as well. Only 2 years ago it couldn't automate writing all of the code for example, it's possible in 2 years it has automated most of that higher level as well, and therefore software making becomes same as ordering a sandwich, just tell it the app you want and you get it. Or if he's just trying to make the reader realize they've given up coding and are losing that skill (or if new to coding are not learning it by using AI), and for better or worse is on the reader to decide.
That is the side of LLMs that often gets ignored, with the main focus being on the composition, which still raises some questions and skepticism, and for good reasons too. But I can absolutely vouch for LLMs being enormously useful on the other side.
I’m someone that is, and has been, for most of my career, someone from the in-between lands. I don’t use paper maps from the gas station, but I have not coded much.
I basically grew up with DOS 1.0 and on. Often made a living being able to sit at a Windows workstation and think and persist so I could figure out in four hours what other people could not, in that buggy strange world of microcomputers many of us grew up in.
Those situations, now, often take me five minutes to get past, instead of four hours. It has been a game changer for me.
A ghost bicycle?
I figure it still requires someone who can pedal and knows where they want to go before you get anywhere useful, and perhaps that slightly aligns with Hickey's point. But on the whole I feel like Hickey is arguing about the meaning of words, which is shrug-worthy.
The creativity and skill of the craftsman is gone. Craftsman/woman create new and unique or different things because they understand the problems or goals and create.
THe people using AI mostly dont know the basics of software and tahts part of the problem why we see really dumb mistakes, like little or no security.
Agreed most code from the past is to be kind very ordinary and is filled with many code smells, but they do get some or many things right.
> AI today produces better slop than most devs ever did. And LLMs are getting better - humans were never on an upward general trajectory.
You fail to make the distinction between the engineers of the past and the audience who vibe codes of today. The later dont know the mosts of best or good practices.
Thats a big difference, those that know NOTHING about software engineering those that know something.
AI only generates what it is told, and guess what garbage in garbage out, because non software engineers dont know or think about the basics.
But does it matter outside of the shop? It's the thing the machinist uses to make stuff, so, for all intent and purposes, a tool.
The thing that makes a lathe a tool is that it behaves like a tool. Not an appliance. Its utility scales with the skill of its operator. Just like a hammer, or a saw, or a wrench. A skilled machinist uses his tools to achieve precise results. An amateur uses the same tools to achieve poor results.
AI appliances puke out randomly generated slop. You could argue there's some kind of skill involved in attempting to read the tea leaves in this slop, but in reality it's just not so. You don't get any depth of experience with these "tools", you just get an accept/reject decision point. Repeat enough and you might come up with something useful. Or you might not. Like accepting random outputs from some kind of vending machine.
This is very, very different from what you get from a skilled craftsman. "A good workman does not blame his tools" is not applicable around LLMs. They're always saying "this model is better than that one" and the like. A good machinist can get good results out of a worn out lathe. Why can't the AI pilots get good results reliably?
but saying stuff like "AI appliances puke out randomly generated slop" just seems silly. it's not randomly generated, and it's not always slop.
There are certainly many ways of using coding agents, but the way he describes it is not my approach. There's a huge amount of direction and feedback.
I don't know if I'd call it a tool so much as a modality of building software. Within the modality, you have everything from truly unsupervised YOLO coding to something far more structured. To an extent, it's similar to how you go about setting up standard operating procedures to get teams of humans to do work at scale.
A project could be used for learning. Anyone could always cheat and have someone write it for them. They could also go to a professors office hours and get advice instead.
Now anyone can have AI write for them. They can also limit AI purely to advice if they choose.
- because car companies are definitely misaligned with their customers
Nope! Now it's "automation". Why ?
Using a lawnmower on your lawn doesn't give you control over the grass it cuts! It just cuts willy nilly wherever you point it, you can't get into the pebbles of your garden bed and forget that curvy edge work you had put in last month. And that's not even the worst. A lawnmower denies you the chance to learn how different breeds of grass make up your lawn or how each breed responds to a scythe. You never get to spend achingly long stretches admiring how grass glints differently in the sun at different times of the day, nor how it smells when cut - you'll mostly smell two stroke. A lawnmower uses insane amounts of oil and gas compared to the simple silent pleasure of walking around swinging a scythe. Being done with your lawn after a short while denies you a backbreaking day in the sun and you might even avoid a sunburn. Besides when you're done mowing your lawn what are you gonna do with all the time you got back! Read a book!?
Lawnmowers are a scam!
And, every single software you know is a tool?
People try to wrangle the indeterministic outputs through deterministic layers to convert the indeterminism to something determined
You can multiply /dev/random for how many (non-zero) constants you like, but the result will stay just as random
He's trying to unpack various qualities: learning potential, reliability, predictability, tactile feedback, simple construction, etc. Then goes to define tools as those things that have these set of qualities, and automation as those that have these other set of qualities: it does something for you, takes the practice, learning and details away from you, harder to control and can get derailed, etc.
In some of his comment replies, he even says there's a spectrum from tool to automation, because he's focusing on those qualities more so than on the semantics.
One wields a tool, but you cannot wield a set of dice or a slot machine, a chatbot, or a call center worker. That's not tool use, that's outsourcing or delegation of work. If I play Claude, or I pay a salary worker somewhere else, I have ceased to work, my skills are going to atrophy, my knowledge and my control is, the opposite of what genuine tool mastery implies.
If something's a tool, the more you use it, the more you improve not just narrowly mind you, but in all your faculties. Using an LLM has the exact opposite effect. At best you improve at only one thing, typing text into the LLM, while you atrophy everything else.
The logical terminus of the habitual LLM user, and that is really why 'industry leaders' love them so much, is the worker becoming a Tayloresque factory ape doing nothing but pushing the same button over and over again.
Reminds me of Baudelaire:
"the photographic industry was the refuge of every would-be painter, every painter too ill-endowed or too lazy to complete his studies"
Do DJ's make music? Why don't they play all the instruments themselves and become "experts"?
Judge the product, not how difficult or easy it was to create it.
Anyway this is getting a little too involved for a HN thread and it's unlikely I'll move your position but I appreciate the dialog.
> A tool is something you wield.
> Control, sensory feedback, intention, intimacy, continuous direction, expertise etc are all missing from LLM use. LLMs are not wielded. LLMs are automation.
Cameras do indeed have sensory feedback, intention, intimacy, contentious direction, expertise, etc. So TFA would indeed describe a camera as a tool, not as automation.
Note also that TFA is not romanticizing effort, rather it is putting value to expertise:
> The continuous application of technique and energy, and sensory feedback, are essential to the buildup of expertise.
Yes there exists a type of expertise where the value is not realized by whichever arbitrary metric you use to assign value. However having expertise is more likely to result in value added compared to not having said expertise.
For example, I am learning the guitar, I am not an expert, but the more I practice the more I approach expertise, then I can play more songs, I can play them better, resulting in me and those around me having more fun = value added.
"You have traded working with the world to working for a capricious robot."
This is what i'm a critic of not having more fun. This reads to me that some people are charlatans and i'm an expert. That type of sentiment is prevalent in all sorts of creative persuits. Aside from it being factually wrong, it's just different not worse or better.
What exactly are you a critic of? Why is this statement factually wrong (and why is the fact that it is wrong just an aside)? Why do you say trading your expertise for automation is neither better nor worse. For me—if I care about the craft—it is obviously worse.
I could have simply turned on the radio if I wanted to hear the guitar played, instead I spend an hour or more a day to acquire the necessary skills to satisfy. The latter is obviously better.
Thats great you care about the craft. There are many kinds of craft, but just because you do your craft in a certain way doesn't make others way invalid. The latter is not obviously better, better depends on your definition of value. The definition i'm reading from the article is whether it provides value to world or to you personally and I'm just saying who cares how that is accomplished. Defining how a craft "should be done" is the trap i'm pointing out. If the making is the important part to you aka the process and the journey, thats awesome and I agree that many wonderful things are created in the way you practice guitar with your hand eye coordination, auditory processing, etc... however I find it counterproductive to label ways of creating more or less valuable, they are just different. If I was to program a machine to play the guitar for me it might be different but not inherently better or worse just because you practice every day with your hands and I program a robot to do it. Maybe I have cerebral palsy and I can't play guitar the way you do, does that make my art lesser? It just makes my constraints different and thats at the core of what i'm getting at.
If all you wanted was a reasonable facsimile of a family member, then photography made attaining that object dramatically cheaper. Prior to photography, almost all of images of people are of fabulously wealthy and powerful people because they were the only ones who could afford a skilled painter making their portrait. After photography, most people could afford a daguerreotype.
The impact on fine art is much more complex. I think probably all you can say definitively is that the timeline where photography exists produces very different fine art paintings because the incentive structure and the implications are different in a world with photos. But better or worse? Impossible to say.
Yet vibe coders and people that delegate the creation of software through English prose to an LLM are still called software engineers or programmers. That is my major problem with the whole thing.
I think comes from a natural feeling of ownership over your profession. There's nothing wrong with that feeling that the title of engineer must be earned but in reality titles means nothing, what you do with it is whats important.
And they are a hell of a useful "assistant"
I mean, I guess there's a lot of people that don't know the difference in what he's saying.
`rm` is a tool. You don't tell `rm` to delete things and then get annoyed when it deletes your production database because it inferred incorrectly.
It does what you tell it. Like a hammer hits what you hit with it.
`claude` can be considered a version of `rm` that can do what `rm` does (and other things - including things you don't want). Nearly everyone using it is aware of that.
An employee is not a `tool`.
`claude` is closer to an employee. You tell it to do things. It costs you money. Sometimes you get what you wanted, sometimes you get something far better, sometimes you get literally nothing, other times you get disaster (more often with `claude` than with a good employee).
That's why they call it an `agent`, not a `tool`.
Employers don't throw up their hands and say, no thanks, I'll do everything myself with `tool`s. They say, I'll try to learn how to better manage employees which are useful to further my goals (along with tools - because both are useful).
Not every person runs a business. Maybe in the future most people won't be using AI at all. Some people definitely will.
I'm not sure why we needed to go on this pedantic ride.
When people say "AI is just a tool", I think they mostly know what they mean and we all do, too.
And I think that the "tool" vs. "automation" delineation is one of the clearest and most succinct takes on _how to talk about this problem_ that I have seen in the past few years.
It can't, though.
Only when connected to a harness can Claude remove files from disk.
And, at that point, it's using existing libraries or tools to do it - `rm` if it uses bash, the `remove` stdio function if it uses C or a C-implemented programming language to write a custom tool for the job, or one of many other options.
It remains true, though, that Claude cannot itself remove files - just be your proxy to guess what files it's probable you were referring to, that you likely wanted to remove them, and then use another tool to actually do so.
As you note, it will be wrong about that sometimes, and it will likely be unpleasant if you haven't prepared for the eventuality.
> When people say "AI is just a tool", I think they mostly know what they mean and we all do, too.
When I hear that phrase, I think the speaker is either too naive to live, or is intentionally trying to sidestep anyone bringing up the manifold disaster-level issues with genAI systems.
That said, I think this particular semantic distinction is something we need to think about more from a political perspective than a semantic precision perspective. A tool is something that humans (or animals, or other entities) control for their own purposes. It's important that AI remain a tool of humanity to serve human purposes, following human accountabilities. Because the alternative narrative is that AI is a super-intelligence with it's own agency which we can not control, and while it may make a small handful of individuals incredibly wealthy beyond their wildest dreams, they can't be held accountable because AI has its own agency.
The word "tool" is obviously very old and carries tons of connotation shaped by the world of the past. AI clearly challenges a ton of assumptions about what "tool" and many other words mean. Therefore, while I understand Hickey's point, I think for the sake of our civilization and the moral hazard we are facing, it's better that we consider AI a tool versus whatever narrative the AI cultists are cooking up.
"AI" as it was known until ~2023 could also be useful as an algorithmic implementation to solve an objective.
Now that definition is squishy, but still relevant.
AI is only a tool, it isn’t anything more than that. I use AI because work pays for an expensive subscription, and I’ve found it helpful… as a tool.
Yes, Janet, languages do evolve. But why do you think dictionaries exists? Solely for teaching purposes? No, it is because at the end of the day, sometimes there is a need for a correct definition to establish a foundation for some argument of some kind.
But I know people are going to ignore and simply say his arguments have no validity.
A shame, beause in this he actually wrote a very clear separation of software that is a tool and aoftware that is automation. And he didn't even say AI is bad or any other thing. He simply says: AI is automation, not a tool. Use accordingly
I don't know why you think that's so effective a way of getting at the truth. Whether something is a tool or not is a matter of family resemblances and is not susceptible to proof or disproof. Id recommend that Hickey put down the dictionary and pick up Wittgenstein.
They do and they don’t, depending on what (and who) you’re talking about and whether or not it’s beneficial to say language evolves or not in that particular argument :)
I mean that people can both claim that “words have meaning” and “languages evolve” depending on which one fits their narrative.
Words are embedded in (yes, evolving) traditions of use. They are situated in systems of other words and ideas. A precise definition (and often a history of the word and the turna its meaning has taken over time) serves to train you, just a little, in that entire tradition— in its motivations, its other ideas, and adjacent terms. It gives you clues about what distinguishes it connotatively and denotativelu from its nearest synonyms. It helps you maintain intelligibility with written works that use older senses of the word. For words in your native tongue, that also means that, in a sense, it helps keep your own cultural history open to you.
So if I had to push a norm, it wouldn't be "stick to old, established definitions" or "arguments are stronger when we use old definitions". It would be something like:
> It is better to keep in contact with what makes a word special, with the stories and arguments it was created to tell. And arguments about whether X is a Y are sometimes arguments about whether we are losing contact with a concept that Y once helped clarify and communicate. If that's happening, it's sometimes an argument worth being sensitive to and propagating, so honestly consider it.
His comment seems to imply there was some inherent virtue in doing the thing rather than letting the machine automate it.
I think he has a useful line of thought here but should think about this more. The definition of a tool is a continuum. On the left are your bare hands, on the right, the presence of your neural will creates a perfect final product instantly.
Neither the LLM’s probabilism nor its presence unusually to the right here changes the definition of the continuum. Automation and tool are not orthogonal. Would we argue that a compiler or the JVM isn’t performing automation on the programmer’s behalf? Yet we literally call it a member of a toolchain.
His point stands about the hazards, the definition argument less so.
Apologies Rich but I use LLMs to write Clojure. IMHO it maximizes token spend efficiency and economics by focusing on domain logic rather than boilerplate.
It doesn't matter whether LLMs work or not, but what's the user's relationship to them, and right now, they've been accelerating away from any "toolness" you could ascribe them. Look at how the industry positions these "tools" to your own employer if you need any more evidence.
If you shipped something understanding none of it, you did nothing. Claude did it. Writing 'code' is not just typing characters that compile, it's maintaining a system of ideas. If you don't know anything about those underlying ideas, what did you even do? How are you not trivially replaceable?
You can argue all day about these topics, but ultimately, the paychecks, the customers, the prestige, etc will be proportional to the non-AI value that you can offer to the world.
The root cause is people fully buying into the idea that this tech is 'intelligent' as opposed to simply giving us a baseline, approximately correct thing to keep working on.
Who says I'm a tool?
You are a tool.
Good to see Rich Hickey still has his head well screwed on his shoulders.
Life is too short to let who you've heard of define your values, and your statement says more about you than them...
https://news.ycombinator.com/newsguidelines.html
(We detached this subthread from https://news.ycombinator.com/item?id=50062384.)
HN's value lies largely in the audience its posts attract. Think about what you want the site to be. It isn't this. Or at least, it wasn't.
Also note this guideline: "If you flag, please don't also comment that you did."
In addition (or rather, in particular, because it's covered by "don't be snarky"), please don't do the internet thing of using quotation marks to make it look like you're quoting someone when you aren't.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...