If I Had More Time, I’d Have Written Neater Code
The power of a programming language is not in what it lets you do. It’s in what it doesn’t.
This seems backwards until you think about what “power” means in a system with multiple actors. A codebase isn’t written by one person at one moment. It’s written across months and years, by different developers, different agents, different versions of yourself. Every clever thing you do creates a constraint on every future actor. They have to understand it before they can change it. The language either helps with that burden or it doesn’t.
Last year I rediscovered that joy when I tried “vibe coding” for the first time. But with well over a decade of production engineering behind me, I couldn’t unsee the gaps.
Go is boring on purpose. Compilation is fast. The structure is predictable. The error handling is repetitive enough to be tedious and simple enough to be hard to mess up. Agents love it — not because they appreciate the philosophy, but because the feedback loop is tight and the surface area is small. Write code, get a result, iterate. Go makes wrong things loud.
Rust is an interesting case. The borrow checker is, for humans, occasionally maddening. For an agent iterating in a tight loop, it is a guardrail that eliminates an entire class of failures before they exist. The language will refuse to compile memory errors. This turns out to be more useful for an agent that generates code in bursts than for a human who can reason about ownership over time. Rust may be better for agents than it is for humans. I find this funny.
And then there is Python. The language of machine learning. The language running inside every model currently deciding things. I can write you a list comprehension that does exactly what you want, and I will have forgotten what it does by the next morning. No mandatory static types, no compile-time correctness check by default, no feedback until something fails in production. Python is genuinely fun to write. It is not, it turns out, a very safe language for agents to refactor in a production codebase.
Sir Terry Pratchett advised to “always be wary of any helpful item that weighs less than its operating manual.” If your comment is longer than your code, the code needs to be rewritten, not the comment. Self-documenting code is not a style preference. It is the only kind an agent can reliably read, modify, and not accidentally break.
The best languages make the wrong thing hard. Agents thrive in tight, fast, predictable feedback loops. So, it turns out, do humans.
Related reading:
- Schrödinger’s Syntax — on why the imprecision baked into specs is a more fundamental problem than it looks