待翻譯：Quality in the Age of AI Slop

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

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?", which resonated with many emotionally. Of course, there was also the epic 10-parter, "The Future of Everything is Lies, I Guess." My personal favorite is "I Think I'm Done Thinking About Gen AI for Now," 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. 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. 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 motorcyc [truncated for AI cost control]