When Building Gets Cheaper, What Actually Changes?

TLDR: In this episode of "Still Burning," Kent Beck talks with Michael Grinich about what the AI transition looks like from inside enterprise infrastructure, why most people are misreading this moment, and how engineering leadership is quietly shifting under the surface. The "itchy brain" framing gets at something real: the compulsion to build is independent of the tools available, and that matters now more than ever.

Michael Grinich runs WorkOS, which powers enterprise infrastructure for hundreds of companies. That's an unusual vantage point. He's not reading trend reports or watching demo videos. He's seeing the actual plumbing of how software organizations are changing in real time, across a very wide surface area. When he says the whole ecosystem is accelerating, not just the AI companies, I take that seriously. That's not a pundit observation. That's operational data.

The conversation digs into something I find genuinely interesting: what happens when the marginal cost of software approaches zero? This isn't a new thought experiment, but we're actually running the experiment now. The old assumption was that building software was expensive, so you built carefully, maintained deliberately, and protected your existing systems. When that cost collapses, the entire calculus around what to build, when to build it, and whether to maintain it at all starts to shift. The organizations that understand this shift are moving differently from those that are still reasoning from 2020 assumptions.

The Red Queen theory gets invoked here, and it fits. In evolutionary biology, the Red Queen hypothesis says you have to keep running just to stay in place, because your competitors are also evolving. Applied to AI competition, this means that whatever edge you gain from adopting AI tooling today, your competitors gain roughly the same edge on roughly the same timeline. The differential advantage is smaller than the headlines suggest. What matters more is how deeply you embed these capabilities into your actual operations, not whether you adopted them first.

What I appreciated most in this episode is the discussion of how engineering leadership is quietly changing. "Quietly" is the right word. It's not a dramatic restructuring, it's a gradual shift in what the job actually requires. When a senior engineer can produce more code faster, the bottleneck moves. It moves toward judgment, toward architecture decisions, toward understanding which things to build at all. The leadership skills that matter are shifting from managing production capacity to managing direction. That's a meaningful change, even if it doesn't make headlines.

The title, "Itchy Brain," refers to something Grinich describes as the compulsion to make things. The itch that drives builders, independent of what's popular or profitable. I find this framing refreshing because it cuts through the AI hype in both directions. The people who are going to do interesting things with these tools are the same people who were doing interesting things before them: people who can't stop building, who find problems irresistible, who think in systems. The tools change. The underlying drive doesn't.

Key takeaways:

The marginal cost of software approaching zero doesn't just speed things up, it changes which questions are worth asking about what to build and why.
The Red Queen effect in AI adoption means survival requires constant adaptation, but the competitive advantage from early adoption is more modest than the discourse suggests.
Engineering leadership is shifting from managing output capacity toward managing judgment and architectural direction.
The "itchy brain" compulsion to build is a durable trait that predates AI tooling and will outlast whatever comes next.

Why do I care: As someone thinking about frontend architecture and engineering practice at scale, the framing around marginal cost is the most practically useful idea here. When building a new feature or service gets dramatically cheaper, it changes the conversation about technical debt, about investment in platforms, about when to buy versus build. The organizations I see struggling with AI adoption aren't struggling because they lack tools. They're struggling because their decision-making frameworks were built for a world where software was expensive to produce. Updating those frameworks is harder than updating your toolchain, and this conversation is a useful provocation to start doing that work.

Itchy Brain