As writing code becomes more and more like “pressing a button to get results,” a more subtle question begins to emerge: Has anyone actually understood the code we get?
This isn’t a story about improving efficiency; it’s more like asking a more realistic question—when the cost of generating code is driven to extremely low levels, will those capabilities in software engineering that were once considered “taken for granted” quietly become new scarce commodities?
Original link: https://www.poppastring.com/blog/what-we-lost-the-last-time-code-got-cheap
Mark Downie Editor | Su Mi
I used to work at Heartland Information Services, a startup in Toledo, USA. We provided transcription services to some of the largest hospitals across the United States. We were one of the leading companies in the US medical transcription industry at the time, and we also participated in the wave of outsourcing transcription business overseas.
These kinds of services may sound simple, but they are actually very critical: if the system goes down, the impact is real. For example, you might need emergency surgery, but you have to wait for the surgical records to be converted into a text version before you can proceed. This kind of waiting is unacceptable.
At the time, our engineering team in India was outstanding, and the company adopted a “hybrid model”: critical systems were developed partly overseas and deployed partly in the United States. The reason was simple—cost. Overseas development was much cheaper, and for a startup that had to calculate every penny, such savings were undeniable. It was also an industry trend at the time; Thomas Friedman proposed that “the world is flat,” and many American developers began to worry about whether their jobs would be replaced.
In retrospect, the code quality was actually quite good, and the Indian engineers were very capable. However, a common problem arises in this kind of cross-regional collaboration: the reasoning behind a certain function’s design might only exist in the understanding of someone on one side of the world, while the person maintaining it is on the other. Knowledge exists, but it’s not always readily available when you need it.
I’ve been thinking a lot about my experience with Heartland lately because the current situation feels somewhat familiar.
This time, the code is “cheaper”.
The cost of writing code has now dropped dramatically. AI tools can quickly generate good-looking, working, and testable code at a speed and cost unimaginable just a few years ago.
Just like the outsourcing wave of the past, this is all a rational economic choice—no one “made a mistake.” The code written by these AIs is usually fine; it works and can be deployed.
But history has shown us a pattern: when “writing code” becomes cheaper, the cost doesn’t disappear, it just shifts.
It will shift from “writing code” to “understanding code”.
A core idea in “Prediction Machines” is that when a basic capability becomes cheaper, its value shifts to “complementary capabilities.” In software, this complementary capability has always been “understanding.”
The outsourcing era has proven that what’s truly expensive is never writing code, but understanding code—understanding why it’s designed this way, how to safely modify it, how to debug it in emergencies, and how to explain to the next person “why it was written this way at 2 a.m.”
The difference this time is that perhaps no one has truly “understood” it.
In the era of outsourcing, knowledge does exist, but it’s scattered across different people’s minds. For example, developers working in Bangalore or Delhi usually know the design intent, but it’s difficult to convey this understanding to another time zone and organizational boundaries.
But the situation is different with AI-generated code—often, no one truly understands the code completely. It may be “generated,” syntactically correct, but the underlying intent doesn’t fully exist in anyone’s mind.
The code was committed, but the “understanding” was not committed along with it.
This is not against AI writing code
This isn’t to say that AI can’t be used. I use it myself every day, and it has definitely improved my efficiency.
However, if we only use “how much code is produced” to measure productivity, that is actually a metric that has long been proven to be problematic.
The outsourcing era later taught the industry one thing: the solution is not to stop distributed collaboration, but to deliberately build a “shared context”—documentation, code review, communication mechanisms, and long-term commitments that allow teams to truly understand each other.
Successful companies treat “cost of understanding” as a core engineering problem, not a byproduct.
What will be truly scarce next?
If average-quality code becomes cheap, then the real scarcity will no longer be “coding ability,” but rather the ability to understand code, locate critical parts in complex systems, and comprehend “why this is important.”
25 years ago, Joel Spolsky said, “Reading code is harder than writing code.” He was right then, and he is even more so now.
The problems that next-generation tools should solve
Next-generation development tools shouldn’t just help us “write code faster,” but should help us:
To understand existing code more quickly
Understanding historical legacy systems
Understanding AI-generated code that no one has actually designed.
Because the real focus of our work is now shifting from “creating code” to “understanding code”.
And this is the core of the new engineering capabilities.
