I’ve been meaning to write about this for ages. Today I’m reading something that is helping me crystallise the thoughts.
The things that people compare LLMs and agentic software development to really bother me as they are not equivalent.
People compare LLMs to the machines that brought about the industrial revolution. Looms, printing presses, factory equipment, and so on. Mechanically powered tools that enabled rapid and accurate reproduction of goods with reduced labour. (My definition, by the way)
The implication/suggestion is that we, the developers, become mere operators of these tools.
People also compare LLMs to software compilers – only now the source language is English and the target language is … whatever you want it to be! Compilers meet the same definition of factory machines that I gave above: “Mechanically powered tools that enabled rapid and accurate reproduction of goods with reduced labour.”
LLMs are not this. They are “mechanical” – they are a machine of some sort. They are fast, for sure. But they do not do accurate reproduction.
Imagine a loom that produced a slightly differently patterned fabric each time. Or a printing press that occasionally skipped – or added! – paragraphs or pages.
Developers using LLMs would agree with this – “we are still needed” they say – “we need to guide the machine”. There is still a “human in the loop”. And it’s not just stop the machine / start the machine / oil the machine / unclog the machine – LLMs and developers work together to produce output.
The need for this kind of “human in the loop” confirms to us that the LLMs and agents are not the same as factory machines and compilers. Factory machines produce the same output for any given inputs.
So what are LLMs, if not “factory machines”?
Today I’m reading Kristen Maevyn’s “The Decoherence Trap“, which is just excellent in its thoughtfulness, thoroughness, writing, and interactive visuals.
They say, when talking about “textile machines” (analogous to my “factory machines”):
The logic of this argument is assuming that code is analogous to textiles. That is, code is the final product that users will pay for. But nobody wants to buy code. They want to buy applications. In other words, code is not the textile, but the textile-machine.
Yes! Code is deterministic and produces the same output for any given set of inputs. The code that the LLMs produce is the “machine”. The LLM is a tool that we are working with to create machines.
We are working with LLMs to create the looms and presses. We are building the machines, not operating them. We are not passing input to the compiler so that it can generate the output – we are building the compiler!
What does this mean for developers using LLMs?
1. With great power comes great responsibility
When you realise you are working at machine-building level, you should suddenly realise that you have a lot more responsibility.
You have responsibility for the efficiency of the machines.
You have responsibility for the safety of the machines.
You have responsibilities to the users of the machines.
You have responsibility for the correctness of the machine.
You have responsibility for the maintenance, life-span, and decommissioning of the machine.
None of this is new to building software. It’s true regardless of how you build it.
But when you can quickly and easily build any machine that you want, it’s easy to forget that you have these responsibilities.
Friction in the machine building process gives you time to think about the consequences of what you are making. And of what the thing you are making will make.
2. A machine-building machine is for building machines
Machines should not be single use.
It sounds bloody obvious doesn’t it? You don’t build a printing press to print one book, destroy the press, and the next time you want a copy of the same book you build a new printing press. That’s mad.
But I’ve seen exactly this happening with LLMs/agents and (if you’ve seen my social posts on the matter you will know that) it drives me CRAZY!
People literally typing if-then-else statements into LLMs. Telling them to ask the user something and remember the entered value under some name. Writing a shell script into an LLM prompt and telling the LLM to run it, look at the output, and branch to different logic based on what happens.
Sure, not everyone does this. Perhaps this is the exception.
But this is using huge resources to build a single-use, disposable machine. Printing presses and looms aren’t cheap. You should make only those that you need!
If you’re writing code – or pseudo code – in prompts to an LLM, then you can get the LLM to turn this into an actual script that you can run for free and (in my experience) orders of magnitude faster!
“But it’s easy to change the English instructions!” you say. Well… change the English instructions, and then tell the LLM to change the script/code that it made before to make it match the new instructions.
LLMs are, apparently, great at writing and modifying code. So have it write code! Don’t have it be an “English interpreter”. That’s incredibly inefficient.
You should do:
- English -> LLM -> Machine
- Input -> Machine -> Output
What’s great about this is you can do the “Input -> Machine -> Output” bit as many times as you like! You have a machine now! Go forth and process! (Tokens not required)
You should not do (in the VAST majority of cases):
- English + Input -> LLM -> (Temporary, single-use machine) -> Output
A framework for machine building
Understanding what LLMs are seems to be critical to effective use of them. It appears to me that some people think they are things that they are not. Perhaps this post helps someone see things differently?
I’m going back to finish the Decoherance article now. You should read it too.
Epilogue/Outtakes
Am I allowed to do outtakes in writing?
Here’s the thing. I started writing a final section called “A machine for building machines for machine building”
(Do you ever get that thing where you’ve used the same word so many times that it kinda stops being a word? I’m there now.)
I got to the following paragraph before it went completely off the rails. But perhaps this is amusing or contains the start of a thought that someone else can finish:
I still want to make machines (software, in case we’ve forgotten!). I think it’s important that humans (developers) make machines (software), because there is great responsibility in being a machine maker (software developer). But we software developers use software to make software.