Software Taste vs. Slop in the Age of AI – TWSoftwareDev26

In the age of AI, software quality hinges on taste, not tooling or budget, argues a developer. Taste, defined as understanding made small, separates elegant, user-respecting software from slop produced by organizations lacking coherent values. The piece contends that software mirrors its creators' values, with open-source tools like git and sqlite exemplifying taste, while enterprise software often fails due to committee-driven, checklist-optimized development.

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 flow. The defaults. The thousand tiny decisions about what to make easy and what to make possible. An agent has no opinion about whether this should be one screen or three. It has no taste. It will cheerfully generate a technically-correct, fully-tested, beautifully-documented experience that is miserable to use - and it will do it ten thousand times faster than the faceless enterprise vendors who trained us to accept misery in the first place. So we will get ten thousand times more of it. Because that’s the other thing. We’ve been trained . Decades of “good enough” enterprise software with brutal switching costs taught us to accept bad as normal. To shrug. To file a ticket and move on. We stopped expecting software to be good. AI is going to take that learned helplessness and pour gasoline on it. Unless. What If We Caught It Before It Got Built? This is where spec-driven development can truly shine, and where I get genuinely excited - and then genuinely worried. The promise is beautiful: if the agent is going to build whatever we specify, then the spec is where taste lives now . The spec is the leverage point. Get the spec right - capture the why, the elegance, the exact sweet spot of how the thing should feel to use - and you can intercept the slop before a single line gets written . That’s an opportunity we’ve never had before. We get to encode the wisdom up front. But “get the spec right” is doing an enormous amount of work in that sentence. I’ve been deep in the new spec-driven literature. There’s a book - Agentic Spec-Driven Development: A Practical Method for Using AI to Build Complete Specifications https://www.amazon.com/dp/B0GX38ZZYT - and honestly, if your teams haven’t read it, they should. The rigor is real. It sits somewhere between a building code for skyscrapers and actual source code - it’s full of the stuff that should be in our specs and usually isn’t. I respect it a lot. And I was bored out of my mind reading it. I felt like the stereotypical accountant. The joy of building - the thing that made me fall in love with this work in the first place - got reduced to a recipe. Steps. Checklists. Sections you must fill in. Now don’t get me wrong. The mechanics of the recipe matter . They matter a lot. There’s beautiful infrastructure being built right now to standardize this. Google’s Open Knowledge Format https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing is a serious attempt to standardize how we write the material part of the recipe - the facts, the constraints, the shared knowledge. And tools like Tolaria https://github.com/refactoringhq/tolaria are trying to make it easy to write and maintain that knowledge, which is exactly the kind of unglamorous-but-critical plumbing this whole movement needs. If skills are the how-to , the knowledge format is the what’s-true . We need both. But a perfect recipe followed by someone with no taste still produces mediocre food. Your Move, Chief Then I read Jay Acunzo’s post, “Your Move, Chief” https://jayacunzo.com/blog/your-move-chief , and it floored me. It’s the antidote I was groping for. If you know the scene, you know. Good Will Hunting. Robin Williams as Sean, on the park bench, telling the cocky genius kid: you can quote every art critic on Michelangelo, but you can’t tell me what it smells like in the Sistine Chapel. You’ve never stood there . You can read everything about love and war and loss, but you’ve never lived it. Knowing about a thing is not the same as having lived it. Your move, chief. That is exactly the gap between the recipe and the meal. Between the spec and the good software. The model has read everything. It knows about everything. But it has never lived. It has never shipped a feature that hurt a real user and had to look them in the eye. It has never felt the specific revulsion of a workflow that’s technically fine and spiritually broken. It has no scar tissue. It has no taste, because taste is lived , not known . The human part - the wisdom, the experience, the taste - is what’s going to decide whether the software is good or just correct . And that part can’t be downloaded. It has to be earned. So Where Do We Point the Juniors? Where Do We Point Ourselves? This is the part that’s genuinely making me rethink how we develop people. Junior engineers used to earn taste the slow way. Years of writing code, getting it torn apart in review, maintaining someone else’s disaster at 2am, feeling the consequences. The path was the apprenticeship. That path is gone. Not “changing.” Gone. The grunt-work roles where people used to accumulate scar tissue don’t exist anymore - the agent does that work now. We can’t send the next generation down the road we walked, because the road’s been paved over with a new train station. But here’s the hopeful part, and I really believe this: they can build more now, not less. With agents, a junior can attempt things that used to take a senior team. They can ship, observe, feel the consequences, and iterate - faster than we ever could . They can develop taste, wisdom, and judgment - but on a completely different track than ours. They don’t have to suffer the way we suffered to get there. In fact they can’t, and thank God. So where do we point them? Toward judgment , not syntax. Toward why this is good and that is slop . Toward standing in the Sistine Chapel instead of reading about it - shipping real things to real people and developing a nose for the difference between fine and right . And where do we point us ? Same direction, honestly. Our job is shifting from writing the thing to knowing what good looks like and being able to say why - clearly enough that it survives translation into a spec an agent can execute. That is a whole new level of understanding and synthesis. It’s harder than coding ever was. It’s also more human. What This Means For Specs So I’m not anti-spec. Far from it. I think rigorous, well-structured specs are about to be the single most important artifact in software. Read the book. Adopt the format. Use the tools. The mechanics matter and I’m not waving them away. But the spec is a vessel . The recipe is not the cooking. If we pour mediocre understanding into a perfectly-formatted spec, we get perfectly-formatted slop, faster and at scale. The format is necessary. It is nowhere near sufficient. The real work - the part no tool will do for you - is the human work of digging in . Of actually understanding the problem and the person you’re solving it for, deeply enough to have an opinion about what right feels like. Of capturing not just the requirements but the taste . The why. The elegance. The exact sweet spot of how it should work. That’s the wisdom we have to learn to write down. Most of us have never had to articulate it before - we just had it, and it leaked into the code. Now we have to make it explicit, on purpose, in a form an agent can build from. That’s the new craft. Conclusion Good software has always reflected the taste of the people who made it. Apple proved it on the upside. AI changes the leverage of taste, not the need for it. It makes the tasteful more powerful and the tasteless more dangerous, both at scale. The slop is coming, and the worst of it won’t be just in the code - it’ll be in how the software feels . The only thing standing between us and an ocean of technically-correct misery is human wisdom, captured early, encoded in the spec, defended on purpose. The models have read everything. They’ve lived nothing. The taste is still ours to bring. Your move, chief. What do you think? Are you finding ways to capture taste in your specs - or watching it get flattened into a checklist? I’d genuinely love to hear how teams are handling this. Drop me a note. On that note: I’m on my way to the second Future of Software Development Retreat, in Switzerland, hosted by Thoughtworks https://www.thoughtworks.com/ . It’ll be a chance to step away, learn from some of the smartest people in software, and spend a few days digging into exactly this - where software development is actually heading. Taste, specs, agents, and all. If you’re going to be there, find me. I’d love to discuss this in person. TWSoftwareDev26