This edition is the second in a series of periodical articles chronicling the things I’m learning and creating right now—I’m still finding the right name, cadence, and scope of content to include, and want your feedback!
Volume as a Proxy for Productivity
A colleague recently shared an article with me about output-competence decoupling: It’s the idea that the quality (and perhaps quantity) of a work is no longer a reliable indicator of its producer’s competence.
My favorite excerpt from the article:
The cost of producing a document has fallen to nearly zero; the cost of reading one has not, and is in fact rising, because the reader must now sift the synthetic context for whatever the document was originally about.
I’m seeing this exact failure mode of AI-generated content every day in my own work. So often, someone gives me a ten-page document with content equivalent to ten concise bullet points.
I wish they’d just given me the bullet points.
I’ve been tempted to say the root cause is people using AI to generate docs, but that isn’t quite it. I think a skilled writer can use AI and produce fantastic work.
Instead, I think it’s an issue of empathy.
Writing is not the act of generating text. Writing is the process of creating text with empathy for a reader, in large part by having understanding and accountability for what’s being written.
When someone delegates their writing to AI on a new topic or for a new audience, they rob themselves of the experience of writing—of the opportunity to create a meaningful work.
I let AI auto-respond to every text and email until I realized that was a fast track to unemployment and divorce.
— Joanna Stern, “I Am Not a Robot: My Year Using AI to Do (Almost) Everything”
Increasingly, if anyone gives me a long-winded document for human consumption, I insist they take the time to rewrite it by hand—even if they’re just paraphrasing the AI—so that they internalize and understand what they’re writing about, and ensure I read exactly what they want me to care about.
The Trust Factory
I believe products created with empathy are more valuable to whoever interacts with them. But more than value, empathy also builds trust.
We’re accumulating code faster than we’re accumulating trust. Yes, we can create code faster now, but software is bipedal—code & trust go together. One without the other just hops along awkwardly.
Last week, Kent Beck wrote about the Trust Factory—about how we (as engineering teams) are accumulating code faster than we’re accumulating trust.
With so much of engineering work happening in “single-player” (engineers creating code with AI with minimal interaction with other engineers), the interactions that once built trust within teams are fading.
The answer to this problem of trust is still murky. However, I think it’ll start with slowing down: In the same way I think it’s important to hand-write (certain) docs intended for humans, I think it’s important to still be hands-on with (certain) code intended for production.
In a recent experiment I did while building a personal project with minimal AI help, Opus 4.7 generated 3x as much code as my hand-written implementation—and it concurred that my version was better. The root-cause seemed to be a lack of long-horizon thinking from the agent, which is a consistent problem.
I’m very optimistic about how these AI “Genies” (as Kent calls them) can take over the boring parts of coding, particularly where the human cost of failure is low.
But I’m not quite at a point where I would entrust my or my team’s reputations to the outputs of these coding agents.
Enthusiastically Skeptical Feedback Loops
Also last week, Charity Majors published an article breaking down the breakdown in trust between AI optimists and AI skeptics.
Within the software engineering discourse, there are two big camps of thought:
AI optimists, who are excited about the value they can unlock with AI.
AI skeptics, who worry about what happens after that value is unlocked.
As Charity so perfectly notes:
The wins are real, the costs are real. This ought to be a fruitful source of tension, where skeptics and enthusiasts join up to solve hard problems with their powers combined, Powerpuff Girls-style.
The problem is, the wins and costs are happening to two different groups of people. There is no natural feedback loop.
— Charity Majors
I think the right answer is somewhere between skepticism and optimism.
It’s easy to be a fervent skeptic. Particularly when you see Claude produce 3x as much code as you, 3x as fast.
But it’s just as easy to feel optimistic: Just weeks ago, Claude was able to review one of my distributed consensus patents, and identify a slew of improvements and corner cases I missed in the original specs.
Part of the challenge is that optimistic voices are everywhere right now: Back in March, Rathin Shah on X shared his takeaways from nearly 200 Y-Combinator pitches. 60% of the pitches were AI-first, while only 14% of the pitches had no AI.
I’m not sure which camp I fall into: I’ve been working in AI engineering since before ChatGPT was a thing, and before that I operated some of Wayfair’s most valuable production infrastructure (advertising…) where AI’s unreliability would be a liability. I’ve experienced the limits of what AI can do, but also the benefits it unlocks when used well.
Right now, my personal take is that AI is perfect for situations where the problem is intractable or desperately boring for a human to solve, and where the human cost of failure is low.
In other words: I’d happily vibe code a prototype for any app, ever. But if I’m building a system that could cause substantial loss of revenue—or worse, loss of life—I would prefer to use AI as a partner, and not as the principal creator.
Speaking of substantial loss of revenue…
The Human Cost of Failure
Charity’s analogy of feedback loops reminded me of my first production incident at Wayfair.
My staff engineer mentor and I had just finished running a load test of a new distributed data processing pipeline. I was quite proud of it. It was the first time I got to put my theoretical knowledge of distributed computing to the test, and it worked marvelously: Millions of ads for millions of products were generated in under an hour, beating the existing solution by an order of magnitude.
The funny thing about ads is that they need images, and the not-so-funny thing is that (at that time) all images at Wayfair were served from an existing service monolith (which supported the vast majority of our back-end workloads).
In short, our shiny new pipeline denial-of-service’d the Wayfair monolith for an hour, and brought many internal workloads to a halt. It was my first P1 incident.
During the ensuing post-mortem, I gained a deep appreciation for observability and site reliability engineering as a discipline. But I learned something else, too.
For the hour that our systems were down, our frontline support teams couldn’t do their jobs. Because their performance hinged, in part, on how many tickets they fielded, their compensation was directly impacted by my team’s mistake.
Through this incident, I learned the human cost of our systems’ failure. A cost that I couldn’t see from my ivory tower while I was blazing a trail of innovation.
Since then, whenever I’m building or rebuilding a system—with or without AI—my first question is always “Who cares about this system?”
This might seem like a silly and fundamental question, but every system we build (whether directly or indirectly) serves a human purpose.
For decades, we software engineers have benefited from the prestige of professional engineers’ titles (think: people who design bridges). However, we’ve not consistently taken on the mantle of responsibility that comes with this title.
Ergo, I believe the purpose of a software engineer is not merely to produce code—it’s to be accountable for our systems’ purposes, and the lives impacted by them.
What’s Next
Last month, I published my first article after a months-long break working on my mechanical sympathy article with Martin Fowler: Defining Innovation. Next week, I’ll be publishing a follow-up to my innovation article chronicling my takes on AI’s impact on open source.
Also: Twice a year, I create a game from scratch in a weekend. This April, I created my third game (”in:frequency”). Why not give it a try in your web browser, and read about how I made it, in this behind-the-scenes article?
Acknowledgements
Queenie Ho, for sharing with me the delightful quote from Joanna Stern’s book “I Am Not a Robot: My Year Using AI to Do (Almost) Everything”.
During my editing process, I used Anthropic's Claude Opus 4.8 to review my drafts for grammatical errors, and to give feedback on the structure and accuracy of my claims. AI was not used to generate any text.
Hello Caer,
Lots of good points in this article. My favorites are:
* code & trust go together: yes, code is not just code, similar to how writing is not only writing. As humans we care about the writer/author and their relationship to us, their intentions and motives, etc.
* "engineers creating code with AI with minimal interaction with other engineers": unfortunately this is common with small teams and newer startups where AI use is encouraged
* also thanks for using real images. AI generated images are too common now and often hurts my eyes :)