I worked at a startup in Toledo called Heartland Information Services. We provided transcription services to some of the biggest hospitals in the United States, and we weren't small. Heartland was one of the larger medical transcription organizations in the country, one of the companies at the center of offshore transcription in that era. While that sounds simple enough, we were the kind of service where downtime had real consequences. Imagine needing emergency surgery but having to wait on a written copy of your procedure. Waiting may not be an option.

The engineers we worked with in India were talented. The company operated as a hybrid, and at various points our most critical work was being developed overseas and deployed stateside. The reason was straightforward: cost. Offshore development was dramatically cheaper, and for a startup watching every dollar, the savings were impossible to ignore. It was also the trend of the moment, Thomas Friedman had declared The World Is Flat and developers stateside were nervous. The question on everyone's mind was whether their jobs were next.

The code being produced was good. The engineers were some of the most talented people I have worked with. But there were moments, inevitable in any distributed system of humans, where the understanding of why something was built a certain way lived on one side of the world and the responsibility for maintaining it lived on the other. The knowledge existed somewhere, it just wasn't always where you needed it, when you needed it.

I've been thinking about Heartland lately, because the dynamic feels familiar.

The cost of producing code has collapsed. AI tools can generate functional, adequate, perfectly average code at a speed and cost that would have been unimaginable even five years ago. And like the outsourcing wave of the early 2000s, the economics are real and rational. Nobody is wrong for using these tools. The code they produce is often fine. It works. It passes tests. It might ship as-is.

But we've seen this pattern before. When code production gets cheap, the cost doesn't disappear. It migrates. It moves from creation to comprehension. This is the argument at the heart of Prediction Machines: when a fundamental input gets cheap, the value shifts to its complements. In software, the complement of production has always been understanding. The outsourcing era taught us that the expensive part of software was never writing it. It was understanding it well enough to change it safely, to debug it under pressure, to explain to the next person why a particular decision was made at 2 a.m. on a Tuesday.

The difference this time is structural. With outsourcing, the knowledge existed in someone's head. A developer in Delhi or Bangalore understood the intent, even if transferring that understanding across time zones and organizational boundaries was hard. With AI-generated code, the knowledge may not exist anywhere. There is no human on the other end who once held the full picture. The code has been committed, syntactically correct but devoid of intent.

This is not an argument against AI-assisted development. I use these tools every day and they have made me genuinely faster. But productivity that is only measured by lines produced is a metric we rejected decades ago for good reason. The outsourcing era eventually taught most organizations that the solution wasn't to stop working with distributed teams. It was to invest deliberately in shared context, documentation, code review, and the slow work of building mutual understanding. The companies that thrived were the ones that treated comprehension as a first-class engineering concern, not a byproduct of proximity.

We need the equivalent investment now. If average code is cheap, then the scarce resource is no longer the ability to produce it. The scarce resource is the ability to read it, to navigate it, to know which parts matter and why. Joel Spolsky wrote over twenty-five years ago that "it's harder to read code than to write it." It was true then. It is unavoidably true now. We need tools built for understanding, not just producing. We need practices that treat understanding as something you build deliberately, not something you hope will emerge.

I think this is what developer tools should be solving for next. Not just helping us write code faster, but helping us understand the code we already have, the code we inherited, the code that arrived fully formed from a prediction machine that does not actually know or understand the world we live in. That is where the craft lives now.