Solving problems with LLMs is like solving front-end problems with NPM: the βsolutionβ comes through installing more and more things β adding more and more context, i.e. more and
more packages.
LLM: Problem? Add more context.
NPM: Problem? Thereβs a package for that.
...
As Iβm typing this, Iβm thinking of that image of the evolution of the Raptor engine, where it evolved in simplicity:
Alt
Photograph of three versions of the raptor engine, each one getting progressively simplified in mechanical parts.
This stands in contrast to my working with LLMs, which often wants more and more context from me to get to a generative solution:
Alt
Photograph of three versions of the raptor engine, but the image is reversed showing the engine get progressively complicated in mechanical parts over time. Each engine
represents an LLM prompt.
...
Jim Nielsen speaks to my experience, here. Because a programming LLM is simply taking inputs (all of your code, plus your prompt), transforming it through statistical analysis, and then
producing an output (replacement code), it struggles with refactoring for simplicity unless very-carefully controlled. "Vibe coding" is very much an exercise in adding hacks upon
hacks... like the increasingly-ludicrous epicycles introduced by proponents of geocentrism in its final centuries before the heliocentric model became fully accepted.
Alt
Geocentric representation of the apparent motion of the Sun, Mercury, and Venus from the Earth, based on 15th century diagrams. It consists of many looping spirals approaching and
then withdrawing from the Earth as they orbit around it.
This mess used to be how many perfectly smart people imagined the movements of the planets. When observations proved it couldn't be right, they'd just add more
complexity to catch the edge cases.
I don't think that AIs are useless as a coding tool, and I've successfully used them to good effect on
several occasions. I've even tried "vibe coding", about which I fully agree with Steve Krouse's observation that
"vibe code is legacy code". Being able to knock out something temporary, throwaway, experimental, or for personal use only... while I work
on something else... is pretty liberating.
For example: I couldn't remember my Google Sheets API and didn't want to re-learn it from the sprawling documentation site, but wanted a quick personal tool to manipulate such a sheet
from a remote system. I was able to have an AI knock up what I needed while I cooked dinner for the kids, paying only enough attention to check-in on its work. Is it accessible? Is it
secure? Is it performant? Is it maintainable? I can't answer any of those questions, and so as a professional software engineer I have to reasonably assume the answer to
all of them is "no". But its only user is me, it does what I needed it to do, and I didn't have to shift my focus from supervising children and a pan in order to throw it together!
Anyway: Jim hits the nail on the head here, as he so often does.
Iβve been musing on complexity-simplicity recently too, βpromptedβ by using LLMs daily to code. It feels like the LLMs, trained on excess complexity, are regurgitating it back up,
which makes it starkly clear that our job is to simplify, reduce, carve off redundant cruft. And just maybe this LLM revolution will nudge us toward simpler systems (as a
reaction) π€
Iβve been musing on complexity-simplicity recently too, βpromptedβ by using LLMs daily to code. It feels like the LLMs, trained on excess complexity, are regurgitating it back up, which makes it starkly clear that our job is to simplify, reduce, carve off redundant cruft. And just maybe this LLM revolution will nudge us toward simpler systems (as a reaction) π€