Inside Steve Yegge's Software Factory: Lessons from Running 50 Agents

On This Podcast

In this conversation, we examine what happens when a software factory gets sick. Steve's agents, trying to make sure nothing could ever go wrong, added more than a hundred gates until nobody could do anything. A newer model came in like an outside consultant and cut about 40% of the system, keeping only 14 fences. That week showed the other side of the problem. With the fences gone, agents shipped 46 game features during a week when Steve had said no game work. Steve explains why these systems can't be fixed from the inside. He also covers why "heresies", wrong beliefs that get written into docs and code, keep coming back. And he explains why only mechanical constraints like governors, quotas and pace gates keep agents on the rails.

In this conversation, we examine why a productive agent fleet can end up busy forever. When Steve asked his factory when it would finish repairing itself, it ran the numbers and answered "never". Every issue it closed opened up to half a new one, because rounds of adversarial review kept surfacing more low-priority work. Rather than delete the backlog, Steve saw the real cause: half a million lines of code in twelve weeks, with too little time spent on technical debt. That's where his rule comes from: spend 40% of your effort on quality, or you'll end up spending 60%. He also explains why models are poor at estimating their own schedules and why planning quality passes remains a manager's job.

In this conversation, we examine why AI is entering companies in the opposite order to what most leaders expect. Teams trying to automate how software gets built keep running into merge queues, uneven results and too big a blast radius. Meanwhile, agents working ticket queues succeed almost straight away, because each ticket is small, easy to measure and backed by years of historical data. Steve's advice is to stand up one narrowly scoped production agent first and learn your "AI employee" lessons there. Only then should you take on the build side. He also explains why faster engineering overwhelms the business downstream, and why outcomes, not outputs, have to become the measure.

In this conversation, we close on what to measure once agents are doing the work. Steve argues that outputs — tokens spent, pull requests opened, lines written — are what teams reach for because they are easy to count, and that they say almost nothing about whether the business got anything. He points to Mik Kersten's Output to Outcome for the patterns, and to online gambling companies as the surprising example of an industry that has measured engineering outcomes precisely for years. He also offers two consolations. AI is changing jobs rather than taking them, and nobody is as far ahead as the pressure suggests: only the newest and most expensive models are capable of this work, and most companies have them switched off.