I think Rich's comment reply here explains the post:
> 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.
> A Hammer is a tool ... a carpentry sub-contractor is not.
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.
You're too hung up on the social agreement of what a tool is. Yes, if I move into the sun to warm up, the sun is a tool. That's proper dictionary "tool definition". I believe Rich's point is, if you see it that way, then think AI is just a tool, you're missing on the world of differences between things.
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.
> So he purposely narrows the definition of a tool, and exclude autonomous things from it.
You can define "tool" anyway you like but for the purpose of this conversation "tool" is anything that can do some kind of work but isn't a human. That is, start with defining "human" and then consider the non-biological entities that do work for us, there's no need for defining "tool". Then ask yourself, is an autonomous car/tractor/drone/etc a human?
Further, consider the simple fact that "human work" is an accidental chore reluctantly performed for the needs of human survival but it doesn't define what human is in any way (animals do work too). Hopefully, this can help you to stop conflating "work" and "human".
You’ve made the same mistake that this thread is talking about.
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.
> You’ve made the same mistake that this thread is talking about.
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.
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.
I don't think the power tools analogy really works. Using power tools doesn't make you less skilled at carpentry, it just makes you less skilled at using hand tools specifically. If you then need to use hand tools later, you need to learn the hand tool skills but the carpentry skills are still there, and that's the more technical skill that takes longer to learn. In this sense the power tool analogy is more like using an IDE vs just a text editor.
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.
Ya, and in a comment he mentions he sees a spectrum from tool to automation.
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.
The argument rests on defining a tool as a tool only if it's a tool for a specific task.
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.
it’s an interface.
which is arguably a type of tool.
“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.
LLM's exist on a vast gradient of "toolness -> agent". Humans exist on that spectrum too.
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.
Yes, Rich says so explicitly as his reply to a comment:
> 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.
Rich mentions in another comment that he's talking about its embodiment in conversational systems purporting to be 'tools' for doing homework, research, coding, writing, etc.
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 coding the old-fashioned way, you were using automation as well, one example being the compiler. Still, if one is not even scanning the diffs anymore, I'm OK with not calling it "coding" anymore. We could call it "vibing" instead. But that's just words, the underlying activity is the same: creating and evolving software. That still takes skill, it's just at another level, and it's all about knowing how to use these... tools. This is what they are. A naive vibe coder is just (still) unskilled at using them and the results will be correspondingly limited.
I think that's the next layer of conversation. The first is that Rich is saying, if we think of everything that a human uses for any purpose as a tool, it's not very useful to reason about.
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.
I agree that that's a useful distinction to make. Which is why code generated by the model should be marked thus in the repository, for example. Just like someone shouldn't check in assembly code as source code when it's actually a build artifact. So it all depends on the abstraction level one is discussing from, again, just like it is for a compiler. Ultimately, I would say automation is a type of tool. A human OTOH, is not.
I also think it means you have to operate very differently around it, it's about guardrails, quality assurance, funneling context, keeping output in check, emphasizing what matters and doesn't, 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.
I guess according to his logic they would be tools for interacting with an automation. Like the button on a car wash kiosk. You could just as well holler and the man turns it on.
Are you saying a sandwich ordering service is a tool? Just because something has been turned into a service doesn’t mean it’s a tool, because otherwise literally any physically achievable action could be turned into a tool by making a service around it, thus completely diluting the definition of “tool” to “literally any physically achievable action”. That’s not a particularly useful definition.
> If you're a conductor, you can view the various members of your orchestra as "tools" to produce the ideal musical output.
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.
No, the sense that righthand is referring to is Merriam-Webster's sense n.(1)(3)(b)†, and he is right that it doesn't involve any sense of instrument or purpose.
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.
If you want to view those two senses as distinct insults, fine. You can even view, I suppose, one as merely insulting and the other as an insult per se. But the sense Merriam-Webster gives in (1)(3)(a), the one from your example sentence, is negative/pejorative.
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]
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.
As always when discussing the usage of English words, it's pleasing to look at Webster's 1913 dictionary, which helpfully includes this definition of "tool":
> 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.
righthand is right about that one. 1913 Webster's says it's a word of reproach, but the example that follows is obviously not the modern insult, which doesn't even have an instrumental sense.
Webster's dictionary currently glosses this sense of tool (n.(1)(3)(b)) as "a foolish or unlikable person : JERK".
Often it is used in society and media in the exact way as the definition I provided. For a good recent example, the following:
"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.
I'm trying in vain to find any indication in your comment that you read more than the headline.
LLM's exist on a vast gradient of "toolness -> agent".
Sure. You can stretch the word "tool" to mean anything, but here, Hickey is using the words "tool" and "automation" to describe specific things. He defines each word precisely, for the purpose of the points he's making.
Hickey describes a tool as something wielded, usually requiring "control, sensory feedback, intention, intimacy, continuous direction, expertise". Lack of that is automation.
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.
A lot of coding was actually plumbing filling in blanks between a framework and libraries with a few decisions in defining the data or process/flow. Not much lost there using AI where you still shape and review+understand the output.
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.
Don't think that's at all what the article in question is discussing, but this was interesting.
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.
> The assumption I need to challenge is that "an ultraintelligent machine could design even better machines".
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.
I had a chance to ask Rich about the subject at the latest Conj. I admit, my question was too vague, I asked him: "what are your thoughts on how AI is reshaping our industry?", to which he vaguely replied that he's "not participating in this [experiment]", he admitted that he hasn't explored LLMs too deeply and he simply thinks they are not good, not to mention tons of other concerns - moral, economic, etc. I said, "well, I wish I had the luxury to choose, but many of us have no choice here, we're simply forced to use the darn thing..."
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.
I think I get where you're coming from. Both the immense respect for Rich Hickey and the disagreement with him. I hopefully don't have to say much for the respect part - he has repeatedly changed how I think about my craft for the better. As I've mentored others, I've often pointed them to talks of his that were relevant to what they were missing. And that's all without using Clojure. But I definitely use ideas from Clojure in other languages where it fits.
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 suppose he's right that it's not a tool for writing code.
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.
It reads to me that your main focus is still on the composition side - the generative aspect of LLMs, which is where Rich's skepticism leans. I'm currently building massive ETL pipelines that involve sifting through tons of heterogeneous types of data. That's the consumption side I'm talking about. Being able to extract semantic value from dissimilar sources and deductively and inductively draw conclusions about all sorts of things - the shape of data, behaviors, payloads, endpoint constraints, etc. - is enormously useful. Before LLMs, painstakingly analyzing every corner case was awfully time-consuming yet unavoidable. It's like looking for a bunch of needles in a random-sized pack of haystacks where the shape, color, density, or magnitude of each needle and haystack can't be easily predicted. It's like using human labor vs. machines to collect, I dunno, cotton. It almost makes no sense not to use machines, except maybe for specific cases where the type of cotton is too fragile or expensive. Of course, machines can miss, but in general, humans would be still sloppier, just because humans do get tired, get hungry, get distracted, etc.
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.
Hello rented_mule! I’m also working on a cartography pipeline using public data sources, I’d love to hear more and to share ideas, my email is my HN username at duck dot com
Or really? I can ask you the same question about your very comment. How often do you travel to a conference that's been held for almost 20 years, face the person founded the entire "ethos" - the whole reason for that conference, stand in a circle of people highly respecting that person and try to debate and argue? I guess, judging by your comment, I'd say you just might. Well, I couldn't do it so easily.
Afaik, Planck didn't use the exact wording (someone simplified it into that, but it's not the literal quote), and it would be huffy of me to even categorize my brief conversation with Rich in that way. Who knows, if I had more time, I could maybe convince him to try to be less skeptical about LLMs. He's not a dogmatist; he's very practical, and things explained pragmatically can change his stance about anything.
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.
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 can't believe you're doubling down on your senseless take even after my explanation and downvotes of your initial comment. Congratulations, you just made everyone reading this exchange a little bit more stupid.
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?
My comment is not blind hero worship without actually addressing any of the arguments made by the person in question.
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?
Is a table saw a tool? It's not deterministic. Every cut is going to be slightly different. It can go "rogue" and toss the work piece back at you. It can even kill you or cut your fingers off.
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.
I haven't witnessed a table saw company focus on the possibility of all table saws going rogue and insisting only they can provide true table saw safety (while poorly articulating what that safety looks like), at least.
It's all in the spec. If you one shot an application then an LLM is not so much a tool as it is a make-a-wish machine, and like with those genies in bottles, what comes out the other end is going to be a surprise, either positive or negative. But if you instruct an llm to write a very specific piece of code with a very well defined interface that you run through a test set that you yourself wrote then it can be very much like a tool.
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.
Unless your single initial prompt includes instructions to deploy the result in production, and then you press <Enter> and never again revisit the conversation or its outcome, then I disagree. Because in normal case, even if you have LLM zero-shot something, you're still there as the final acceptance gate. You decide if it's good enough, or if it needs to be fixed.
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.
Being in the loop doesn't make LLMs anymore of a tool. How many software engineers can just take the vague description, bang something out, push to prod without talking, clarifying or discussuing with anyone in the meantime. Are they tools?
I find the G-code analogy sound. CNC machines let a person outsource the whole manufacture process but it still counts as a tool because the implementation is purposeful and result is fairly predictable. With LLMs, like CNC, we can control the predictability if we are careful; it's just a little harder.
Hickey is being a bit narrow sighted here, and ignoring some of the ways that humans are using AI outside of coding.
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.
Heres another view. A tool is something you buy or use to accomplish a task. Its a commodity everyone buys a hammer to bang in those nails. AI is the same here, everybody thinks they are developing a new calendar app, they are actually developing the SAME calendar app. The person didnt actually develop anything they simply used the tool to accomplish the same goal.
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.
Most code before LLMs was human slop, not the carefully crafted artisanal blocks of fine braces you claim. AI today produces better slop than most devs ever did. And LLMs are getting better - humans were never on an upward general trajectory.
> Most code before LLMs was human slop, not the carefully crafted artisanal blocks of fine braces you claim
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.
Yes, a bit of a thought bicycle, as Jobs envisioned computers - perhaps more than a bicycle though because the cognition is not limited to my own powers but also the distilled powers of past men.
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.
Huh? A lathe is absolutely a tool by Hickey's definition and any sane person's. You can chuck multiple tools in a lathe (drills in the tailstock, boring bars, turning, facing, and threading cutters in the toolpost). But that doesn't change the fact that a lathe itself is also 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?
> 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.
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.
First of all, Rich Hickey is a hero to me. It would be hard to respect someone more that I don’t personally know.
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.
I thought the best metaphor Rich Hickey had was the fast food analogy - drive-thru food is not a "tool for cooking". And the externalities may be similar - fast food is convenient and fast, but may be less healthy, more expensive, and you deprive your ability to learn to cook better or faster in future. LLM use might be thought of as "fast thinking" or "fast coding" in analogy.
I can go ask AI to help me learn something about coding. If it can be used as tool, it is a tool. That doesn't mean all uses of it are as a tool.
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.
Opinion pieces on AI have been getting a ton of engagement and bring out a very emotional crowd. It feels very "Reddit" lately, and ironically I find /r/localllama to be better at engaging the technology itself than descending into political flamewars.
a semantics discussion but I think it would be fair to call them "indeterministic tools" and there are other tools that are indeterministic besides LLMs
People try to wrangle the indeterministic outputs through deterministic layers to convert the indeterminism to something determined
I don't think he's trying to make a semantic discussion.
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.
no, I think he's quite right to say that there is no such thing as an indeterministic tool. As he says, what defines tool use is precision, mastery and intentionality.
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.
> 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.
Expertise has no inherint value. What you do with that expertise does. I can be an expert in playing monopoly, does that make it valuable? no. I can be an expert in virology but instead I watch tv and drink beer all day. It's a coorelation causation trap.
The correlation is not a 1:1 relationship (few things in nature are).
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.
Which is why it ultimately helped art because it removed the incentive to just make paintings as realistic as possible because there was a tool that did that boring task better.
I don't know if "helped art" is a well-defined concept because it depends on a notion of "better" or "worse" art which is itself famously poorly defined.
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.
So much so we call them photographers instead of (vibe) painters.
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 the distinction is meaningless to the vast majority of the population. People who use a web service don't care if it was vibe coded or hand coded as long as it does the job.
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.
Well, not a good analogy really, most of the old masters used cameras regularly, and there's a history of camera use for painting that extends from the northern renaissance to modernity.
My point is the line between tool and automation is a pointless line to draw that is about effort not output. This same logic was used to critique photography as an art form.
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.
One can argue that the instrument DJs master are the discs and the mixer. DJs have to know a lot of songs, know which keys they are in, know which tempo it is in, know the range of tempos two songs sound good together, know which keys sound good together when switching songs, etc. etc. Good DJs are indeed experts. If they wanted automation they would just pick a Now record or a Spotify playlist and play it through.
Is it not possible the spotify playlist is better than the DJ set? I agree DJ's are experts! In fact thats my point! They are just as much experts as musicians playing instruments just different kinds of experts. That being said just because work was done to it does not make it good.
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.
Agentic AIs (what he's talking about) are agents, obviously; you set the goal, they decide the means. Traditional programs are automation. Totally different, qualitatively.
Is a query planner an agent? (It might be, I'm not sure semantically the "agent" vs. "automation" distinction will aid as much in the discussion as "tool" vs. "automation", but I'm open to being completely off base here).
Let's talk about a lawnmower. Bought one the other day. Effective tool?
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!?
I love Rich Hickey's speeches, and found this entertaining, but it seems pretty pedantic.
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.
> `claude` can be considered a version of `rm` that can do what `rm` does (and other things - including things you don't want).
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.
In the vein of these 2 minutes of Guy Steele's talk on Fortress (How to think about parallel programming: Not! https://youtu.be/dPK6t7echuA?si=huyI3LR8LVaB6Yen&t=1589) I think that the real thing here is "do not hide what is important nor obscure that which ought to belong to the user". The question is (as always) "what is important"?
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.
also it's not even really about ai, it's more of an argument about the definition of "tool". ok ai isn't a tool, now what changes? nothing? alrighty then.
Huge respect for Rich Hickey, and anything he says is worth thinking deeply about.
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.
It’s always scary to click on a new AI opinion piece from an engineer you admire, but this is very well-argued and well-thought, and possibly will shut down all the ‘it’s just a tool!’ arguments that somehow reminds me of the braindead discourse on gun control in the US, where any controversial position is brushed away with that exact cliché.
Good to see Rich Hickey still has his head well screwed on his shoulders.
I agree 100% to what Rich has to say here, especially because, as Rich always writes, he goes to the dictionary to find correct definitions to support his argument. But I think this is a lost battle, because there is always going to be the camp of people of "BuT lAnGuAgEs EvOlVe".
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 agree 100% to what Rich has to say here, especially because, as Rich always writes, he goes to the dictionary to find correct definitions to support his argument.
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.
Hickey is not leaning on the dictionary. The specific definitions he lays out for tool and automation make up his argument, not the words themselves. Saying "no, tool can be these other things" misses the point by a considerable distance.
So he's stipulating a definition of the word and then saying LLMs don't meet it. A more truthful title would be, "LLMs are not tools in my narrower, idiosyncratic sense of the word." Fine, but so what?
Dictionaries exist to show what some people currently believe a word means. But it is poor argumentation to argue that a word should only mean what the dictionary says. That's the "old man shaking his fist at the clouds" that the world is constantly changing.
I think there's a better version of this, and it fits well with Hickey's predilection for etymology dictionaries in particular:
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.
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 :)
No, they always do. The confusion might be that you think evolution means "get better". But evolution of languages, just like biological beings simply means "changes over time".
This is the most sensible thing I read, and I'm honestly disappointing in how defensive the Hacker News response had been. It's a beautifully articulated argument for a very common-sense position, from a person I owe a lot of respect for.
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.
"All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor."
It's a useful piece because it shows how considering AI a tool is nothing but lying to yourself.
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.
Shipping code is more than just writing the code. Just writing code is far from the be all and end all of making something, and there are already many books written on the subject already. Now, just throwing the result of a oneshot prompt over the wall isn't contributing much but we've long recognized that a useful piece of software is much more than just the effort of writing out the code.
Yes, it's possible, but far from popular at the moment, with many developers admitting not to have written a single line of code in months, and delegating the bulk of code review to tools.
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.
AI is a tool. And I don't see the point of this argument other than a bit of a `boomer rant` , as someone who sort of fanboyed rich, like many on HN, earlier in my career.
Via LinkedIn (ai-tool-rich-hickey-kjl8e) but I suspect that we're rate limiting slop from there. Mods, feel free to swap out the original link if I was just-wrong about that.
I've reset the link in keeping with HN's preference for original sources, but given that linkedin.com is a banned domain on HN, what you did was fine. I've put the gist link in the toptext as well.
Both belong to Microsoft anyway. They should know how to optimally get their shit together - it's not our problem. People be spreading shit all over - that's the general idea of the Internet.
> Aww shucks, it sucks to see folks you admire get old and age out with tech.
The vast majority of the time, old people whom the young think are "out of touch" are actually speaking from hard-won experience. Ignore them at your peril, because they are usually correct and the young are usually wrong.
Every generation thinks they figured things out and the youngsters should listen to them this time. It never happens and it's probably a good thing. I don't think any age range has a monopoly on being right or wrong, just different biases.
I don't think being old automatically makes you right or anything. Nor does being young automatically mean you are wrong. But in my own life, I have noticed that the older generation is right more often than they are wrong, and the younger generation is wrong more often than they are right. Which makes sense, one should get more skilled over time after all. But it means that if you are young, it is a good idea to bet on your elders having the right idea about stuff until proven otherwise.
I am well aware. It is also completely irrelevant to my point. The point is that you should never assume a graybeard is out of touch, even if you disagree with him. Most of the time, he knows something you don't by virtue of having had a lot more experience. Not every time! But often enough to make it worth your while to bet on it.
By his definition, we could argue that a catapult or bow and arrow are not tools
Uh no, not based on his definition. Catapult and bows are simple. You can evaluate the result of using these tool instantly, and the corresponding adjustment is something you have to make, because you are wielding the tool. This is what he means by "wielding".
Compare and contrast with complaining to an LLM that "the margins look wrong".
Sorry to disappoint your dissidence, but the article was flagged by users and we've turned off the flags now, which means it's back on the frontpage, not being repressed!
Hey dang, while we're talking flags, I made a comment yesterday where two of the replies are now [flagged] and [dead] and yet they both seem innocuous.
I thought I could 'vouch' them but it's not an option - is vouching time limited?
I'm also wondering what's going on with that user. Their comments all seem fine to me but I notice that a huge amount of their past comments - even beyond my comment thread - are [dead]. I feel a bit sorry for them.
I'm pretty sure there is a limited vouch window. I can vouch the first but not the second, I would imagine you should be able to as well. As far as the poster goes, my best guess is the account is somehow flagged as a bit? I've seen a few accounts where every comment they make shows up as flagged-dead, but I've never been quite sure why.
The second comment was already vouched when you had a look. ;) It wasn't out of place as a comment, but the forum software does automatically mark some comments as dead - going back a month in the user's comments, many do come across as possible LLM content but some people do write that way.
Sorry, Dan. I don't come here to read stereotypical LinkedIn essays. To the extent AI emits slop, LinkedIn is where it learned how. Sometimes a shallow dismissal is just what the situation calls for.
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.
People have different views. If you feel someone's views are wrong, you have several options, including (1) responding respectfully with more better information, or (2) not posting. Snark and personal attack, however, are not ok, regardless of how wrong someone is or you feel they are.
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.
I think Rich's comment reply here explains the post:
> 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.
The part about "It's just a tool." that always bugged me is exactly this.
A Hammer is a tool ... a carpentry sub-contractor is not.
> A Hammer is a tool ... a carpentry sub-contractor is not.
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.
You're too hung up on the social agreement of what a tool is. Yes, if I move into the sun to warm up, the sun is a tool. That's proper dictionary "tool definition". I believe Rich's point is, if you see it that way, then think AI is just a tool, you're missing on the world of differences between things.
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.
> So he purposely narrows the definition of a tool, and exclude autonomous things from it.
You can define "tool" anyway you like but for the purpose of this conversation "tool" is anything that can do some kind of work but isn't a human. That is, start with defining "human" and then consider the non-biological entities that do work for us, there's no need for defining "tool". Then ask yourself, is an autonomous car/tractor/drone/etc a human?
Further, consider the simple fact that "human work" is an accidental chore reluctantly performed for the needs of human survival but it doesn't define what human is in any way (animals do work too). Hopefully, this can help you to stop conflating "work" and "human".
You lost me.
If we're discussing the article, than we should be using the definition put forward in the article.
You’ve made the same mistake that this thread is talking about.
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.
> You’ve made the same mistake that this thread is talking about.
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.
>> A Hammer is a tool ... a carpentry sub-contractor is not.
>If human - the sub-contractor isn't a tool, if robot - it is.
This is a miscategorization to me.
A hammer is a tool, a carpentry sub-contractor is a system that uses tools -- whether the sub-contractor involves humans or robots doesnt matter here.
> 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.
> 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.
I don't think the power tools analogy really works. Using power tools doesn't make you less skilled at carpentry, it just makes you less skilled at using hand tools specifically. If you then need to use hand tools later, you need to learn the hand tool skills but the carpentry skills are still there, and that's the more technical skill that takes longer to learn. In this sense the power tool analogy is more like using an IDE vs just a text editor.
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.
So functionally, this take is mostly incorrect.
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.
Ya, and in a comment he mentions he sees a spectrum from tool to automation.
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.
The argument rests on defining a tool as a tool only if it's a tool for a specific task.
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.
it’s an interface. which is arguably a type of tool.
“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.
LLM's exist on a vast gradient of "toolness -> agent". Humans exist on that spectrum too.
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.
Yes, Rich says so explicitly as his reply to a comment:
> 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.
> The more using a thing is like ordering a sandwich, the less it is a tool.
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?
Rich mentions in another comment that he's talking about its embodiment in conversational systems purporting to be 'tools' for doing homework, research, coding, writing, etc.
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 coding the old-fashioned way, you were using automation as well, one example being the compiler. Still, if one is not even scanning the diffs anymore, I'm OK with not calling it "coding" anymore. We could call it "vibing" instead. But that's just words, the underlying activity is the same: creating and evolving software. That still takes skill, it's just at another level, and it's all about knowing how to use these... tools. This is what they are. A naive vibe coder is just (still) unskilled at using them and the results will be correspondingly limited.
I think that's the next layer of conversation. The first is that Rich is saying, if we think of everything that a human uses for any purpose as a tool, it's not very useful to reason about.
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.
I agree that that's a useful distinction to make. Which is why code generated by the model should be marked thus in the repository, for example. Just like someone shouldn't check in assembly code as source code when it's actually a build artifact. So it all depends on the abstraction level one is discussing from, again, just like it is for a compiler. Ultimately, I would say automation is a type of tool. A human OTOH, is not.
I also think it means you have to operate very differently around it, it's about guardrails, quality assurance, funneling context, keeping output in check, emphasizing what matters and doesn't, 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.
I guess according to his logic they would be tools for interacting with an automation. Like the button on a car wash kiosk. You could just as well holler and the man turns it on.
They can't be tools at all by his logic, because using them is 100% similar to ordering a sandwich.
Are you saying a sandwich ordering service is a tool? Just because something has been turned into a service doesn’t mean it’s a tool, because otherwise literally any physically achievable action could be turned into a tool by making a service around it, thus completely diluting the definition of “tool” to “literally any physically achievable action”. That’s not a particularly useful definition.
> If you're a conductor, you can view the various members of your orchestra as "tools" to produce the ideal musical output.
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.
> The only way I know people can be a tool, is through an already existing insult.
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-... )
"tool" in that context definitely has a negative/pejorative connotation. That's the insult sense of the word
No, the sense that righthand is referring to is Merriam-Webster's sense n.(1)(3)(b)†, and he is right that it doesn't involve any sense of instrument or purpose.
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.
If you want to view those two senses as distinct insults, fine. You can even view, I suppose, one as merely insulting and the other as an insult per se. But the sense Merriam-Webster gives in (1)(3)(a), the one from your example sentence, is negative/pejorative.
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.
As always when discussing the usage of English words, it's pleasing to look at Webster's 1913 dictionary, which helpfully includes this definition of "tool":
> 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.
Okay but how is it used in society? I don’t know many people who refer to Websters. Notice your Webster’s doesn’t include the insult usage.
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.
> Notice your Webster’s doesn’t include the insult usage.
What exactly do you think
> a word of reproach
means?
righthand is right about that one. 1913 Webster's says it's a word of reproach, but the example that follows is obviously not the modern insult, which doesn't even have an instrumental sense.
Webster's dictionary currently glosses this sense of tool (n.(1)(3)(b)) as "a foolish or unlikable person : JERK".
( https://www.merriam-webster.com/dictionary/tool )
Often it is used in society and media in the exact way as the definition I provided. For a good recent example, the following:
"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.
I'm trying in vain to find any indication in your comment that you read more than the headline.
Sure. You can stretch the word "tool" to mean anything, but here, Hickey is using the words "tool" and "automation" to describe specific things. He defines each word precisely, for the purpose of the points he's making.Hickey describes a tool as something wielded, usually requiring "control, sensory feedback, intention, intimacy, continuous direction, expertise". Lack of that is automation.
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.
How about this, if you're using an agentic AI as a tool, be careful as it may stop being a tool.
> How about this, if you're using an agentic AI as a tool, be careful as it may stop being a tool.
Even more importantly, you maybe become its tool.
A lot of coding was actually plumbing filling in blanks between a framework and libraries with a few decisions in defining the data or process/flow. Not much lost there using AI where you still shape and review+understand the output.
https://edoras.sdsu.edu/~vinge/misc/singularity.html
Don't think that's at all what the article in question is discussing, but this was interesting.
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.
> The assumption I need to challenge is that "an ultraintelligent machine could design even better machines".
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.
> Would you bet your life, and everyone else's, to test that assumption?
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.
I had a chance to ask Rich about the subject at the latest Conj. I admit, my question was too vague, I asked him: "what are your thoughts on how AI is reshaping our industry?", to which he vaguely replied that he's "not participating in this [experiment]", he admitted that he hasn't explored LLMs too deeply and he simply thinks they are not good, not to mention tons of other concerns - moral, economic, etc. I said, "well, I wish I had the luxury to choose, but many of us have no choice here, we're simply forced to use the darn thing..."
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.
I think I get where you're coming from. Both the immense respect for Rich Hickey and the disagreement with him. I hopefully don't have to say much for the respect part - he has repeatedly changed how I think about my craft for the better. As I've mentored others, I've often pointed them to talks of his that were relevant to what they were missing. And that's all without using Clojure. But I definitely use ideas from Clojure in other languages where it fits.
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 suppose he's right that it's not a tool for writing code.
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.
It reads to me that your main focus is still on the composition side - the generative aspect of LLMs, which is where Rich's skepticism leans. I'm currently building massive ETL pipelines that involve sifting through tons of heterogeneous types of data. That's the consumption side I'm talking about. Being able to extract semantic value from dissimilar sources and deductively and inductively draw conclusions about all sorts of things - the shape of data, behaviors, payloads, endpoint constraints, etc. - is enormously useful. Before LLMs, painstakingly analyzing every corner case was awfully time-consuming yet unavoidable. It's like looking for a bunch of needles in a random-sized pack of haystacks where the shape, color, density, or magnitude of each needle and haystack can't be easily predicted. It's like using human labor vs. machines to collect, I dunno, cotton. It almost makes no sense not to use machines, except maybe for specific cases where the type of cotton is too fragile or expensive. Of course, machines can miss, but in general, humans would be still sloppier, just because humans do get tired, get hungry, get distracted, etc.
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.
Hello rented_mule! I’m also working on a cartography pipeline using public data sources, I’d love to hear more and to share ideas, my email is my HN username at duck dot com
> it's very difficult to disagree with anyone of the caliber of this man
Did you seriously write this with a straight face?
Or really? I can ask you the same question about your very comment. How often do you travel to a conference that's been held for almost 20 years, face the person founded the entire "ethos" - the whole reason for that conference, stand in a circle of people highly respecting that person and try to debate and argue? I guess, judging by your comment, I'd say you just might. Well, I couldn't do it so easily.
I agree with how you handled the situation and this comment.
Though, it makes me think of the quote "Science advances one funeral at a time" - Max Planck
Afaik, Planck didn't use the exact wording (someone simplified it into that, but it's not the literal quote), and it would be huffy of me to even categorize my brief conversation with Rich in that way. Who knows, if I had more time, I could maybe convince him to try to be less skeptical about LLMs. He's not a dogmatist; he's very practical, and things explained pragmatically can change his stance about anything.
I got the impression that comment was less about confronting Hickey to his face, and more about hero worship in general.
When you place someone on a pedestal, you make it hard to evaluate them critically. The remaining Clojure community has a problem with it.
> more about hero worship in general.
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.
Yes. This is about hero worship.
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 can't believe you're doubling down on your senseless take even after my explanation and downvotes of your initial comment. Congratulations, you just made everyone reading this exchange a little bit more stupid.
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?
My comment is not blind hero worship without actually addressing any of the arguments made by the person in question.
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.
> Clojurists don't understand enough of it
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?
Is a table saw a tool? It's not deterministic. Every cut is going to be slightly different. It can go "rogue" and toss the work piece back at you. It can even kill you or cut your fingers off.
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.
I haven't witnessed a table saw company focus on the possibility of all table saws going rogue and insisting only they can provide true table saw safety (while poorly articulating what that safety looks like), at least.
It's all in the spec. If you one shot an application then an LLM is not so much a tool as it is a make-a-wish machine, and like with those genies in bottles, what comes out the other end is going to be a surprise, either positive or negative. But if you instruct an llm to write a very specific piece of code with a very well defined interface that you run through a test set that you yourself wrote then it can be very much like a tool.
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.
Unless your single initial prompt includes instructions to deploy the result in production, and then you press <Enter> and never again revisit the conversation or its outcome, then I disagree. Because in normal case, even if you have LLM zero-shot something, you're still there as the final acceptance gate. You decide if it's good enough, or if it needs to be fixed.
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.
Being in the loop doesn't make LLMs anymore of a tool. How many software engineers can just take the vague description, bang something out, push to prod without talking, clarifying or discussuing with anyone in the meantime. Are they tools?
I find the G-code analogy sound. CNC machines let a person outsource the whole manufacture process but it still counts as a tool because the implementation is purposeful and result is fairly predictable. With LLMs, like CNC, we can control the predictability if we are careful; it's just a little harder.
Is ffmpeg a tool? When the incantation is so obscure, are you really wielding it?
Something something tolerances
Hickey is being a bit narrow sighted here, and ignoring some of the ways that humans are using AI outside of coding.
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.
Heres another view. A tool is something you buy or use to accomplish a task. Its a commodity everyone buys a hammer to bang in those nails. AI is the same here, everybody thinks they are developing a new calendar app, they are actually developing the SAME calendar app. The person didnt actually develop anything they simply used the tool to accomplish the same goal.
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.
Most code before LLMs was human slop, not the carefully crafted artisanal blocks of fine braces you claim. AI today produces better slop than most devs ever did. And LLMs are getting better - humans were never on an upward general trajectory.
> Most code before LLMs was human slop, not the carefully crafted artisanal blocks of fine braces you claim
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.
Yes, a bit of a thought bicycle, as Jobs envisioned computers - perhaps more than a bicycle though because the cognition is not limited to my own powers but also the distilled powers of past men.
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.
Rich Hickey's flair for words not withstanding, I believe he is right on this.
It is like saying that a lathe is not a tool. Technically true, the tool is just the cutting part, not the whole machine.
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.
Huh? A lathe is absolutely a tool by Hickey's definition and any sane person's. You can chuck multiple tools in a lathe (drills in the tailstock, boring bars, turning, facing, and threading cutters in the toolpost). But that doesn't change the fact that a lathe itself is also 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?
i don't think this is really true, although maybe the "tool" part is the harness itself.
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.
You're right. Unless they use true sources of randomness, its only psueorandomly generated. Great insight.
The AI is random argument never made sense to me considering it can trivially be made deterministic.
..... There's a reason its not made deterministic.
> 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.
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.
Ivan Illich makes a similar argument in Tools for Conviviality (1973) where he distinguishes tools you work with versus tools that work for you.
First of all, Rich Hickey is a hero to me. It would be hard to respect someone more that I don’t personally know.
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.
I thought the best metaphor Rich Hickey had was the fast food analogy - drive-thru food is not a "tool for cooking". And the externalities may be similar - fast food is convenient and fast, but may be less healthy, more expensive, and you deprive your ability to learn to cook better or faster in future. LLM use might be thought of as "fast thinking" or "fast coding" in analogy.
I can go ask AI to help me learn something about coding. If it can be used as tool, it is a tool. That doesn't mean all uses of it are as a tool.
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.
I was never going to learn webGL, AI or no.
Author’s definition of tool feels too narrow. What about tools of the mind?
Whether you agree with him or not, this is a wild post to be flagged.
Opinion pieces on AI have been getting a ton of engagement and bring out a very emotional crowd. It feels very "Reddit" lately, and ironically I find /r/localllama to be better at engaging the technology itself than descending into political flamewars.
Is car a tool?
- because car companies are definitely misaligned with their customers
Software has been called tools for decades. He author is going against the grain of the regular usage of the word.
LLMs are not normal software
And, every single software you know is a tool?
a semantics discussion but I think it would be fair to call them "indeterministic tools" and there are other tools that are indeterministic besides LLMs
People try to wrangle the indeterministic outputs through deterministic layers to convert the indeterminism to something determined
I don't think he's trying to make a semantic discussion.
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.
no, I think he's quite right to say that there is no such thing as an indeterministic tool. As he says, what defines tool use is precision, mastery and intentionality.
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.
How would people wrangle indeterministic outputs through deterministic layers?
You can multiply /dev/random for how many (non-zero) constants you like, but the result will stay just as random
[flagged]
Do you consider a camera an automation and not a tool? This type of romanticing of effort is a tired old debate that has not aged well...
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"
Explained in TFA.
> 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.
Expertise has no inherint value. What you do with that expertise does. I can be an expert in playing monopoly, does that make it valuable? no. I can be an expert in virology but instead I watch tv and drink beer all day. It's a coorelation causation trap.
The correlation is not a 1:1 relationship (few things in nature are).
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.
The article states:
"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.
I’m sorry, I don’t quite follow your logic.
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.
Sorry you don't follow, tried my best to explain!
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.
I think a camera is an excellent tool for producing photographs. It is a shitty tool for becoming a better painter.
Which is why it ultimately helped art because it removed the incentive to just make paintings as realistic as possible because there was a tool that did that boring task better.
I don't know if "helped art" is a well-defined concept because it depends on a notion of "better" or "worse" art which is itself famously poorly defined.
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.
So much so we call them photographers instead of (vibe) painters.
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 the distinction is meaningless to the vast majority of the population. People who use a web service don't care if it was vibe coded or hand coded as long as it does the job.
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.
Didn't you just call them vibecoders instead of software engineers?
Do job listings call them vibecoders, so I can filter for actual software engineering work?
Well, not a good analogy really, most of the old masters used cameras regularly, and there's a history of camera use for painting that extends from the northern renaissance to modernity.
[dead]
Yeah I mean a camera pretty precisely fits his definition of a tool. Not sure what your point is here.
My point is the line between tool and automation is a pointless line to draw that is about effort not output. This same logic was used to critique photography as an art form.
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.
One can argue that the instrument DJs master are the discs and the mixer. DJs have to know a lot of songs, know which keys they are in, know which tempo it is in, know the range of tempos two songs sound good together, know which keys sound good together when switching songs, etc. etc. Good DJs are indeed experts. If they wanted automation they would just pick a Now record or a Spotify playlist and play it through.
Is it not possible the spotify playlist is better than the DJ set? I agree DJ's are experts! In fact thats my point! They are just as much experts as musicians playing instruments just different kinds of experts. That being said just because work was done to it does not make it good.
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.
Agentic AIs (what he's talking about) are agents, obviously; you set the goal, they decide the means. Traditional programs are automation. Totally different, qualitatively.
Is a query planner an agent? (It might be, I'm not sure semantically the "agent" vs. "automation" distinction will aid as much in the discussion as "tool" vs. "automation", but I'm open to being completely off base here).
Let's talk about a lawnmower. Bought one the other day. Effective tool?
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!
Tools are wielded by the mind, not ultimately the hand. The hand itself is a (flexible) tool of the mind
Semantics, ok, they are "assistants" that can go rogue, escape confinement, etc.
And they are a hell of a useful "assistant"
It's not just semantics, because a lot of people (especially here on HN) claim that AI is just a tool to promote its usage.
Did tools just become recursive?
Oh god these word games... no wander some people get nothing done.
I love Rich Hickey's speeches, and found this entertaining, but it seems pretty pedantic.
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.
> `claude` can be considered a version of `rm` that can do what `rm` does (and other things - including things you don't want).
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.
The name of the Claude Code executable is called `claude`, so they may have been referring to the harness, not the model.
In the vein of these 2 minutes of Guy Steele's talk on Fortress (How to think about parallel programming: Not! https://youtu.be/dPK6t7echuA?si=huyI3LR8LVaB6Yen&t=1589) I think that the real thing here is "do not hide what is important nor obscure that which ought to belong to the user". The question is (as always) "what is important"?
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.
also it's not even really about ai, it's more of an argument about the definition of "tool". ok ai isn't a tool, now what changes? nothing? alrighty then.
Huge respect for Rich Hickey, and anything he says is worth thinking deeply about.
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.
It depends on what your definition of "is" is
AI, as it currently exists in the marketplace, is used, engaged, and distributed to be a tool.
"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.
So gdb isn’t a tool then. Huh, that seems odd.
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.
I generally don't agree with the framing in the gist, but I'm not sure where you are getting that the author wouldn't consider gdb to be a tool
wish we could go like a week with no posts about ai. we all deserve a break to learn something new...
The main thing I'm taking from this article is that (editiorialized) "AI is a tool like a drive-through is a tool for cooking."
It’s always scary to click on a new AI opinion piece from an engineer you admire, but this is very well-argued and well-thought, and possibly will shut down all the ‘it’s just a tool!’ arguments that somehow reminds me of the braindead discourse on gun control in the US, where any controversial position is brushed away with that exact cliché.
Good to see Rich Hickey still has his head well screwed on his shoulders.
I agree 100% to what Rich has to say here, especially because, as Rich always writes, he goes to the dictionary to find correct definitions to support his argument. But I think this is a lost battle, because there is always going to be the camp of people of "BuT lAnGuAgEs EvOlVe".
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 agree 100% to what Rich has to say here, especially because, as Rich always writes, he goes to the dictionary to find correct definitions to support his argument.
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.
Hickey is not leaning on the dictionary. The specific definitions he lays out for tool and automation make up his argument, not the words themselves. Saying "no, tool can be these other things" misses the point by a considerable distance.
So he's stipulating a definition of the word and then saying LLMs don't meet it. A more truthful title would be, "LLMs are not tools in my narrower, idiosyncratic sense of the word." Fine, but so what?
Dictionaries exist to show what some people currently believe a word means. But it is poor argumentation to argue that a word should only mean what the dictionary says. That's the "old man shaking his fist at the clouds" that the world is constantly changing.
I think there's a better version of this, and it fits well with Hickey's predilection for etymology dictionaries in particular:
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.
> "BuT lAnGuAgEs EvOlVe"
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 :)
No, they always do. The confusion might be that you think evolution means "get better". But evolution of languages, just like biological beings simply means "changes over time".
I don’t think evolution means “get better”.
I mean that people can both claim that “words have meaning” and “languages evolve” depending on which one fits their narrative.
Ok, and?
His comment seems to imply there was some inherent virtue in doing the thing rather than letting the machine automate it.
This is the most sensible thing I read, and I'm honestly disappointing in how defensive the Hacker News response had been. It's a beautifully articulated argument for a very common-sense position, from a person I owe a lot of respect for.
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.
"All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor."
It's a useful piece because it shows how considering AI a tool is nothing but lying to yourself.
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.
Shipping code is more than just writing the code. Just writing code is far from the be all and end all of making something, and there are already many books written on the subject already. Now, just throwing the result of a oneshot prompt over the wall isn't contributing much but we've long recognized that a useful piece of software is much more than just the effort of writing out the code.
Surely it is possible to use AI and also comprehend its output.
Yes, it's possible, but far from popular at the moment, with many developers admitting not to have written a single line of code in months, and delegating the bulk of code review to tools.
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.
[dead]
Why are you a tool?
Who says I'm a tool?
You are a tool.
AI is a tool. And I don't see the point of this argument other than a bit of a `boomer rant` , as someone who sort of fanboyed rich, like many on HN, earlier in my career.
Via LinkedIn (ai-tool-rich-hickey-kjl8e) but I suspect that we're rate limiting slop from there. Mods, feel free to swap out the original link if I was just-wrong about that.
I've reset the link in keeping with HN's preference for original sources, but given that linkedin.com is a banned domain on HN, what you did was fine. I've put the gist link in the toptext as well.
I for one am happier to read a gist than linkedin.
Both belong to Microsoft anyway. They should know how to optimally get their shit together - it's not our problem. People be spreading shit all over - that's the general idea of the Internet.
Oh it's not about who they belong to. One shows the things I want to read, while the other one shows things I do not want to read.
Can the people who flagged this explain why?
Thanks dang ;)
[dead]
[dead]
[flagged]
From your profile you are "I'm all in on GenAI", could this be clouding what advice you find useful?
possibly, i drank the kool aid 3 years ago, when the context window was 4k, i never put the cup down.
> Aww shucks, it sucks to see folks you admire get old and age out with tech.
The vast majority of the time, old people whom the young think are "out of touch" are actually speaking from hard-won experience. Ignore them at your peril, because they are usually correct and the young are usually wrong.
Every generation thinks they figured things out and the youngsters should listen to them this time. It never happens and it's probably a good thing. I don't think any age range has a monopoly on being right or wrong, just different biases.
I don't think being old automatically makes you right or anything. Nor does being young automatically mean you are wrong. But in my own life, I have noticed that the older generation is right more often than they are wrong, and the younger generation is wrong more often than they are right. Which makes sense, one should get more skilled over time after all. But it means that if you are young, it is a good idea to bet on your elders having the right idea about stuff until proven otherwise.
Old age and treachery beat youth and skill every time:
https://ridiculousfish.com/blog/posts/old-age-and-treachery....
you should see what Linus Torvalds is saying about LLMs
I am well aware. It is also completely irrelevant to my point. The point is that you should never assume a graybeard is out of touch, even if you disagree with him. Most of the time, he knows something you don't by virtue of having had a lot more experience. Not every time! But often enough to make it worth your while to bet on it.
I'm a greybeard too and by that post they made, they are completely out of touch.
On the other hand I’m glad to be on the same side as people I admire like Gary Marcus, Rich Hickey, and Cal Newport
Your heroes could be wrong, I'm a fan of all these folks. But this time around, not on their side. Guess who is on my side? Linus Torvalds for one. see - https://www.phoronix.com/news/Linus-Torvalds-Claude-Code
Compare and contrast with complaining to an LLM that "the margins look wrong".
So it just needs to have one of those properties and not all? LLM is a tool, IMO, it's pretty simple to use it too.
[flagged]
[flagged]
Thankfully reputation is something earned.
Sorry to disappoint your dissidence, but the article was flagged by users and we've turned off the flags now, which means it's back on the frontpage, not being repressed!
Hey dang, while we're talking flags, I made a comment yesterday where two of the replies are now [flagged] and [dead] and yet they both seem innocuous.
#1. https://news.ycombinator.com/item?id=50051731
#2. https://news.ycombinator.com/item?id=50051714
I thought I could 'vouch' them but it's not an option - is vouching time limited?
I'm also wondering what's going on with that user. Their comments all seem fine to me but I notice that a huge amount of their past comments - even beyond my comment thread - are [dead]. I feel a bit sorry for them.
I'm pretty sure there is a limited vouch window. I can vouch the first but not the second, I would imagine you should be able to as well. As far as the poster goes, my best guess is the account is somehow flagged as a bit? I've seen a few accounts where every comment they make shows up as flagged-dead, but I've never been quite sure why.
The second comment was already vouched when you had a look. ;) It wasn't out of place as a comment, but the forum software does automatically mark some comments as dead - going back a month in the user's comments, many do come across as possible LLM content but some people do write that way.
Anecdotal, but I feel like I've seen an uptick in flagging attacks or aggressive reactions to benign comments. It's odd.
[flagged]
You broke quite a few of HN's guidelines with this. Please don't!
https://news.ycombinator.com/newsguidelines.html
(We detached this subthread from https://news.ycombinator.com/item?id=50062384.)
Sorry, Dan. I don't come here to read stereotypical LinkedIn essays. To the extent AI emits slop, LinkedIn is where it learned how. Sometimes a shallow dismissal is just what the situation calls for.
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.
Even if you don't owe LinkedIn essayists better, you owe this community better if you're posting here. Please stick to the rules.
I can’t think of someone more worthy of the collective attention of HN than Rich Hickey.
[flagged]
People have different views. If you feel someone's views are wrong, you have several options, including (1) responding respectfully with more better information, or (2) not posting. Snark and personal attack, however, are not ok, regardless of how wrong someone is or you feel they are.
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...
> some guy I've never heard of
Life is too short to let who you've heard of define your values, and your statement says more about you than them...
Automations are machines, and machines are tools. AI is a tool.
I’ve used coding agaents and more than once in the chat I found myself saying: “oh no, why’d you do that? you are such a tool!” so that’s it!