Software Quality and Gumption Traps
Software quality matters. Just not in the way most engineers think it does.
After 30 years in software—from startups to public SaaS companies—I’ve come to an uncomfortable conclusion: we’ve been optimizing for the wrong kind of quality. And the current panic about AI and LLM-assisted coding is exposing just how confused we are about what quality actually means.
As somebody with a degree in studio art who cares deeply about craftsmanship, I find these quality debates fascinating. Because most engineers haven’t actually studied quality. The single most influential writing on quality in the last 500 to 1,000 years is Zen and the Art of Motorcycle Maintenance by Robert Pirsig. And yes, it’s nominally about motorcycle maintenance, but it’s really about something much deeper.
Classical vs. Romantic Quality
Pirsig introduces two ways of understanding quality: classical and romantic. Classical quality is analytical, rational, concerned with the underlying form. It’s about clean architecture, elegant algorithms, test coverage, and technical correctness. This is what most software engineers mean when they talk about quality.
Romantic quality is about the immediate experience, the surface, what it feels like to use something. It’s experiential and intuitive.
Here’s the thing: most software engineering culture is obsessed with classical quality. We argue about design patterns, we insist on comprehensive test suites, we refactor for elegance. And we’ve convinced ourselves that this is what quality means.
But Pirsig’s real insight isn’t about choosing between classical and romantic quality. It’s about gumption traps.
Gumption Traps
A gumption trap is anything that prevents you from improving quality or even experiencing quality. It’s what stops you from caring about your work.
And here’s the crucial insight: quality is the external-facing side of a two-sided coin. The other side is care. You cannot have quality without someone who cares about the experience of making or using something.
When it comes to software quality in the age of AI, people over-index on classical quality—the “right” architecture, the “clean” code, the test coverage. They under-index on the type of quality that actually matters in production software: does it let the business do what it needs to do?
What Quality Actually Means for Software
The type of quality that matters in software is not absolute. It’s contextual.
You need software that doesn’t block the underlying business. That’s it. That’s the bar.
Does it stop the business from doing what it needs to do? Then it’s a quality problem.
Does it have bugs? Rough edges? An architecture that makes purists wince? If the business can still operate, those might not be quality problems at all. They might just be engineering aesthetics masquerading as pragmatism.
This relates to developer experience, yes, because developers have to build and maintain the software. But it doesn’t relate much to the classical quality metrics we’ve been taught to worship.
There’s nothing about AI that means you can’t care about software.
This is the real pushback to “vibe coding”—the assumption that using LLMs means you don’t care about what you’re building. Maybe some people who vibe code really don’t care. Maybe they’re just prompting and praying.
But that’s a personal discipline issue. It’s not inherent to the tools. You can care deeply about software and use LLMs. You can be mindful and intentional with AI-assisted coding. The tool doesn’t determine the care.
LLMs Remove More Gumption Traps Than They Create
Here’s what I think gets lost in the AI coding debate: LLMs are possibly the most powerful gumption trap removing device that software engineers have ever had.
Look at Ruby on Rails. It succeeded despite being slow, despite not being particularly elegant from a computer science perspective, despite violating all sorts of academic principles about what “good” software should be.
Rails succeeded because it removed gumption traps. Convention over configuration. Make the common case easy. Get out of the developer’s way.
There were so many gumption traps in the early 2000s around configuring XML files, wiring up dependencies, writing boilerplate. Rails said: we’ll make reasonable choices so you can focus on building.
LLMs work the same way, in the right hands.
There are still an incredible number of gumption traps between “I have an idea for how software can make my life better” and having that software actually exist and work.
The criticism of AI-generated code as “slop” misses the point entirely. That’s classical quality thinking. Clean code. Elegant patterns. Test coverage.
But if the software does what it needs to do? If it doesn’t block the business? If someone cares enough to maintain it?
Then maybe what we’re calling slop is actually just software that prioritized romantic quality—the experience of building and using—over classical quality—the aesthetics of the underlying form.
The quality debate about AI isn’t really about the code it writes. It’s about whether we’re finally being honest about what we were optimizing for all along: not perfection, but possibility.