Quality in the Age of Slop

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.

That nails it for me, yes.

I am biased because this piece talks about the book that single-handedly changed my life. I like it a lot, overall, though I think prefacing it with opinions of pseuds from goodreads is not a good idea.

Gumption traps come in many varieties, but all will be familiar to working software engineers.

Gumption traps are very relevant to programming, and I think you are bound to encounter each one that Pirsig lists at some point in your career. (I've written about them myself, too, though this was before widespread adoption of LLMs.)

The advice in ZAMM is so relevant to programming that I wondered whether Pirsig, ZAMM's author, had ever done any programming himself.

Of course he did, and in the sequel to Z&AMM, Lila, he even namedrops COBOL!

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.

Quality, I think, is best described as a layer sitting above subjective and objective. For the most concise explanation I think we have to go to Lila:

Any person of any philosophic persuasion who sits on a hot stove will verify without any intellectual argument whatsoever that he is in an undeniably low-quality situation: that the value of his predicament is negative. This low quality is not just a vague, woolly-headed, crypto-religious, metaphysical abstraction. It is an experience. It is not a judgment about an experience. It is not a description of experience. The value itself is an experience. As such it is completely predictable. It is verifiable by anyone who cares to do so. It is reproducible. Of all experience it is the least ambiguous, least mistakable there is. Later the person may generate some oaths to describe this low value, but the value will always come first, the oaths second. Without the primary low valuation, the secondary oaths will not follow.

The reason for hammering on this so hard is that we have a culturally inherited blind spot here. Our culture teaches us to think it is the hot stove that directly causes the oaths. It teaches that the low values are a property of the person uttering the oaths.

Not so. The value is between the stove and the oaths. Between the subject and the object lies the value. This value is more immediate, more directly sensed than any “self” or any “object” to which it might be later assigned. It is more real than the stove. Whether the stove is the cause of the low quality or whether possibly something else is the cause is not yet absolutely certain. But that the quality is low is absolutely certain. It is the primary empirical reality from which such things as stoves and heat and oaths and self are later intellectually constructed.

(If you want, I also have some more notes about it.)

In Lila, Pirsig endeavours to construct a complete metaphysical system and therefore qualifies his definition into splitting static patterns of quailty (tiered into inorganic, organic, social and intellectual) above which sits this indefinable dynamic quality that is the focus of Z&AMM.

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.

The question I would ask is whether adoption of AI is in itself a low-quality event or whether it is possible to integrate language models into the work of programmers in a way that is high quality. I think people are feeling that the way they engage with it is low quality, but because they don't have the words or the frame of mind to engage with it on a level that is not just subject-object dualism it's difficult to articulate, and they instead choose to reject it outright.

I think on some level AI enables romantic approach to programming in the sense that as long as you're able to engage with an AI-generated artifact on a surface-level and don't care to go deeper into it, it might be fine in a given moment. But when you actually try to look under the surface, into the code, you notice that there is no classical structure to it that you can reveal because it's been made by a model that pretended to work this way, but actually didn't. I suspect this is why people who have no inclination to engage with technology other than as a means to accomplish something else (executives, product designers, investors, solopreneurs, &c.) don't exactly understand the developers' frustration with AI-generated code.

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.

This is still true of documentation and manuals for software libraries and tools. I read the documentation for Pi agent the other day and walked away frustrated because it just assumes that part - that you already know what is good way to use it and you're only looking for ways to tailor it to your preferences. And my colleagues, whom I asked "well, how do you use this thing well" just looked at me puzzled.

Reminds me a bit of Vim. If you just read the Vim manual, you come away puzzled. We needed some decades of people writing pieces on how to use Vim well. And then it turned out that Vim itself might not even be the best platform for good Vim usage, so we got Kakoune or Helix.

My wife and I are expecting our first child later this year. A daughter! I'm beyond excited.

As a father to a two-year-old daughter, congratulations! You're in for a ride of your life.

If you're looking for more material in the same vein as Z&AMM, I would recommend Hofstadter and Sander's Surfaces and Essences (making the same point as Pirsig's analytic knife but in a less philosophical or metaphorical way), Lila as a sequel that tries to structure the contents of Z&AMM more, and the work of Sevilla King and John Vervaeke.

My fear is that software development is a dead profession walking. Not because agents can actually do the hardest and most demanding parts of the profession, but because the vast majority of software in the world has always been dodgy crap that just needs to limp along. This will combine with a classic "market for lemons", where most SaaS software will become buggy crap, and buyers will have no ability to distinguish it from the good stuff. And this will drive prices and demand downward. Somebody will still be employed writing software, but the total numbers will eventually decline, and the job will mostly become slop management. The exception will be a few lucky people working on "systems of record" and other stuff that has to work. But this will be like the small number of people who make a truly good living as movie stars, professional athletes, musicians, or game developers: a demanding craft where supply of qualified workers far exceeds demand, and only a handful make a good living.

But that's only the medium term. The real goal of the AI labs is to build something that can replace human intellectual and physical labor entirely, at lower cost than any human. They don't know how to do it yet, but they will spend every last dollar on the planet trying. The thing the investors dream of building would actually be an evolutionary successor to the human race. Again, they don't know how to do it. But they'll try.

So as for my personal AI policy:

1. For those cases where I care about the craft, I'm settling on using coding agents as an "artist's assistant", sort of like the people that painted the backgrounds for the great painters. Opus 4.8 is actually the wrong tool for this, because it's already too smart. You can lose track of your codebase I a reckless hour or two. I'm currently quite fond of Qwen3.6 27B, which is smart enough to run down a bug, carry out a refactoring, or implement a well-specified feature in code I understand. But as soon as I lose my understanding of the code, I get punished by the model getting confused. (And anyone who is bothered by how I maintain my open source software is entitled to a full refund of $0.)
2. My public policy position is that only fools and idiots would build their own evolutionary successor without some guarantee that coexistence is possible. Therefore, I flatly oppose building true human-level intelligence. But I oppose it at the international treaty level. But not the fake kind of international treaty. The sort of treaty where if you violate it, the US and China freak out at a deep level and commit to stopping your training runs. Local data center bans are fine and good, but if some asshole builds SkyNet in Iceland or the Middle East, then you still need to fight SkyNet. Stopping AI is fundamentally a state level problem. Harassing open source maintainers for having an AGENTS.md file is not a serious praxis.

So I largely agree with the OP. Software development can be a true craft, and I have spent 30 years of my life getting paid well do something I love. But if models improve much more, we risk entering a world where the number of people who truly love the craft of software exceeds the demand for actual software craft. The dark matter of corporate internal apps will be mostly happy with slightly better slop than they're getting right now, and that is the bulk of actual jobs in the profession.

I do mourn for my chosen profession. But I mourn more for the world and for the human race. We don't need to invest every scrap of our wealth trying to build something smarter and cheaper than a human, something that could be replicated with a cp command. But we're going to burn all the those resources trying.

I read through the entire post. I don’t know if that’s a sign of your fine prose or just my ability to stick with a long read, but I think it’s the former.

Regarding quality, one point Robert makes is that people differ about Quality not because Quality is different, but because people are different in terms of experience.

So before I comment on quality to my team, I ask myself whether our experiences are the same. If not, telling them to “improve quality” doesn’t work. I need to be specific about what to improve.

Extending this to AI-generated code, I wonder if “quality” differs according to experience, too?

I enjoyed this, thank you for writing it.

Personally, I feel like I straddle both sides of the “line”, insofar as there is one.

On one hand, I see that I yearn for the connection and relationship with the code that I would write without AI, and I notice that when I leverage AI that connection is lost. It’s real.

On the other hand, I think that the level of abstraction that leveraging AI nudges you upward towards, provides its own opportunity to apply discernment and impose one’s view of quality at that higher level of abstraction. In these cases, yes, the connection is still lost or degraded at the level of the code itself if you let AI perform that for you without sufficient involvement on your part. But it is not lost at whatever level of abstraction you are not asking the AI to contribute at. In my case, for my personal projects, this is at the architectural level and when defining interfaces. For example, recently I’ve been building harnesses and pipeines that make calls to various LLM providers. I think very carefully about the inputs and outputs to and control flow of these calls and how to compose them into a flow that accomplishes some broader goal I have. When I take the time and put attention and care into this process, I feel like despite losing my connection with the code itself I’m not losing my connection with my intention and the architecture. In other words, for me, quality and craft are not limited to what I leverage AI for.

This is sort of an exhausted analogy at this point, but it’s similar to being a manager or running one’s own company. I tell people that the hardest checkpoint in any CEO’s journey is the point at which they give up control, i.e. control over the ways in which their vision is precisely accomplished. It is simply not possible for the CEO of a sufficiently large enterprise to know every detail of how their vision is accomplished. I think this is true for CTO’s as well, albeit to a lesser extent, since they must still concern themselves with some technical details.

The mourning that I’ve gone through, the thing I’ve come to accept, is that there is a tradeoff between time spent, understanding, and output on any one venture; optimizing for any two shifts attention away from the third. But there is still ample opportunity to exercise discernment and have a quality to whatever combination is optimized for.

I am comentor B in this article and read it carefully. I haven't read ZAMM but I have read a bit of zen.

This makes a lot of sense, and most folks when given a free hand (sudden money or a boost in productivity) promptly waste it by becoming the biggest most obnoxious pieces of shit possible. There is some obvious dread around this.

People who use a computer tend to have a limited appreciation for how much craftsmanship and effort it took to make a book by using a typewriter movable print writing it by hand your own memory an ability to convince others to repeat your words by virtue of their beauty alone.

There is nothing about the computer that prevents people from investing a lot into the quality of their output and making something great. There are a lot of pieces of shit out there.

random bit on ZAMM: John's "romantic" view of technical artefacts can be defended as practical if it's applied on a case-by-case basis. say, you work on a project and rely on open source infrastructure. what does it do to your project when you need to rabbit-hole into an obscure kernel or compiler bug? one that you can easily work around, document, and reverse the workaround when someone fixes it? the bottom line is: one has to chose his own's battles wisely.