Taste Is in the Spec (Cooking Is Not the Recipe) · Greg Herlein
Herlein
Home
Posts
About Me
Projects
Resume
Staffing
© 2018-2026. All rights reserved.
Built with Hugo<br>Theme Blackburn
Taste Is in the Spec (Cooking Is Not the Recipe)
28 Jun 2026, 00:00
ai /
spec-driven-development /
software-engineering /
taste /
craft /
agents
Here’s a question I can’t stop chewing on: why is some software so damn good, and most of it so… not? Not buggy. Not slow. Just bad. Bad in a way you feel in your gut the moment you touch it. The answer isn’t tooling, or budget, or headcount. It’s taste. And I’m starting to think taste is the whole ballgame in the age of AI.
The Thing We Don’t Talk About
We talk endlessly about correctness. Does it compile, do the tests pass, is it secure, does it scale. The ilities. All necessary. None of them sufficient.
Because there is software that ticks every one of those boxes and is still an absolute misery to use. And there is software - some of it written by three people in a basement and given away for free - that makes you go “oh, that’s how this is supposed to work.” You don’t fight it. It anticipates you. It has opinions, and the opinions are right.
That second kind isn’t an accident. It’s taste, made durable.
Think about Apple in its prime. Jobs wasn’t a great engineer. What he was, relentlessly, obsessively, was a person of taste who refused to ship anything that wasn’t right - and who built a company that could deliver “right” over and over for a long time. The famous stuff about the inside of the Mac case being beautiful even though no customer would ever see it? That’s not vanity. That’s a culture that internalized “we do not ship slop, anywhere, ever.” The software was loved because the organization had taste, and the products they made were the org made visible.
Conway Was Right, And It Goes Deeper
You know Conway’s Law: organizations ship their org chart. Systems mirror the communication structures of the teams that build them.
But it’s bigger than communication structure. Software mirrors the values of the organization that builds it. Its taste. Its discipline. Its respect - or disregard - for the person on the other end.
This is why some open source is still, decades on, the best software ever built for its job. git. ffmpeg. sqlite. curl. These weren’t built by faceless committees optimizing a quarterly EBITDA target. They were built by people who deeply understood the problem, cared about getting it right, and answered to no one but their own standards and their users. The taste of a small number of opinionated humans is fossilized in every command and every flag. That’s the magic. That’s encapsulated wisdom.
And it’s also why so much enterprise software is an abomination.
I won’t name names. (You know the ones. You have your own demons, I know you do.) These aren’t bad because the engineers were bad. They’re bad because they were built to be all things to all customers, by enormous organizations with no single coherent point of view, optimizing for the RFP checklist instead of the human at the keyboard and caring more about margins and growth than the user. There was no taste to encapsulate. So nothing got encapsulated. You feel that absence every single day you use the thing.
So What Is “Elegant Code,” Anyway?
Engineers chase “elegant code” like it’s a holy grail. And if you ask ten of them what elegant means, you’ll get ten answers, most of them vibes.
Here’s my answer, and I’ve had a long time to think about it: elegance is understanding made small. It’s what’s left after you’ve truly grokked the problem and thrown away everything that wasn’t the problem. Elegant code looks obvious in retrospect, which fools people into thinking it was easy. It was not easy. It was hard-won. The elegance is the wisdom - compressed until it fits in your head.
Elegance isn’t a property of the code. It’s a property of the understanding behind the code. You can’t fake it and you can’t bolt it on later.
And - this is the part I really want you to sit with - elegance of use matters every bit as much as elegance of code. Maybe more. A gorgeous internal architecture wrapped around a baffling, hostile user experience is not elegant. It’s just slop wearing a nice suit.
The Slop Is Coming. And It’s Not Just Code.
Here’s what keeps me up. We are about to flood the world with AI-assisted software. And the conversation about “AI slop” is fixated almost entirely on the code - is it correct, is it secure, did it hallucinate an API that doesn’t exist.
That’s the small problem.
The big problem is that the slop will be in how the software works. The...