Every conversation about AI-assisted software development eventually arrives at the same unnamed thing.

People call it taste, or style, or instinct. The sense that something is right or wrong before you can articulate why. Engineers circle the concept and retreat from it, because the tradition demands measurement. If you can’t test for it, it’s just opinion.

Robert Pirsig, a rhetoric instructor who followed this question until it nearly destroyed him, had a word for it. In Zen and the Art of Motorcycle Maintenance, he called it Quality: the pre-intellectual recognition that precedes analysis. You know the motorcycle doesn’t sound right before you know which valve is misfiring. You know the code is wrong before you can point to the bad abstraction. The recognition comes first. The articulation follows.

I think Quality is the variable that explains why some people produce genuinely good work with AI and others produce slop. Not skill, which can be learned. Not tooling, which everyone has access to. A way of paying attention that no prompt can encode.

In Blast Radius , I wrote about Fred Brooks’ distinction between essential and accidental complexity. AI is extraordinarily good at eliminating accidental complexity. Boilerplate evaporates. Scaffolding writes itself. Tests pass. Code compiles. But essential complexity remains: what to build, why, whether it serves anyone, how hundreds of individually reasonable decisions interact when they accumulate. That’s where Quality lives.

The line isn’t clean, though. AI does touch essential complexity. I use it to challenge my own designs, to surface alternatives I hadn’t considered, to pressure-test assumptions. In a bounded context, a single component or a well-scoped design decision, AI can produce something that feels genuinely right. Not just correct. Right.

The trouble is that the world isn’t a bounded context. Products are messy. Systems accumulate decisions the way organisms accumulate scar tissue. The interaction between a reasonable choice in January and a reasonable choice in June doesn’t surface in any individual pull request. Every PR is clean. The system drifts anyway.

Quality lives not in any individual decision, but in the integration — in whether it all adds up.

Pirsig argued that Quality isn’t a method. You can’t follow a checklist to it the way you can follow a checklist to correctness. It’s the ongoing act of paying attention, of caring about the work, of staying present with what you’re building long enough to feel when something has gone wrong. “Care and Quality,” he wrote, “are internal and external aspects of the same thing.” And caring can’t be outsourced, because caring requires stakes.

In practice, I’ve learned that the hardest moment is right before the building starts. The design is still forming, the architecture is still uncertain, and the AI is ready to go — it can generate a thousand lines before I’ve finished deciding whether the approach is right. The temptation to start building is enormous. But that’s where Quality is determined: in the slow, uncomfortable phase where intent gets shaped and you haven’t committed yet. Implementation can be fast; AI earns its keep there. Review has to be slow again. The discipline is knowing where speed serves you and where it robs you.

Pirsig described what he called gumption traps: specific psychological obstacles that destroy the capacity for Quality work. AI introduces new ones. The most insidious is what I’d call value rigidity at speed. You commit to an approach and the AI builds it out so fast that momentum makes it hard to reconsider, even when something feels off. The natural pause points that manual implementation used to provide, the friction that doubled as reflection time, are gone. You can be headed in the wrong direction faster than ever.

But AI also dissolves a gumption trap I didn’t expect. When I write every line of code myself, my identity gets woven into it. Someone reviews my work and they’re reviewing me. The defensive instinct is real. When AI produces the implementation, that entanglement loosens. I can evaluate the output with clearer eyes. The sunk cost drops, because if it’s wrong, I can discard it and regenerate without feeling like I’m throwing away hours of careful craft. Care gets preserved in the design and review, while attachment to any specific implementation fades. You can care deeply about what you’re building without being precious about how any particular piece was produced.

In traditional fencing, pupils practiced footwork for years before they ever touched a sword. The footwork wasn’t preparation for the real thing. It was the real thing. Everything that happens with the blade is an expression of what’s happening with the feet. When I was studying computer science, my university taught functional programming first, a language paradigm almost none of us had encountered, specifically to strip away the familiar and force us to think about computation itself.

This matters for how people develop Quality in an AI-assisted world. Engineers who have never written code by hand, who have never struggled with a bad abstraction and lived with the consequences, may lack the instinct to recognize when AI-generated code is subtly wrong. They haven’t done the footwork. You can’t review what you haven’t learned to feel. And when AI generates a ten-thousand-line pull request, the ability to feel what’s off in it, not just verify that the tests pass, is what separates review from rubber-stamping.

The footwork doesn’t mean avoiding the sword. I use AI constantly. When it generates code in a language I don’t know well, I read the code, not because I must but because the reading teaches me. When it makes architectural choices, I ask why. The interaction becomes a learning loop, but only if I stay engaged with it. The moment I stop reading, stop questioning, stop caring whether the output is good, I’m not working with the tool anymore. I’m being carried by it.

I’ve been writing about AI-assisted development for a while now. About how collapsing cycles strain coordination, about the absorption gap between what AI can do and what organizations actually deploy, about the blast radius that determines which systems resist substitution. I didn’t plan these as a series. But looking back, they all circle the same thing.

Production speed has outrun the ability to judge what’s been produced.

The thread I kept reaching for without naming is Quality: the human capacity to recognize whether something is good, to care whether it’s good, to stay with the work long enough to make it good.

My instinct is that this capacity is practically impossible to automate. Not because of something mystical about consciousness, but because Quality lives in the unbounded context, in the messy accumulation of everything, and AI operates in bounded contexts brilliantly while struggling to hold the whole. I can’t base this on more than a feeling. Pirsig would say the feeling is the most reliable data I have.

The risk isn’t that AI replaces Quality. It’s that speed makes us forget to look for it.