When AI writes the code, shared understanding becomes the scarce resource.
Working draft — feedback welcome
AI makes implementation abundant. What it can't make is the shared picture of what to build and why. Constructive friction is the mechanism that protects it. This book is the argument for why teams that keep that friction will outperform teams that optimize it away.
This book is not quite what it looks like.
It looks like a book about AI: about agents, specs, workflows, and the changing shape of software development. Those things are in here. But they're not what the book is about.
What the book is about started with a conference talk, a university friend, and 18 PlayStation Move controllers.
We were building a demo for KubeCon. The talk was called “18 Bluetooth Controllers Walk Into a Bar,” about observability and runtime configuration for JoustMania, an open-source party game where players jostle motion controllers until someone falls over. Complex execution: multiple Bluetooth adapters, battery-powered devices, sensors firing at 100Hz. When a player complains their controller “felt different,” how does anyone debug it at 2am at a convention?
A good and genuinely interesting problem and two people who knew the domain and cared about the project.
As we had different schedules, we started hacking on our own. We both made progress and moved fast.
And we never quite specced it together.
The knowledge gap opened quietly. Decisions got made that the other person didn't know about. Assumptions turned out not to be shared. Work that should have built on itself didn't quite fit together. Not because either of us was wrong, but because we hadn't stopped to build the shared picture before we started building the thing.
The full draft continues in the PDF.