When Code Got Cheap: Why Understanding Is Now the Scarce Resource in Software

The pattern feels eerily familiar. Years ago, I watched engineers in Bangalore craft elegant transcription pipelines for Heartland Information Services, their work deployed stateside to power critical medical documentation. The cost savings were undeniable—offshore development made code astonishingly cheap. Yet beneath the surface, a quieter cost was accumulating: the erosion of shared understanding. When the engineer who designed a failure-handling routine slept eight hours ahead of the on-call engineer debugging it at 2 a.m., the 'why' often got lost in translation. The code worked, but its intent lived in a different time zone, a different context.

Today, we’re seeing a structural echo with AI-generated code. Tools like GitHub Copilot or Cursor can produce syntactically correct, test-passing modules in seconds—code that would have cost thousands of dollars and days of human effort just a few years ago. The economics are rational, the productivity gains real. But as with offshore outsourcing, the savings don’t vanish; they migrate. The expensive part of software was never the typing. It was always the comprehension: knowing which parts are brittle, why a seemingly odd abstraction exists, how to change it safely when the pager goes off at midnight.

This isn’t nostalgia for a pre-AI era. I use these tools daily—they’ve genuinely accelerated my workflow for boilerplate and exploration. The danger lies in mistaking speed of production for progress. When we measure developer output solely in lines committed or features shipped, we repeat a mistake from the outsourcing era: optimizing for the wrong metric. Joel Spolsky observed over 25 years ago that 'it’s harder to read code than to write it.' That truth has only deepened. AI-generated code often arrives without a human who ever held the full mental model—no one to explain why a particular error case was handled this way, or why a dependency was chosen. The code is present, but its lineage of intent is fractured.

The insight from Prediction Machines is clarifying here: when a fundamental input (like code production) becomes cheap, economic value shifts to its complements. In software, the complement of production has always been understanding. During the offshore wave, companies that thrived didn’t abandon distributed teams—they invested in shared context: rigorous documentation blameless postmortems, and code review practices that treated comprehension as a first-class engineering discipline. The same principle applies now. If average code is cheap, then the scarce resource is the ability to navigate, assess, and evolve existing codebases—not to generate more of it.

This shifts where we should focus our tooling efforts. Instead of merely optimizing for generation speed, we need tools that make comprehension active and visible: better dependency visualization, intent-preserving comment generation, or exploration environments that surface 'why' alongside 'what.' Practices matter too—teams should allocate deliberate time for reading inherited code, treating it as core skill maintenance rather than grunt work. The goal isn’t to reject AI assistance but to ensure that the code it produces doesn’t become a black box we’re afraid to touch.

Of course, not all code demands deep understanding. Some scripts are truly disposable; some prototypes exist only to validate an idea. But for systems that endure—medical devices, financial platforms, infrastructure—the cost of misunderstanding compounds silently. A misread assumption in a legacy module can cascade into outages, security flaws, or failed migrations. The companies that will thrive in this new era aren’t those producing the most code fastest, but those that best preserve and transmit the human reasoning embedded in their systems. The craft of software has always lived not in the typing, but in the thinking that precedes and follows it. Our tools—and our habits—should reflect that truth.