Code is Cheap(er)
45 points by facundoolano
45 points by facundoolano
The comparison with the sorcerer’s apprentice scene is really good!
Peter Naur’s Programming as Theory Building from 1985 probably deserves a few more re-reads these days.
“LLMs are incapable of fear of complexity” overstates the case.
The failure mode is real: left to broad instructions, LLMs will often add layers, invent abstractions, and produce more code than the problem deserves. But that behavior is easy to observe, easy to review for, and surprisingly easy to steer away from. Use your AGENTS/CLAUDE.md file to tune software to how you like it.
Ask for the smallest change. Ask what can be deleted. Ask whether an abstraction is earning its keep. Ask for invariants, coupling points, and cognitive load. Ask for a second pass that removes cleverness. The model will usually follow that pressure. Put that into your prompt and it will avoid it from the start.
So the danger is not that LLMs can never respect complexity. The danger is that they are happy to produce whatever shape of code the surrounding process rewards. A team that rewards volume will get volume. A team that rewards simplicity can often get that too.
The models are better than most humans these days, and they're only going to get better from here. Pressure your AI lab with feedback when your code isn't good. GPT stuff is terrible at writing good docs for instance (IMO at least).
Yeah, I'm not sure if I agree with that phrase too, but there is something there. On one hand side I've seen a "common complexity" defaulted to (building out big cmake project where a single target makefile is enough). On the other, I had to argue and reassure LLMs after answers like: "this is a month long project, I don't recommend doing this, how about we commit this and leave it as a demo" when we both know it's going to be done in an hour or less. But then you tell it "yeah, do the completely novel thing, just figure out how to" and it will try, so it that sense... there is no fear.
Hmm. Yes and no. I think the issue and question isn't really capability but training and goals. Currently the thing that is trendy is "I vibecoded the whole project". Also LLMs are incredibly bad at changing stuff compared to creating something from scratch which is likely based on how they are trained also I think there might simply be a statistical bias. As in there is more code in large complex code than the is in small simple projectse so that it will statistically outweigh it in training.
So while incapable is maybe not the best wording I'd argue that "per default" there are various biases towards complexity.
And there's also a general bias for doing stuff rather than not doing stuff. And a good programmer usually uses a lot more context than the manager asking for a specific thing. And give counter offers which I think is possible with LLMs but asking the right questions is not what current LLMs are good at with their "ask questions during planning" and loop detection code. It's likely also something where training data isn't as common.
In a way "prompt engineering" is horrible hacks around this set of issues.
understanding code has become more expensive
I am not sure I agree in general. Perhaps this is true for LLM-generated code with little thought but behind it, but with proper guidance LLMs can generate very readable and well-layered code. Of course, the human is taking most of the architectural choices there, which I think it's how it should be anyway.
Another counterpoint is that I've found LLMs excellent to understand human-written code I'm not familiar with. I can ask Claude Code to perform a deep dive into some code a produce a Markdown document where each part is explained, and even suggest an ordering for me to start reviewing/understanding the code.
That's extremely valuable.
My experience with LLMs in unfamiliar code is generally good, except where it takes creative liberties and lies where things deviate from the norm. The problem is the code is unfamiliar, so it’s hard to distinguish between these.