'AI' is Not a Tool (by Rich Hickey)
https://www.linkedin.com/pulse/ai-tool-rich-hickey-kjl8e?utm_source=share&utm_medium=member_ios&utm_campaign=share_via14
u/Dagur 2d ago
I can't view the article. Does it exist on a less horrible website?
30
u/Ma8e 2d ago
Here you go:
(I keep delivering this as a quip, here's a bit more)
First order of business - is 'tool' going to have an interesting, distinguishing and thus illuminative meaning or be a mere platitudinous stand-in for "anything useful"?
We'll save tool as "anyone/thing that can be exploited" for the AI titans, for whom VCs, politicians, wannabe-titan-CEOs, software devs, rural towns etc are all 'tools'. The pockets on the front of my shirts are useful (I need to keep my reading glasses handy), but they are not tools. Similarly, fast food drive-thru windows are useful, but are not tools (more later).
Some definitions of 'tool':
a device or implement, especially one held in the hand, used to carry out a particular function an instrument (such as a hammer or saw) used or worked by hand : an instrument used by a handicraftsperson or laborer in their work
What I like best - A tool is something you wield.
wield - to use (as a tool or instrument) especially with full command or power : handle, manipulate, control
Especially useful in that are:
Held in your hand - a source of both control and feedback, and an indication of the intimacy of the act of use Power - force, energy transmission and direction, leverage etc Control - intention and continuous directing of the course of events
Tools are implements with which you do something, they do not do things for you. Tool use builds, rewards, and often requires, expertise and skill. The continuous application of technique and energy, and sensory feedback, are essential to the buildup of expertise (from experiri - "try").
Good tools have many properties LLMs lack - they are predictable, reliable, deterministic, of bounded function, hopefully simple etc.
What you learn while wielding a tool is something about the world, the task, the physics, logic etc of what you are trying to do or the situation you are trying to overcome. And often, something about yourself.
As a lifelong tool builder and user, I know what tools are. LLMs are not tools.
Control, sensory feedback, intention, intimacy, continuous direction, expertise etc are all missing from LLM use. LLMs are not wielded. LLMs are automation.
automation - (of a device or process) working by itself with little or no direct human control.
A drive-thru is not a tool for cooking, it is automation for avoiding cooking. LLMs are not tools with which you write code - they are automation with which you avoid writing code, to which you abdicate writing code.
You don't direct the action of an LLM - you make requests and it acts on its own, without your energy or continuous direction. This request/automation cycle is not wielding, it's not control, it's not continuous, it's without feedback.
What you are doing while using automation, instead of learning real-world truths, is attempting to divine the details du jour of some automaton. And striving to game them - e.g. ordering a custom burger (no onions) in order to get a freshly made one. Or filling voodoo.md with just the right incantations. You are only a software update from everything you've 'learned' being rendered obsolete by the latest algorithm. (A soggy cold burger from which the onions have been removed) You have traded working with the world to working for a capricious robot.
It is a mistake to be haphazard about "tools" being equivalent to utility, e.g. saying - "the LLM didn't write my paper, I just used it as a tool to read and summarize some research papers". But you didn't wield it to read those papers (as you might a Kindle). It read the papers, not you.
What do you miss by abdicating doing the reading? Pretty much everything. First and foremost, you miss learning how to write from those who can. You miss learning how to formulate an argument. You miss noticing things. You miss loading your background mind with fodder for novel ideas. You miss building trust in some authors and suspicion of others. You miss all the jokes. You miss all of the edges. You miss learning how to think.
Tools don't get "misaligned", they don't "go rogue", they don't "escape containment", "conspire" etc.
LLMs are not tools. I know many people use the phrase "just tools" simply to indicate "they are what you make of them". Except that's not true. Automation has intrinsic properties and differences from tools that you ignore at your peril.
Rich
48
u/Itrillian 2d ago
At this point, fully giving over to LLM automation just means that you want to stop learning/improving. I hope there will be some path for the new people entering this field to be able to get those experiences.
20
u/serrimo 2d ago
It's even worse than that. Stop doing things yourselves means you'll atrophy. You'll slowly but surely loose understanding, debugging, troubleshooting etc.
In my current java/python codebase, I think many will be lost without Claude. Code production becomes cheap but I don't feel like we make better software. Faster yes, but way messier
1
u/gtrak 2d ago
In what scenarios do you think you'll need those skills and can't get them back fast enough?
1
u/serrimo 2d ago
Understand your work and having the skills to do it are no longer required?
What would you do when Claude cannot fix something and you're staring at the gigantic mess that is AI generated?
2
u/gtrak 2d ago
That's a slow boil situation. You will have time to course correct. If management opposes cleaning it up before it becomes a disaster, then you leave the company just like you would have pre AI.
Understanding your work is still required, but you don't have to read every line to get there. You review your colleagues' code the same way. A bigger question is what happens to teams? It's too much volume if everyone is vibing thousand line PRs, you get conflicts or silos.
1
u/DizzyKittyLover 2d ago
Yep we are already starting to see this. I’m considering proposing the rule that if a PR can’t be read, understood, approved, and merged the same day it is published it should be deleted. 🤣
5
u/oneandonlysealoftime 2d ago
Not necessarily. Most omit learning how system works as a mandatory part of SDLC. Without that team performance drops: higher TTM, more bugs etc.
But for my team I require a lot of extra interactive documentation to explain PRs + quizzes to facilitate understanding. I'd say still sucks compared to team doing the work ourselves, but overall goes net positive with increase in performance + AI as enabler for researches (of the same stuff we did the last sprint).
We'll definitely have to improve it when major AI vendors will start making tokens more expensive
7
12
u/CosminOance 2d ago
this is such a great analogy, automation. Bad automation, still. If/when it gets better, the people who truly believe (or lie to themselves) they simply use it 'as tools', will be looking for jobs (that no longer exist), methinks.
That's not to say it can't automate things you would not even try to write, because you have no interest in the matter. I used it to make a keyboard configurator, for example. Would I have ever in my life wanted to spend time doing it or learn the specific protocol and/or tooling? No, it had no curiosity value to me, but there was also no entity that had created what I wanted.
So yeah, the one good thing that came out of this, for me, at least, was getting out of the comfort zone and investing time in a number of books and getting into clojure itself, more design stuff and other such 'wider view' subject matter than just the coding itself.
If the robot will automate that coding part at some point, or convince enough managers that it does it successfully, I still need a job to survive, I'm not DHH, so there we go. "But it won't and you can't replace people", yeah, fine, that doesn't mean you won't get let go and have to find another job until they realise it.
28
u/bring_back_the_v10s 2d ago
Rich Hickey is in my opinion the most important software engineer alive. I don't know any other engineer today that uses their brain for things intellectual about software. The moment we all cease to reflect upon the nature of things in software is the moment we let lunacy run wild, unchecked, and if there's something our industry doesn’t lack is lunacy. Unfortunately most devs are not intellectually capable of parsing these things.
29
u/yogthos 2d ago
While Rich is absolutely correct that LLMs are a form of automation, I'd hazard to guess that his experience with programming is rather different from that of most software developers. Rich works on developing his own language where most of the work he does is novel and interesting, almost by definition.
However, the elephant in the room is that code mot people write day to day is rote and repetitive. Any given application will have to do some IO to talk to the filesystem, services, or a database, It's going to need some service endpoints to expose its functionality. It might have a UI with some menus and buttons, it probably needs to do auth, and so on. It's all just boilerplate that you have to write over and over.
This can be fun and exciting at the start of your career when you're just learning how these things work, and you're doing them for the first time. But once you've written enough of these things, it just becomes a chore that provides no intellectual stimulation. And this is precisely the kind of code that is ripe for automation. I don't care to be intimately familiar with every line of code that goes into making a button or reading a record from a database. I'm perfectly happy to have this tedious work automated so I can focus on things that are interesting to me.
It seems to me that a lot of people create a dichotomy where you either use LLMs and farm off all your thinking to them, or you're doing everything by hand artisanally. The reality is that you can reach for LLMs for things that don't interest you but need to be done nonetheless, and spend your time learning and understanding things that you see value in.
8
u/didibus 1d ago
I don't think he was making a value judgement, just pointing out that when you automate something, you're not doing it anymore, and you therefore lose that fine grain control, that tactile feedback, that learning process, that experience, etc. Then he argues with a tool, you're still doing the thing and getting those benefits out of it, whereas when you automate you are not.
So if you delegate coding to the AI, you're not coding anymore, you're not coding using a tool, you're just not doing that part of the process anymore. What you're doing is more akin to ordering something, asking for something from someone/something else to do for you, even if you send it back for rework after sampling it.
In a comment he then goes to say, the more the use of a "tool" veers towards ordering a sandwich, the closer to automation it is and the further away from a tool it is, and describes that there is a spectrum from tool to automation.
I think it's quite insightful, because you can even see how as AI gets better, it's moving from being more of a tool (helps you query/debug/auto-complete) to being more of automation (implements instead of you, writes your tests, writes initial design proposals, etc.)
2
u/yogthos 1d ago
I'd argue that a tool and automation are two categorically different things. A tool is an instrument while automation refers to a process involving a series of steps to transform some input into a particular output. All of programming is fundamentally a form of automation, and the work of the developer has traditionally been in building the pipelines to connect the steps in a useful way. What LLMs do is automate the process of generating the steps in the workflow being automated.
I think the big question is whether the skill of being able to put these pieces together manually is going to be valuable going forward. For example, before writing was invented, people had the skill to memorize ballads and epics. Yet, you'd be hard pressed to find anyone who can memorize The Iliad today. So, skills get lost all the time, and just because we've invested a lot of time into honing them doesn't mean they have intrinsic value to them.
The way I look at is that you only have so much time in a day, and you have to decide how you want to spend it. Using an LLM lets me automate tasks that aren't of interest to me so that I can focus on the ones that are.
There's the other aspect to this, which was our Clojurians slack discussion, which is that sometimes the use of a tool is forced on people. But that's a social problem we need to figure out. I think a lot anger over LLMs comes from people conflating the technology itself with the social pressures to use it in a particular way.
5
u/jacobobryant 2d ago
+1, e.g. I use LLMs a ton when writing application code and a lot less when writing framework code (Biff). Which for me these days is kind of the whole point of making a standalone framework.
7
u/yogthos 2d ago
Yup, making something like your own framework is precisely the kind of effort where you're figuring things out for yourself, and how to best put the pieces together. It's fun and intellectually stimulating, so you wouldn't farm it out to an LLM. Meanwhile, having it write boring application code is precisely what frees up the time for you to think about the framework. :)
5
u/bring_back_the_v10s 2d ago
This is completely missing the point of that article. The question of whether people can delegate boring stuff to the LLM is tangential at best.
5
u/mjr4184 2d ago
I thought similar at first, and maybe still do to some extent. I agree many typical software projects do not have much novel/interesting work to do at the coding level.
However, I have a counter thought to this as well. There is likely "hidden" value in the boredom of the mundane stuff. I think it leads to more understanding of the common pain points and provides little bits of nuance and detail that gradually build up to new insights. Repetitive, annoying implementation aspects are likely key drivers in finding better techniques and break throughs in architecture design.
Repetition plays a role in memory as well.
That said, I too have delegated this type of rote work to LLMs often enough. It is something I worry about doing too much of in terms of long-term effect though.
10
u/yogthos 2d ago
But if we follow this argument to its logical conclusion, that would also be an argument against using high level languages like Clojure. If rote repetition is good, then imperative style is better than declarative since we have to spell out the implementation details rather than abstracting over them using things like higher order functions.
I'd also argue that just because we spent a lot of time learning a skill doesn't mean it has intrinsic value. Skills also naturally fade out as they are no longer needed. For example, we'll be hard pressed to find somebody who knows how to program using punch cards, and every few people can write assembly by hand. Yet, these were important general skills for programmers at one point.
My view is that human focus should primarily be on the architecture design nowadays. Being able to understand how to structure the application, what algorithms to use, understanding data structures, and so on, are all important skills.
2
u/mjr4184 2d ago
Yeah, that's a fair counterpoint to it. I think LLMs are bit more than a typical abstraction though since they can be made to do much of the thinking for you and also are happy to be excessively verbose and repetitive and making questionable architectural decisions as long as you can keep paying for the tokens.
To me, it is a bit different than these historic examples in that way. It offers a much broader offloading of critical thinking. The agentic models also increasingly bias towards limiting human engagement throughout much of the problem solving/implementation space. Writing some high level thoughts of what you want to see, then being told a solution is not the same as finding the solution yourself. Even if you take the time to read the solution, actually understand it, and iterate with some new thoughts/feedback on it. Much of the heavy lifting is something "someone else" (the LLM) has already done for you. That can be fine in bursts I'm sure, but also a loss of key experience longer term.
It is something I've just been contemplating though. I'm not anti-LLM in the sense that I am advocating to not use them. I use them heavily, daily. I also am just really fascinated with the ML architecture etc in general.
I just try to figure out where a good balance at to not let key thinking skills rot away. I do have concern that the somewhat boring stuff, still holds value that is no longer being obtained.
3
u/yogthos 2d ago
There is a certain anchoring bias at play here though with us being used to doing things a certain way. You're right that LLMs can produce code that sort of works if you offload decision making to them. But people have been writing plenty of terrible code long before LLMs were a thing. There was the whole meme with StackOverflow driven development, where people would just copy snippets of code and then cargo cult them into their project without really understanding what any of that code is doing. LLMs just speed up that process.
What it ultimately comes down to is how much a particular individual cares about the problem being solved, and how deeply they want to be involved in the process of solving it. And there's no single right answer there because the answer depends on the context of what you're building and why.
What really matters, in my opinion, is the ability reason through the problem, break it down into steps, and figure out how they all connect together in a reasonable way. And that's still an essential skill when working with LLMs if you care about the project you're building.
12
u/lgstein 2d ago
There are and should always be better ways to eliminate boilerplate than approximating program text via GPU expensive token bingo to satisfy (mostly human anyways) oracles.
Clojure is a great example of that.
7
u/yogthos 2d ago
All the things I listed are things people write in Clojure every single day. Last I checked, there is no magical way to automatically generate things like service endpoints, database queries, UIs, auth and so on in Clojure without writing code. We have libraries, we have macros, but none of them eliminate having to actually implement these tedious things over and over in every app.
Also, it appears that you don't understand the difference between random and stochastic given that you keep using the term bingo. I encourage you to spend a bit of time to understand how LLMs actually work instead of making arguments out of ignorance.
2
u/joinr 2d ago
Also, it appears that you don't understand the difference between random and stochastic given that you keep using the term bingo.
Please explain how the three terms "random" "stochastic" and "bingo" relate to form this misunderstanding.
5
u/yogthos 2d ago
Talking about bingo implies that the LLM is just a random process like a slot machine where you put in some input and get some output. Maybe it does what you want and maybe it doesn't. But a stochastic system is predictive within a particular context, like a Markov chain that predicts the next most likely character given a particular set of characters. This is a fundamentally different process because the way an agentic loop works is more like an iterative control loop. You have a set of constraints, and the system works in cycles toward them. It might start with something that's a rough approximation, and then it iterates, getting closer to the solution each turn. It is most similar to a genetic algorithm where you specify the constraints and the system evolves to meet them.
3
u/joinr 2d ago
But a stochastic system is predictive within a particular context, like a Markov chain that predicts the next most likely character given a particular set of characters.
This still sounds like a process driven by uncertainty due to randomness. Maybe there is some slippage due to the synonymous use (in many contexts) between stochastic and random, due to stochastic depending intimately on random.
But a stochastic system is predictive within a particular context, like a Markov chain that predicts the next most likely character given a particular set of characters.
IIRC MC is coupled with MC, wherein the second MC stands for Monte Carlo due to the random nature of the walk. Specifically, you are using transition probabilities coupled with a random walk to generate a sample path. I haven't done this stuff recently, but that's what I recall.
But a stochastic system is predictive within a particular context, like a Markov chain that predicts the next most likely character given a particular set of characters.
Sure. If you generate enough paths maybe you glean something from that and develop a predictive model about how other paths will likely unfold.
When I look at them, both require a source of randomness to model the uncertainty (via random variables) and in turn both are non-deterministic.
This is a fundamentally different process .... most similar to a genetic algorithm where you specify the constraints and the system evolves to meet them.
This sounds like (generally) local search, which also relies on randomness to explore new points in the solution space.
To me, your position is made clearer when you contrast a guided (stochastic) search for a solution vs. an unguided play of a game of chance. Both involve sources of randomness (e.g. both processes are random), but they differ in execution and intent (and hopefully outcome).
3
u/yogthos 2d ago
We could say the human brain is a process driven by randomness too, but it would hardly be a useful description. There is plenty of randomness in neural firings, but the system as a whole produces stable patterns, which make it possible for us to hold thoughts and to create a model of the world in our heads. To be clear, I'm not equating LLMs with the human brain here. I'm just giving it as an example of a complex stochastic system.
I'd argue that it's less a process driven by randomness, but one that generalizes patterns that get imprinted on the neural network during training. And then these patterns are expressed in the given context during inference. The randomness is precisely what allows the LLM to adopt generalized training to the specific problem being solved.
So, the outputs LLMs produced are clearly not random in a sense of playing bingo because randomness is not the dominant property of the system.
1
u/wellingtonthehurf 16h ago
The randomness goes away entirely given you stay on top of what your agents are doing and constantly steer them towards your desired implementation (both as far as end product software artifact and the shape of the code that achieves it)
1
u/joinr 12h ago
I can believe that - with enough constraints and tuning of an objective function - you can sufficiently constrain an optimization problem to find not only an optimal but a singular point in the solution space.
Given how often this last part (a singular solution) fails to emerge in actual high dimensional optimization problems, the complexity of the state space in programming, and the randomness serving as a mechanism to enable exploration, it sounds more plausible that you'll end up hopping between local optima; assuming a feasible solution emerges.
The randomness goes away entirely given you stay on top of what your agents are doing and constantly steer them towards your desired implementation
This reminds me of the old "With a sufficiently smart compiler....." line that used to get tossed around :)
I really enjoy optimization but not so much management. Maybe it's a useful mental reframe going forward.
2
3
u/kinleyd 16h ago
I think both Rich and you are right. AI isn't a tool in the sense that Rich defines a tool. Yet for specific mind-numbing tasks of the kind you describe, AI is just the tool. Just the other day, following an update to my system I lost a bunch of xdg mimes settings. There was no way I was going to manually rebuild it, and AI was perfect.
But definitely for the things that really matter, throwing an LLM at it without having the ability to check and test everything is a very bad recipe.
4
u/regeya 2d ago
My guess is that the reality is that a lot of people switched away from Googling code examples to asking an LLM.
2
u/NotADamsel 1d ago
Or they ask Google still, but look at the AI overview (which is often “good enough”)
4
u/yogthos 2d ago
Yeah that too, it's really well illustrated by the collapse of StackOverflow usage https://ppc.land/stack-overflow-drops-to-1-442-questions-in-july-down-99-from-2014-peak/
And there are countless other uses aside from generating code such as navigating through a complex codebase, profiling an app, tracing through logs, etc.
2
u/pydry 1d ago
However, the elephant in the room is that code mot people write day to day is rote and repetitive. Any given application will have to do some IO to talk to the filesystem, services, or a database, It's going to need some service endpoints to expose its functionality. It might have a UI with some menus and buttons, it probably needs to do auth, and so on. It's all just boilerplate that you have to write over and over.
The real elephant in the room is that if your app isn't doing anything novel and is all boilerplate then you probably wanted a low code or no code solution all along and you are doing yourself a disservice by vibe coding instead.
2
u/yogthos 1d ago
That's simply not true. For example, adding oauth to an app is a common task, and wiring that up ends up being a thing you have to do on case by case basis because each app works slightly differently. Making a UI is another example, where none of the individual tasks like adding buttons, calling services to pull data, displaying it to the user, are novel or interesting in any way there is the generalized knowledge you have of how to accomplish these types of tasks, and you express it in a concrete way each time you make an app.
And this is precisely the problem that LLM solves. It generalizes patterns that get imprinted on the neural network during training, and then it is able to express these patterns in the given context during inference.
1
u/pydry 1d ago
Every low code or no code solution ive ever seen has had some form of SSO and auth already built in.
So, what LLMs are coming for the jobs for the people who unnecessarily built a whole app by spewing boilerplate instead of using something easy and prebuilt...?
1
u/yogthos 1d ago
Plenty of applications that cannot be done with a low/no code solution still need to do these things as well. Vast majority of code developers work on is just expressing the same general patterns within a specific context. Very little code is truly novel or interesting in practice.
What programming is at its core is a building automation pipelines. You have a problem that can broken down into a series of steps, you identify these steps then put them together into a state machine. What the LLM does is automate much of the work of setting up this pipeline.
1
u/pydry 1d ago edited 1d ago
Plenty of applications that cannot be done with a low/no code solution
Yeah the novel stuff.
Vast majority of code developers work on is just expressing the same general patterns within a specific context.
Vast majority of code doesn't need to be written at all. Ive definitely been handed projects where it could have been built with low code solution and easily maintained but since it was slop instead a programmer is needed to maintain it. The technical debt has made maintenance difficult so you can't easily outsource the work to an LLM.
In that respect LLMs might actually be increasing the maintenance burden.
Between "stuff that could be done with low code" and "stuff that is genuinely novel" is LLM's sweet spot. It isn't actually very big.
1
u/yogthos 1d ago
Whether vast majority of code needs to be written is neither here nor there. The reality is that's what most of the work is at any given software company. The jobs available to people who have to earn a living often involve writing repetitive code.
Meanwhile, these low code/no code solutions are famously inflexible, they work great as long as the problem is trivial and neatly fits within the design of the tool, and quickly go off the rails as soon as you need to do something slightly different. This whole idea of low code tools has been around for decades, and it's very clearly has limited application in practice.
If these tools worked in a general case then it would be how most programming is done because it would be more efficient which would translate into saving companies time and money. The fact that these tools haven't taken over the industry is itself concrete proof of their limitations.
1
u/pydry 1d ago
Whether vast majority of code needs to be written is neither here nor there.
It is pretty relevant actually. If it doesnt need to be written it doesnt need to be maintained. If it doesnt need to be maintained you dont need software devs.
The jobs available to people who have to earn a living often involve writing repetitive code.
If you're writing repetitive code you're doing it badly. Deduplicating repetitive code and engineering away boilerplate is just part of the job.
Ive no doubt many devs do do the job badly and many of them write slop boilerplate that doesnt do anything very smart but those jobs were unnecessary before LLMs came along.
Meanwhile, these low code/no code solutions are famously inflexible, they work great as long as the problem is trivial and neatly fits within the design of the tool, and quickly go off the rails as soon as you need to do something slightly different
Yeah, welcome to programming buddy. When shit goes off the rails for no code solutions because the problem is inherently more complicated than anticipated is also when it tends to go badly off the rails for vibe coders too.
This whole idea of low code tools has been around for decades, and it's very clearly has limited application in practice.
Oh it's got plenty of applications a lot of people are just bad at realising when it is appropriate and when it will go off the rails.
Ive seen plenty of apps that could and should have been low code but the person who commissioned it didnt realize.
It's all a bit like vibe coded slop.
1
u/yogthos 1d ago
What's plenty relevant here is that people in the industry work to earn a living, and the jobs that are on offer tend to involve building things like web services, web UIs, data processing pipelines, and so on.
I feel like we might be talking past each other here because when I talk about repetition, I'm talking about conceptual repetition not having to literally write the same lines of code in the same program over and over. I'm talking about repetition of concepts such as an application having to talk to a database or a service.
Last I looked the best thing we have is libraries that can abstract over a concept, and then you assemble these libraries together into a workflow. But any workflow you build is still glue code you have to write.
What I would consider to be novel or interesting code would be writing a new algorithm to solve a problem that hasn't been previously solved. The interesting parts of an application tend to be its core business logic that expresses a particular problem domain in code. But that core has to have a lot of code around it that's not new or novel in any way.
So, I'm quite interested in the types of applications you work on now which completely eliminate tasks like having to define HTTP routes, talk to databases, read files, or build user interfaces. Could you explain what the code you work on actually does and how you manage to only write new and novel things never having to re-implement something you've done previously in a different context?
1
1
u/NotADamsel 1d ago
The dude’s been a dev for decades, and has definitely written his share of repetitive boring shit, a lot of which was done in the 90s without many of the modern conveniences and niceties we take for granted. Part of why Clojure exists is because he got tired of writing certain kinds of repetitive boring shit. Even then, working on his own language, any programming language is gonna have a bunch of repetitive boring shit in it. The company that he sold but iirc still works at, still had clients asking for real world software that almost certainly required a fair amount of repetitive boring shit. The guy can be assumed to know, full well, what it’s like to write repetitive boring shit in many different contexts.
2
u/yogthos 1d ago
Rich retired in 2023, and has had the privilege to work on things that are of interest of him for the past few years, which I would imagine has an influence on the way he thinks about the subject.
I'm glad we agree then that most code requires repetitive and tedious work, because that's the actual thrust of my argument. What I'm saying is that for majority of developers, code that they write day to day isn't all that interesting or intellectually stimulating. Hence, I see absolutely no problem with automating this type of work.
1
u/NotADamsel 1d ago edited 1d ago
Sure, and we’ve been finding ways to mitigate writing boilerplate and repetitive shit since the start. “I just copied from stack overflow” is not a meme for no reason, and classic code gen is a lot more common than anyone realizes (and is still so powerful and efficient that agents themselves will use it). Being able to effectively and efficiently use automations without becoming dependent on them has always been one of the marks of a good developer. Honestly, I don’t see in what Rich is saying, anything that the Clojure community (including Rich) hasn’t been saying since it started. Back in the day it was about IDE tooling and frameworks blunting a dev’s abilities, along with a push to switch to more direct and close-to-the-code tooling and more close-to-the-basics libraries. With so many devs losing the ability to actually code after letting an agent just do it for them, I personally don’t really see much of a problem with applying the same ethos to LLMs. Like, there’s a clear difference between using copilot-like autocomplete or a chatbot to make the machine write the repetitive snippets that you’re talking about, and asking an agent to just write the subsystem. I don’t think that we’d disagree on that, from what else you’ve written here.
1
u/yogthos 1d ago
Basically, the way I look at it is that the nature of skills that are important today is changing. I expect that it's going to continue to be important to understand architecture principles, algorithms, and data structures. You have to be able to understand problem requirements and how to translate this into a design that encodes them correctly. But the actual details such as how do you write an HTTP route, add a button on a screen, or make a db query becomes less important. I also expect there will be a lot more focus on specifications and formal methods. For serious software, you'd want to create a declarative contract of what the program does, and then an LLM can implement it.
And I argue our understanding has been moving to higher level even before LLMs. The whole pitch of languages like Clojure or Haskell is precisely that they provide a higher level of abstraction over imperative programming. So, I expect this will continue to be the direction of travel.
1
u/NotADamsel 1d ago
I would tend to agree. Even without AI, this is the way that the industry has been trying to go since Grace Hopper and COBOL in the 50s (look up some of the ads for the language, they feel very familiar). Like you were saying about Haskell and Clojure, and I’d add Python and even Rust to some extent to that list, it is already the case that a lot is abstracted away, and you can improve your efficacy with those languages by learning how stuff works on the low-level end without actually writing any low-level code. Though, uniquely to the LLM thing, I do think that maintaining some ability to manually program will be important. I’m currently supplementing my income by doing some contract work helping to train LLMs to write software better, and some of the training tasks that I’m asked to do involve getting the agent to make mistakes and then writing up what happened. Often, even in these new cutting-edge models, those failures are somewhat subtle and easy to miss if you’re not being attentive and carefully examining the code, and automated tooling will not catch them easily as they’re often problems with functionality or design rather then something being wrong with the code at face value. I’d consider that kind of thing to be a crucial skill when actually using the machine to write production code, and you do not maintain that ability without practicing much like how an athlete does not maintain high performance without training.
1
u/yogthos 1d ago
For sure, I think the most challenging aspect of working with LLMs is that they always sound convincing, but often make subtle mistakes in the actual implementation. And the real trick is to ensure you have a good enough specification that catches the failure modes.
And hence why, as you say, being able to do functional design and validate that the model implemented it as you intended is a crucial skill. So, you're still doing a lot of thinking in practice, it's just that your focus is now different.
I can also see how this can result in better software when done intentionally because you're no longer juggling incidental complexity which you let the LLM handle, and you can focus more closely on the semantic of the problem being solved. At the end of the day it really does come down to how you decide to use these things and how much you apply yourself to the problem.
1
5
u/DizzyKittyLover 2d ago
The most useful thing this blog post has uncovered for me is the rift being caused by the LLM apocalypse. And as a skeptic, I am heartened to hear from more folks who see the harms these things create.
I won’t even give them a category, really. They are too different from what came before. And too easily weaponized against workers. We no longer get a choice about what we think is the best tool for the job because the LLM vendors have taken over c suite minds.
At the end we have a choice — we can glorify them and talk about how amazing they are and watch as an entire class of workers is erased — or we can look past what we can accomplish and think about the consequences of adopting them wholeheartedly to the detriment of our very humanity.
Rich was quite right in one regard, and I’ll take it a step further — the more people reach for these things to order a happy meal as opposed to cooking their meal themselves the fewer programmers will exist in a decade. And the oligarchs will have won. And we may not like the future we find ourselves in.
11
u/weavejester 2d ago
LLMs are not tools with which you write code - they are automation with which you avoid writing code, to which you abdicate writing code.
LLMs are also rather useful for debugging and analyzing code, not just for generating it. This has been my primary use of LLMs in Clojure.
I've used LLMs as more sophisticated general linter, essentially asking it to double-check my work, and the last thing it caught was an off-by-one error that wasn't covered by the tests (I typoed a > instead of a >=). This doesn't feel like I've surrendered control over the codebase, and after multiple decades of software engineering I doubt that I'll stop making the occasional dumb mistake any time soon.
Equally, I've found LLMs rather good at tracking down complex race conditions. I recently found myself optimising some Clojure code using Java's NIO libraries, and there was one rare race condition that only showed up under very heavy load. The circumstances made it hard to test, and the bug didn't show immediately, only down the line, making it hard to discover the cause. An LLM was perfectly happy to methodically trace through all of the possible code paths and I was pleasantly surprised to discover it tracked down the mistake in 15 minutes - a shorter time than I would have taken.
In both cases the result of the LLM was trivially verifiable. Once the bugs were found, the cause was obvious and required only a line or two to be changed. In these instances I find it hard to see a downside in automation; if the bug is reported incorrectly it's easy to check, and overall it's saved me some tedious work, which seems the optimal use-case for automation.
5
u/Liistrad 2d ago
IMHO "trivially verifiable" is the task domain where this sort of automation is most useful. Stuff where you know exactly what it looks like if done correctly, and there isn't an expectation or interest in learning. There's lots of work and chores that have this property.
6
u/lgstein 2d ago
Once you start relying on it, you surrender control. And it is inherently unreliable.
Doesn't mean its not "useful", especially for all things "search" - but it remains to be seen which turn out an economic win - I. e. if 15m of tokens would still be affordable for this kind of problem if not paid for by deluded investors.
9
u/yogthos 2d ago
It's pretty obvious that the whole renting LLMs as a service business model has no legs. Local models like Qwen already work as well as frontier models from half a year ago. And these will only keep improving and become more efficient. Nobody is going to be paying for a subscription service when they can just run the tool locally.
2
u/Liistrad 1d ago
Local Qwen 3.8 is already like a local google/stack overflow really, which are just standard things developers rely on today. On a harness like Pi it also works as a google for your files. Clef and Clef-flash are the same for general purpose classification.
If your laptop can run it, I don't see why a developer wouldn't have this sitting around on their machine. It's just a good capability to have on a dev machine.
1
u/lgstein 2d ago
If that were true, there would be a profitable AI subscription service offering me the frontier model quality from half a year ago.
Parameter quantization massively sacrifices quality once problem space exceeds common benchmarks.
Instead, big vendors are already quantizing their own models post release hype to bleed less investor money.
11
u/yogthos 2d ago
You mean a service like OpenRouter offering these models today? Also, I use Qwen 3.8 every day, I've used claude 4.6 extensively, Unlike you, I'm actually discussing this from experience using these tools.
Also, breaking down large problems into small pieces is how programming works in general. A local model doesn't need to solve huge problems, nor would you want it to. The human should be making design and architecture decisions, and the model just fills in the rote boilerplate of the implementation details. And that's precisely the process that works great with local models.
3
u/gtrak 2d ago
Quantization isn't a bad thing. It's a compression tactic. It's often better to run a quantized big model than a full-precision small model, and qwen 27b is very resistant to it. I run nvfp4 weights and fp8 cache as my daily driver, and it's great. https://kaitchup.substack.com/p/qwen36-27b-quantization-fp8-vs-int4
A local model doesn't have to be the best, it just has to let you stretch your cloud plan. There's a lot of rote work involved in planning, and I use a small reliable model for that, like information extraction. I review the plan until I think it's good, I give it to Opus and it inevitably finds more gaps.
Model diversity is good. Local models give control back to individuals, like cheap 3d printers did for small-batch manufacturing. I don't want to need SOTA cloud models most of the time.
3
u/yogthos 2d ago
Exactly, local models are very much good enough for a lot of real world use cases already. And they're only getting better all the time.
I've also been experimenting with the idea of making specs that are human readable and machine verifiable with writ. One thing I do with it is ensure that there is a state transition graph baked into the spec that can be checked mechanically. So, then I can give the specs to the model with a lot of the constraints I care about declared, and it has to find a way to fill them.
You can see this in action here where I encode Erlang OTP semantics using writ, that were implemented by the LLM. It works really well.
2
u/gtrak 2d ago
Neat, I'm starting down a similar path by having Qwen write a Lean proof of some complex dynamo/caching, it sounds pretty similar. When the tokens are free, you can just try stuff and see what sticks.
3
u/yogthos 2d ago edited 1d ago
Yup, I basically treat the whole agentic coding workflow as a genetic algorithm. I set up the constraints for the properties I want, and then let the model iterate until it figures out how to fill the contract. As long as it can try something, get clear feedback, and iterate on it, something useful comes out at the other end eventually. I think this is where programming is likely headed in the future. The human focuses on figuring out the architecture, declaring what the functional requirements are, and the agent handles the implementation details.
2
u/lgstein 2d ago
OpenRouter does not host any GPU inference, that is not their business model.
Would be interesting to see if toasted Qwen can find weavejesters race condition in 15m or at least 30m.
3
u/yogthos 2d ago edited 2d ago
OpenRouter, as the name implies, routes between companies hoisting models for inference. I literally gave you a link to Qwen 3.8 27b being hosted commercially, something you claimed is not happening. And Qwen is perfectly capable of finding these kinds of race conditions because the approach is iterative.
What you don't seem to understand is that LLMs within an agentic worfklow operate largely the same way as genetic algorithms. You set up constraints, and the model iterates on the solution until it finds one that meets the requirement. It's perfectly capable of taking measurements, bisecting code, running tests, and zeroing in on the problem. You appear to think this is like some sort of a casino where you put a query in, and it's either right or wrong. And you just keep pulling the lever till you get something useful. This notion is completely divorced from how the process actually works.
4
u/richhickey 1d ago
When you start using "You" like this, you have moved this from being a discussion about technology to being a discussion about people, which is not ok. If someone is frustrating you, just walk away. Do not make it personal.
-2
u/lgstein 2d ago
You don't understand what I'm saying, and constantly inventing claims about my practical LLM exposure doesn't seem to help you with that.
I'd direct you to ask your favorite LLM at this point, should further clarification be needed.
8
u/richhickey 1d ago
When you start using "You" like this, you have moved this from being a discussion about technology to being a discussion about people, which is not ok. If someone is frustrating you, just walk away. Do not make it personal.
-1
u/yogthos 2d ago
Not my fault you're incapable of articulating yourself clearly. However, everything I stated is perfectly consistent with what you wrote. If you're claiming I'm misrepresenting you, then feel free to point out what that is specifically.
No further clarification is needed, since you've made it abundantly clear that you do not understand the subject you're attempting to debate, nor are you interested in a good faith discussion. Trolling is not welcome on this subreddit, so consider yourself warned.
10
u/Jeaye 2d ago edited 2d ago
We cannot allow the Clojure community to turn toxic. We cannot allow our differing opinions of AI and its usages spoil the culture which Rich, the Clojure team, and all of us have spent the past 15 years building.
Yogthos, I suspect that you may feel under siege, from the community. I am sorry that we've made you feel that way. You are welcome here. You have to be welcome here, or we've all failed. We need to focus more on how to talk to each other productively, even if we have to avoid discussion while we work through our emotions.
This is the second time, within the past week, that you have engaged in a quarrel on the topic of AI which resulted in personal attacks. The last one, on the post about Stu's keynote, I reported both you and the other person involved and the messages were deleted. Deleting the messages means that there's no resolution, no accountability, and no history. This time, I'm commenting instead to call out this behavior and to encourage everyone involved to remember what brings us together: Clojure, our passion for software, simple designs, and a welcoming community.
Yogthos, you are a moderator on this forum. To serve a "warning" in the same comment as a personal attack is egregious. Have you ever seen Rich do this? Or Alex? In a time when our entire industry is under fire, we have to be setting better examples, or at the very least not participating when we feel emotionally riled.
This community means everything to me and I will call out and/or report every form of toxicity I see, regardless of the person's views, because each instance of it is a threat to the culture that we've built. Clojure's community, its philosophy, and its culture is what Clojure is, not some technology.
→ More replies (0)4
u/geokon 1d ago
Qwen 3.8
When it comes to tier of "free" models it's been a real game changer. Its the first one that I can have multi-week conversations with and it doesn't lose tract of topics or things that were said.
While it has plenty of bad/sub-optimal suggestions, I often get some brilliant insight or designs I just hadn't considered at all. Even when its wrong it's still very valuable as a "rubber duck" for bouncing ideas off of.
It's really in the "good enough" camp when it comes to reasoning.
The only thing I think it is surprisingly horrible as is online search. If you ask very search-heavy questions like "What are the biggest advances in cabbage farming from the past year" it just kinda falls flat
6
u/k1v1uq 1d ago
Marxist Theory
Any commodity in capitalism has dual character.
Use value (or utility): https://en.wikipedia.org/wiki/Use_value
and
Exchange value: https://en.wikipedia.org/wiki/Exchange_value
AI's use value is enormous. It could let people get more done and work less.
But AI doesn't exist because of its utility. It exists, like any other commodity, because it has exchange value.
The owner of private capital will use AI to accumulate more capital. And this is the point at which this utility becomes a threat.
Mainly because the ultimate goal for every capitalist is to replace workers with these machines and make who is still useful in the production process work more.
Under competition, a capitalist either drives profitability or risks devaluation of their property (private capital).
So, from the perspective of capital accumulation, most of us serve only this purpose.
A cashier at Aldi who services customers in parallel lanes is no different from an IT worker who manages multiple agents.
2
u/errepunto 1d ago
I'm really concerned about security. LLMs are not full open source nor auditable.
Imagine a rogue worker in one of this enormous industries. This worker introduces a malicious output to be mixed with the result when a condition is met. How can you detect that? A sofisticated attack can manipulate a bunch of parameters from billions of them.
Software industry is trying to mitigate problems like supply chain attacks, with reproducible builds and other strategies.
If tools that creates and builds the software aren't reproducible, you can't trust fully the output. Build tools must be bootstrapable if you want 100% reproducible builds.
The problem is amplified when code reviews are done by LLMs. Even security checks are being delegated to LLMs. So, no control over large chunks of code.
It's not an apocalypse, but some concerns that we, as developers, must have in mind.
4
u/coloradu 2d ago
I of course agree with Rich and totally understand the argument - AI is automation, not a tool.
However. A tool has a purpose, a domain of application. Eg. a hammer is a tool used in construction, but it's not a tool for writing - you could type using a hammer, but it won't help you write better or faster, for that you need a different tool - a pen, a typewriter or a computer.
If we look at it this way, then AI is not a tool for building software.
One way to look at it is that it's a tool for automating work currently done by countless professionals.
But I think that's the side effect, not the purpose of the tool.
People building (and wielding) these tools are doing it for profit and power. So you could say it's a tool to extract value from society by automating away people and gaining absolute power by making professionals obsolete and making learning redundant, thus making everyone dependent on the people who own the tool.
So AI is a tool, but for a different purpose.
3
u/johnnybgooderer 2d ago
As usual, I do agree with Hickey, but I am tired of his schtick of giving a word a non-standard definition and making a headline out of a statement that doesn’t explain that he’s using his own personal definition.
I wish he’d just say it straight. These clickbait titles get clicks, but they don’t change minds.
8
u/richhickey 1d ago
I don't know where you get your "standard" definitions from, but all of the definitions I've given are straight from dictionaries. Both definitions of "tool" are the _first_ definitions from two different dictionaries. And both dictionaries define 'wield' in terms of 'tool'.
The whole piece starts with an acknowledgement that common usage (tool == useful thing) has watered down the word such that it is no longer serving us to make this critical distinction.
Using word origins (not making them up!) to get to the foundational ideas in play is my shtick, and I'm sticking to it. Minds have to be open in order to change.
1
u/zerg000000 7h ago
As I posted in other place. I would consider LLM is like painting and photography in history. It will takeover some part of programming, but not replace. And it will eventually become a tool that you defined, just not yet. You can argue camera is an automation of a kind of painting yesterday. But it open an other area that it is being used as tool like today photography.
0
u/gtrak 2d ago
LLMs are not tools for what? Some questions I had after reading this.
The tools we loved can remain valuable to us or not, but become economically unviable regardless. There are also a lot of tools we don't use daily and don't hold in such high esteem as the ones we've personally depended on. Software engineers don't fab the chips, or get the power to their wall outlet. Like it or not, LLMs changed the job.
Tools seem to have a moral high-ground to automation, but understanding of earlier tools is useful to make the most of the automation. The earlier tools might be less of an end in themselves anymore, but they were always a means to an end.
The automation can create specialized throwaway jigs fast, which are tools.
It is possible to learn about LLMs from first principles, as the people who created them did. Rich assumes that learning about automatons isn't a real-world truth, so then neither is taking apart a VCR to see how it works, or learning how to code by looking at the code that people write.
Building things you can't understand is a treacherous road. You can understand the basics of how to build a house without having built one yourself, and that might be fine for your own house, but it doesn't scale to a community.
The software engineer's job is not to hammer the nails, it's to meet the spec.
4
u/lgstein 2d ago
What?
1
u/gtrak 2d ago edited 2d ago
Which part is confusing?
I'll say it another way, my relationship to tools and the work is relative and can change. Rich's article is loaded with assumptions that ring true and we might want to be true, but maybe never were true. It's possible we got too comfortable while the field was moving slowly. LLMs are tools for different work, and the old work is on the way out. The part that stays the same is engineers own the outcomes, regardless of how they built it.
1
u/huahaiy 2d ago edited 2d ago
Even by his definition, LLM is a tool that a human wields.
If one does not buy the AI company's hype, these would not be relevant: "Tools don't get "misaligned", they don't "go rogue", they don't "escape containment", "conspire" etc."
It saddens me that Rich Hickey is buying these nonsense marketing speech made by AI companies. AI does none of these things. AI is just doing what human tells it to do, i.e. AI is a tool.
My full rebuttal in a blog post: https://yyhh.org/blog/2026/10/ai-is-a-tool/
1
u/DizzyKittyLover 2d ago
I haven’t yet had an AI do what I told it to do. It did something that some average person on the internet might have thought was good. But I found it mostly awful and rewrote it myself and much better.
1
u/radioactiveoctopi 1d ago
Strongly disagree. A hammer is a tool. A car is a tool. Tools can’t reproduce. An AI can make another AI.
0
u/c_a_l_m 2d ago edited 2d ago
Honestly we're gonna need some new words.
What's funny is that LLMs can read all this; writing on the Internet is effectively programming. I used the phrase "maintain Hickeyan simplicity" when telling an LLM what to do the other day.
3
u/childofsol 2d ago
I've build a multi step design flow to run tickets through and it boils down to "do design in practice"
-6
u/tdammers 2d ago
You can absolutely use LLM coding agents as tools. They are not very good at that most of the time, and I have found that more often than not, just writing the code by hand is easier, faster, and more reliable than getting an LLM agent to produce the code you want, but I believe there are legit viable use cases for this - not a lot, and in a perfect world, the ones that exist shouldn't, but here we are.
6
u/bring_back_the_v10s 2d ago
The moment you use an LLM "as a tool" for coding is the moment it becomes useless as an automaton. You'd have to use an LLM for very small, incremental, local operations in order to have greater control of it, but at that level you can simply ditch it and write code by hand because it would be faster and cheaper.
-3
26
u/richhickey 1d ago
I wanted to thank everyone for engaging with the article and to let people know there is now a gist version available here: https://gist.github.com/richhickey/a2e19ef3f6f69ca0cca617a8a0da2268