# Quality in the Age of Slop

> Source: <https://sinclairtarget.com/blog/2026/06/01/quality-in-the-age-of-slop/>
> Published: 2026-06-02 09:11:39+00:00

# Quality in the Age of Slop

#### Jun 01, 2026

This blog post is very long and almost entirely about the 1974 bestseller
*Zen and the Art of Motorcycle Maintenance* by Robert M. Pirsig. It is also
about AI—there will be some juicy takes, pinky swear—but those familiar with
*ZAMM* should consider themselves warned.

Those unfamiliar with *ZAMM* are owed some context. Many see *ZAMM* as a
pretentious book, the kind of book your freshman-year roommate (the one who
wrote haikus at 2am by moonlight) would have gushed about. It has a middling
3.78 rating on GoodReads, but it's the reviews that capture how the people who
don't like *ZAMM* feel about *ZAMM*. Here's user "Zora," who rated the book one
out of five stars:

I learned from this book that you can sell a billion copies of a book that no one should ever waste three minutes reading. This is just another neo-philosophy book disguised as a novel. I'm almost convinced that the only reason people buy this book is so that their pseudo-intellectual (read: pompous scumbag) friends will accept them into their hippie circle. Although I know about twenty people who claim to have read this book, I have yet to meet a single person who actually knows what it's about. This book is a bigger hoax than the bible.

—Zora

And here's user "Lala BooksandLala," who also gave a one-star rating but expressed herself more succinctly:

absolutely not

—Lala BooksandLala

So I will admit that a blog post about *ZAMM* and AI might not sound like a
good time; if there's anything more pretentious than *ZAMM* itself then surely
it is a blog post about *ZAMM*. But I hope that by starting with this frank
content warning I've won myself some of your trust, maybe even enough that
you'll be game to buckle in for the winding theme-park boat ride through *ZAMM*
that I'm eager to take you on. Because, pretentious as *ZAMM* may be, I really
can't stop thinking about it now that we have to contend with the Maw.

What is the Maw? The Maw is the gaping pit of nihilism that has opened up in
the middle of the tech industry. The Maw is the explicit or implicit subject of
roughly 63% of blog posts now shared on link aggregators like Hacker News, the
subject that nobody can resist writing about, even authors who typically write
about SAT solvers or microservices. The Maw is the looming threat that has
prompted such an outpouring of *cris de couer* in the blogosphere, which
some might view as—though I hope events don't go this way—just the death
braying of a highly literate professional class.

Lately, we had ["Do I Belong in Tech Anymore?"](https://ky.fyi/posts/ai-burnout),
which resonated with many emotionally. Of course, there was also the epic
10-parter, ["The Future of Everything is Lies, I Guess."](https://aphyr.com/posts/411-the-future-of-everything-is-lies-i-guess) My personal favorite is ["I Think I'm Done Thinking About Gen AI for
Now,"](https://blog.glyph.im/2025/06/i-think-im-done-thinking-about-genai-for-now.html) which is notable for complaining primarily about the
*aesthetics* of AI and perhaps also for [how quickly its author was not, in
fact, done thinking about Gen AI](https://blog.glyph.im/2026/01/how-to-argue-with-me-about-ai.html). We, the
software engineers, are clearly working through something.

Software engineers aren't known for shying away from new technology, so it feels like you need an extraordinarily good reason to opt out of using the latest agentic coding tools. And yet I think many of us are so disturbed by the implications of letting linear algebra write software that we are looking to articulate that reason, looking to cobble together a defense of the values that heretofore we took for granted but now are under attack.

This attack isn't just the one implied by how capable AI coding tools have
become. This attack sometimes comes from actual people. On Hacker News and
similar sites, it's common to see something like the following: Commenter A,
expressing sympathy with an anti-AI blog post, recounts how the last time he or
she used Claude Code it came up with a name for a function that was subtly
misleading. Commenter B, Maw acolyte, then swoops in, asking why commenter A
even cares about how functions are named, given that Claude can just read the
whole function body to understand what the function does anyway, *without
breaking a sweat*, and furthermore doesn't commenter A realize that soon enough
no humans will be reading the code at all?

Commenter B appears to be suggesting that software engineering is over. Not just that many individual software engineers will be out of a job, but that the entire discipline of software engineering—the accumulated wisdom about best practices, about effective architecture, about how to make software maintainable and performant—is defunct. That the difference between an accurate name and an inaccurate one doesn't matter if the AI can still spit out working software.

This is what scares me most about the Maw. It seems to want to swallow forever the distinction between good and bad, leaving a world in which there is only code that works and code that doesn't, and no code that is beautiful, or excellent, or virtuous, or funny.

Every time I've encountered a comment written by commenter B, I've fallen into
a bout of despair. I feel despair because I've always found the pursuit of
excellence in my chosen profession motivating, but on my darker days I worry
about whether excellence matters anymore. It seems improbable to me that AI
will really make software engineers obsolete, though I can't know the future;
what seems more probable is that the software industry will value technical
craft less than it did before. If I want to keep my faith in excellence, I'll
have to shore it up for myself. And so I have big, urgent questions: Is there
still such a thing as a good programmer? As good code? If there is, why does
"good" matter? What would it look like to be a good programmer who uses AI
tools? What do *I* consider good, in the face of the Maw?

I can't stop thinking about *ZAMM* because I've discovered that this novel from
1974 ostensibly about motorcycles has helped me with these questions. In
between some plodding bits about Aristotle and what Montana looks like from the
highway, in *ZAMM* I've found a convincing—even moving—vindication of the
craftsman ethos latent in so many of the blog posts critical of AI. I suppose
this is my attempt to grab everyone by the collar and yell, "Don't you see?
This is all straight out of *ZAMM*!", hoping that *ZAMM*'s elevation of craft
gives others the same comfort and guidance that it has given me.

In case you don't care for motorcycles, let me first persuade you that *ZAMM*
is actually a book about programming. At least, it's as much a book about
programming as it is a book about motorcycles.

*ZAMM* might as well be called *Zen and the Art of Software Maintenance*
because maintaining motorcycles and maintaining software are, by *ZAMM*'s own
yardstick, fundamentally the same activity. This seems surprising because we
think of motorcycle maintenance as something that requires getting your hands
greasy and of programming as something that does not. Yet to get hung up on
that difference would be to misunderstand where the real action of motorcycle
maintenance is:

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greater part of his work is careful observation and precise thinking. That is why mechanics sometimes seem so taciturn and withdrawn when performing tests. They don't like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all.

—

ZAMM, Chapter 9

In order to fix a faulty motorcycle, a mechanic needs to debug the fault, and
that debugging process is the same whether the fault is an engine that won't
start or a web service that keeps getting deadlocked. It's been a meme since at
least 2010's *The Social Network* that you don't interrupt a programmer who's
"wired in"; apparently the same thing has always been true for motorcycle
mechanics. Both the programmer and the mechanic have to steady wobbly towers
of abstractions in their heads to make any progress.

There is one bit in *ZAMM* about how keeping a stool on either side of your
bike will save your back in the long run, and another bit about how to be
delicate with precision parts, but these are the only pieces of direct advice
in the entire book about how to *physically* maintain a motorcycle. Everything
else *ZAMM* has to say about motorcycle maintenance involves the state of mind
of the mechanic, and so is equally applicable to programming.

Many of these things *ZAMM* has to say operate in the airy realm of philosophy,
and we'll get to that in a minute, but if all you wanted from *ZAMM* was
practical tips for working on your next software project it has more of those
than you'd think.

Take the chapter devoted to "gumption traps." "Gumption" is the reserve of willpower you have available for the intellectual exertion of maintenance, the "psychic gasoline that keeps the whole thing going." A "gumption trap" is an event occurring during maintenance that drains a large fraction of your gumption at once.

Gumption traps come in many varieties, but all will be familiar to working software engineers. There's the "intermittent failure setback", which is when "the thing that is wrong becomes right all of a sudden just as you start to fix it." In software engineering, this is known as a could-not-reproduce, or in bad cases as a Heisenbug; these drain your gumption when you let yourself be fooled into thinking that actually everything is working, only for the problem to crop up again. There's also the "impatience trap," which can happen when you underestimate how long a task will require and, as you fall behind your expected schedule, grow more and more tempted to take shortcuts. Unless you stop and accept the minor gumption hit of admitting that your estimate was wrong, you're vulnerable to experiencing a catastrophic loss of gumption when one of your shortcuts leads to a big mistake that delays you even further.

The advice in *ZAMM* is so relevant to programming that I wondered whether
Pirsig, *ZAMM*'s author, had ever done any programming himself. The answer is
yes. He was a big computer guy. At the Smithsonian, there is [an exhibit
displaying Pirsig's 1966 Honda Super Hawk motorcycle next to his Apple
II](https://www.smithsonianmag.com/smithsonian-institution/zen-motorcycle-still-inspires-philosophical-road-trippers-50-years-later-180984143/). His Apple II is tricked out with seven expansion cards,
which, according to people who know more about the Apple II than I do, is a lot
of expansion cards. He couldn't have bought his Apple II until well after
*ZAMM* was published (the Apple II was released in 1977), but he was a computer
guy even before that, since he worked as a technical writer for Honeywell.
There are several analogies in *ZAMM* involving circuits and digital computer
manuals.

It would have been a worse novel, but had Pirsig written *ZAMM* ten or twenty
years later it could easily have been about computers and surfing the net
instead of motorcycles and roadtripping the West. Many passages would carry
over almost verbatim.

Okay, thus far, I might have given you the impression that even if *ZAMM* isn't
really about motorcycles it's still mostly about maintaining things. Actually,
*ZAMM* is only about maintaining things as a gateway to *ZAMM*'s big main idea,
"Quality." (Yes, with a capital "Q.")

Quality and how it relates to AI programming tools is what I want to get to,
but first I need to explain what Pirsig means by "Quality." This part might
drag a little, which is why I wanted to sell you beforehand on how *ZAMM* is
full of highly germane and useful advice about programming. Computers! We're
here to talk about computers. But also an amateur philosopher's ideas about
rhetoric and aesthetics. Please don't unbuckle and make a break for the nearest
exit.

*ZAMM* is structured like an intellectual mystery novel. The inciting incident
occurs in the first chapter, when Pirsig notices that he and his riding
companion, John, have very different attitudes toward their motorcycles. John
has purchased the most reliable motorcycle money can buy, a German-made BMW,
hoping he can avoid what he sees as the ugly, fussy business of maintaining the
motorcycle himself. He'd prefer not have to think about how it works at all.
This astounds Pirsig; John's attitude seems impractical and besides there's so
much beauty to appreciate in the inner workings of a motorcycle. Pirsig's
attempt to account for this discrepancy between John and himself mushrooms into
the giant system of thought that takes up the rest of the book.

The mystery in *ZAMM*, rather than "whodunit," is whether there is an idea that
can tie John's view of the world and Pirsig's view together. Pirsig believes
John's attitude represents the way many people in the 60s and 70s feel about
technology—that technology is hostile, controlling, and *square*. He
sympathizes with this view but also knows that technology doesn't have to be
this way and wonders what went wrong. Pirsig decides that John's view
represents the "romantic" understanding of the world, one concerned with
emotion and the immediate impressions of things, while his view represents the
"classical" understanding of the world, one concerned with underlying form and
logical abstractions. What went wrong is that these two understandings at some
point diverged, and also that technology and society have become so
oppressively dominated by the classical understanding that people need to
take long motorcycle roadtrips to get away from it. Pirsig thinks we need both
modes of understanding to build technology that serves human flourishing, but
he's missing a "fulcrum idea" that could reconcile them.

Pirsig recalls how earlier in his life, while employed as a college instructor teaching rhetoric, he questioned what he was even supposed to be teaching his students. His job was to teach them good writing, which he did by pointing out the various little devices—metaphor, parallelism, anaphora—that good writers employ. Yet an essay could have all of these and be bad, or none of them and be good. And his students seemed to know good writing from bad writing already, even if they couldn't write well themselves or name all the rhetorical devices. Teaching rhetoric seemed to call for the romantic mode of understanding to be admitted to the classroom, but how could that fly in a university, a bastion of the classical mode, where you aren't supposed to teach students that "good" is whatever they like? And is that even what he wanted to teach them? That didn't sound right either.

Pirsig realizes that what he was trying to teach his students is Quality. This is the idea that unites the romantic and the classical. He says that Quality is something we can all recognize but nobody can formally define.

Over the following several chapters, Pirsig explains what he means with some
metaphysics. (This is likely where many readers sour on *ZAMM*; it's the
least convincing part of the book.) Under Pirsig's metaphysical regime, whether
something—a piece of writing, a motorcycle, an experience—is "high-Quality" or
"low-Quality" isn't objective, because it isn't measurable, but nor is it
subjective, because Quality creates subjects and not the other way around.
Quality is a kind of sieve on reality that is applied before we can even
understand there to be subjects and objects at all.

This is hard to wrap your head around. I'm not sure I understand it. I refer
you to *ZAMM* if you want a better explanation, since I probably haven't done
it justice.

In any case, I think the actually brilliant thing that Pirsig has done
is land on the name "Quality." Pirsig is trying to answer that age-old
question in ethics, "What is Good?", which is basically also that age-old
question in aesthetics, "What is Beautiful?"—questions that are thorny in the
extreme because for them to be meaningful surely the answer has to apply to
everyone, yet nobody seems to have been able to *prove* that
their notion of Good really is the Good universally. Pirsig's answer is,
"What if we call it 'Quality' instead?" The name "Quality" is a smudge; it
conflates "quality" as in "high-value" with "quality" as in "characteristic" or
"feature." This is brilliant because since Plato's *Republic* everyone has been
trying to argue logically for their version of the Good, but "Quality" suggests
that the Good is immediately perceived, that it's immanent in our experiences
of the world and comes *before* logic and reason.

Here I start to find Pirsig more convincing. He goes on to point out that science and math, while consistent and logical within their domain, have Quality judgments in their underpinnings and all around their periphery. In geometry, once you have your axioms, everything can be derived with unassailable certainty, but if you choose different axioms you end up with different geometries, and whether one set of axioms is more "right" than another is mostly a matter of taste and fitness for purpose—call it "Quality." In science, once you have a hypothesis, the scientific method tells you what to do, but choosing a hypothesis from the ocean of possible hypotheses is an art without any prescribed method.

Pirsig quotes Henri Poincairé, who says that the mathematician or scientist at the cutting edge of knowledge must choose among the many possibilities one can derive from existing laws, and that "the rules that must guide the choice are extremely fine and delicate. It's almost impossible to state them precisely; they must be felt rather than formulated." This sounds a lot like the situation in Pirsig's rhetoric class.

We've already dawdled here for far too long, but I can't resist giving you
another example, one that doesn't appear in *ZAMM* but which I think epitomizes
Pirsig's argument. Consider Occam's Razor. This is the principle in science
that if you can explain something with a simpler theory you should. It is the
only thing stopping you from concocting a more complicated but still
empirically valid law of gravity that says gravity exists because all matter
fondly misses being smushed together before the big bang. As long as your
theory can be used to predict things accurately, why not use it? Occam's Razor
says that you shouldn't use it because the missing-being-smushed part is
extraneous, but that's an *aesthetic* judgment, a Quality judgment, through and
through!

What Pirsig is really trying to show is that the romantic mode of understanding and the classical mode of understanding, far from being opposed to one another, are in the best of science and technology intertwined. As he writes, "the dictum that Science and its offspring, technology, are 'value free,' that is, 'quality free,' has got to go." We might think of our surface impressions of things as somehow inferior to "true" knowledge because they don't involve rigorous logic, but Pirsig wants to remind us, as he puts it, that our impressions of Quality are "the leading edge of the train of knowledge" and without them "the entire train has no way of knowing where to go."

Much of the criticism of AI from software engineers has focused on whether
agentic programming tools can do what the big AI companies claim they can do.
There have been blog posts about AI tools where the punchline is that the AI
fouled up the codebase or hallucinated a function in a library that doesn't
exist. While I agree that currently AI tools often make mistakes, I suspect
that this debate about effectiveness is beside the point and many of the
engineers criticizing AI would prefer not to use agentic tools *even if they
worked as advertised.*

I have struggled with this. I have felt a deep disquiet about AI tools that I worry I can't justify, because I know it'd still be there even if Claude Code worked flawlessly. This has bothered me so much that we're now thousands of words deep into my attempt to work it out.

I want to go back to the blog post I mentioned above, ["I Think I'm Done
Thinking about Gen AI for Now,"](https://blog.glyph.im/2025/06/i-think-im-done-thinking-about-genai-for-now.html) which I love for being brave
enough to get into all this. Responding to other software engineers writing
enthusiastically about AI, the author says this:

I cannot

effectivelyrespond to these folks, because they are making apracticalargument that I cannot, despite my best efforts, find compelling evidence to refute categorically.Myexperiences of genAI are all extremely bad, but that is barely even anecdata.Theirexperiences are neutral-to-positive. Little scientific data exists. How to resolve this?

Later, the author explains why his experiences with AI have been negative:

My factual analysis of genAI is hopelessly negatively biased. I find the vast majority of the aesthetic properties of genAI to be

intenselyunpleasant.

And finally he concludes:

Would I

liketo use this magic robot that could mostly just emit working code for me? Would I use it if it werefree, in all senses of the word?No. I absolutely would not.

There's something poignant about how strongly he feels repulsed by AI and yet
how tied up in knots he is about not being able to prove his case with data in
some disinterested, unbiased way. I can certainly relate. If I squint, I can
see how [someone might be able to use coding agents in a way I can
admire](https://mitchellh.com/writing/my-ai-adoption-journey), but of the more typical case where people seem to be
delegating authorship to the machine I can only say that it seems low-Quality.
That it can't possibly lead to good code because there's no human excellence in
it. But that seems so subjective! Can I really make a case for "human
excellence" if one day it stands in the way of what could be quantifiable
gains in productivity?

*ZAMM* has helped me here in two ways.

First, *ZAMM* has helped me understand that I've been stuck in the classical
mode of thinking. In the last third of the book, which is much better than the
middle, Pirsig says that he wants to forget about all the metaphysics and
investigate what Quality means for daily life. He says the most important thing
that Quality can do is expand reason to include things that were previously
inadmissible. This is important because it's "the overwhelming presence of
these irrational elements crying for assimilation that creates the present bad
quality, the chaotic, disconnected spirit" of our modern age. The classical
mode so dominates our thinking today that somehow I've decided my visceral,
pre-intellectual distaste for AI is something I should discount rather than
heed.

Pirsig might say that my opinion on AI is neither subjective nor objective
because it derives from a perception of Quality. I'm not sure I can make heads
or tails of that. I would instead say that my opinion *is* subjective—is
hopelessly biased—but what *ZAMM* has helped me appreciate is that everybody
else's opinion is too, even when it might not appear that way. Someone could
come to me with lots of studies that show programmers on average produce 50%
more lines of code per day using coding agents. This person has data! But I
would be entirely justified in asking, "Why do we care about these additional
lines of code? Is there some important end that makes producing this code worth
diminishing our capacity for excellence, or will we just be shoveling a glut of
ill-conceived features into software products that already fail to delight the
soul? What Quality judgment have *you* made that says writing 50% more code
this way serves human flourishing?"

Second, *ZAMM* has helped me better understand my reservations about AI. Pirsig
says that the problem with modern technology is that it has become dominated by
a classical "subject-object" way of looking at things. He talks about how, in
manuals for consumer products, every line conveys the idea that the grill/lawn
mower/dish washer/computer has no relationship to you, and you have no
relationship to it, other than to operate it. What counts as good grilling, or
lawn mowing, or computing etc. is always taken for granted, even though that's
the most important part. We have a society in which technology is created by
people who are disinterested in it to be sold to people who are also assumed to
be disinterested in it.

Pirsig believes that to fix this problem technologists need to identify with the work that they are doing rather than allow any estrangement to come between themselves and the machine:

The mechanic I'm talking about doesn't make this separation. One says of him that he is "interested" in what he's doing, that he's "involved" in his work. What produces this involvement is, at the cutting edge of consciousness, an absence of any sense of separateness of subject and object.... When one isn't dominated by feelings of separateness from what he's working on, then one can be said to "care" about what he's doing. That is what caring really is, a feeling of identification with what one's doing. When one has this feeling then he also sees the inverse side of caring, Quality itself.

—

ZAMM, Chapter 25

Quality is related to caring because once you care, once you are interested, you have a vantage point from which to make Quality judgments. These Quality judgments (e.g. "Is this good code?") are based in part on the romantic mode of understanding and so within the classical mode alone aren't defensible. But they are necessary, because in the moment-to-moment work on the machine, there are thousands of facts you could consider, thousands of alternative threads you could follow, all equally valid in the classical mode, and the only way to make any sense of it all is to apply a Quality-focused version of Occam's Razor:

To put it in more concrete terms: If you want to build a factory, or fix a motorcycle, or set a nation right without getting stuck, then classical, structured, dualistic subject-object knowledge, although necessary, isn't enough. You have to have some feeling for the quality of the work. You have to have a sense for what's good.

Thatis what carries you forward.—

ZAMM, Chapter 24

I can't see how I could offload programming to a coding agent without losing this sense for "the quality of the work." I have found LLMs extremely useful as a search tool and as a kind of super-charged rubber ducking partner. But to use an LLM to write code—when LLMs include randomness as an essential part of how they work—when the whole selling point of these tools is that they can produce more code than I can keep up with—would only be putting a layer of friction between myself and what I'm building. It would make it harder to lose myself in the work. It would make it harder to care.

I am in my mid-thirties. Many noble things have happened in my lifetime—we've cured diseases, made people in the poorest nations wealthier, and even started going back to the moon. But I can't help feeling that in those same 30 years there has been a hallowing out of shared purpose that has left the world more cynical than before.

My wife and I are expecting our first child later this year. A daughter! I'm beyond excited. But I also fear for what the world will be like another thirty years from now, when she's my age.

I hope my daughter can live in a world where people identify with the work they
do and care to be excellent at it. Writing rambling blog posts like this one
probably won't help achieve that. But what I *can* do, perhaps the most
important thing I can do, is strive in my own work to set an example for her.

The place to improve the world is first in one's own heart and head and hands, and then work outward from there. Other people can talk about how to expand the destiny of mankind. I just want to talk about how to fix a motorcycle. I think that what I have to say has more lasting value.

—

ZAMM, Chapter 25