Code Generation Is Cheap. It Always Has Been.

There is a gold rush happening in software engineering right now, and it goes something like this: AI can write code! It can write it fast! It can write it in any language! The future is here and developers are 10x more productive!

And look, it is impressive. You can describe a function in plain English and get working code back in seconds. You can scaffold entire applications with a prompt. You can generate tests, write migrations, build APIs — all at a speed that would have seemed absurd five years ago.

But here is the thing that nobody seems to want to talk about at the AI hype conferences: writing code was never the expensive part.

A brief, incomplete history of “making code easier to write”

We have been making code generation cheaper for decades. This is not new. It is a pattern as old as software itself.

Assembly was “expensive” to write, so we invented C. C was “expensive” to write, so we invented Python. Boilerplate was expensive, so we invented frameworks. Frameworks were complex, so we invented scaffolding tools. And now scaffolding is complex, so we have AI.

Every single one of these innovations made the same promise: you will write less code, and it will be faster. And every single one of them was right. And every single one of them missed the point.

Because the cost of software was never in the writing.

The 80/20 rule nobody likes

Here is a number that has been roughly true for my entire career, and probably for yours too: about 20% of the total cost of a software system is building it. The other 80% is maintaining it.

Read that again. Eighty percent.

That means for every dollar you spend writing code — whether you write it by hand, generate it with AI, or have an intern copy it from Stack Overflow — you will spend four more dollars keeping it running, fixing its bugs, updating its dependencies, migrating its data, explaining it to new team members, and figuring out why it breaks at 3AM on a Tuesday.

AI code generation makes the 20% cheaper. That is genuinely useful. But it does absolutely nothing about the 80%. In fact — and here is where it gets spicy — it might make the 80% more expensive.

More code, more problems

When generating code is nearly free, people generate more code. This should surprise no one. When something becomes cheap, consumption goes up. That is economics, not computer science.

But every line of code, however it was generated, has a maintenance cost. It needs to be understood by humans. It needs to be tested. It needs to be deployed. It needs to be monitored. It needs to be debugged when it does something unexpected. And it will do something unexpected, because that is what software does.

So now you have teams generating code at 10x the previous speed, and the codebase is growing at 10x the previous speed, and the operational complexity is growing at 10x the previous speed. But the team maintaining it? Same size. Same humans. Same 24 hours in a day.

This is not a theoretical concern. Talk to any engineering leader right now, and they will tell you: the bottleneck is not “we cannot write code fast enough.” The bottleneck is “we cannot understand, deploy, monitor, and maintain what we have fast enough.”

The maintenance iceberg

Let us break down what “maintenance” actually means, because it is one of those words that sounds simple but hides enormous complexity.

Understanding: Someone (probably not the person who wrote it, and definitely not the AI that generated it) needs to understand what this code does, why it does it, and what happens when it breaks. This takes time, context, and institutional knowledge.

Dependency management: Every library you import, every service you call, every API you depend on — they all change. They release breaking updates. They deprecate features. They get acquired and shut down. Your code needs to keep up.

Operational overhead: Code does not run itself. It needs infrastructure, monitoring, alerting, logging, deployment pipelines, rollback procedures, and someone to look at all of that when things go sideways.

Debugging: The most expensive activity in software engineering is not writing code. It is figuring out why existing code does not work the way you expect. This is true whether the code was written by a senior engineer, a junior engineer, or GPT-4. Actually, it might be harder when AI wrote it, because at least the senior engineer remembers why they made that weird architectural choice.

Knowledge transfer: People leave teams. People join teams. Every time this happens, the new person needs to understand the existing system. AI-generated code does not come with the “why” — it only comes with the “what.”

The real AI opportunity is not generation — it is operations

Here is where I think the industry has the script flipped.

The most valuable application of AI in software engineering is not in writing more code faster. It is in helping teams deal with the code they already have. The code that is running in production right now. The code that breaks at inconvenient times. The code that nobody fully understands anymore because the person who wrote it left two years ago.

Think about where your team actually spends its time:

• Investigating why production is slow
• Figuring out what changed between the last working state and now
• Reading through logs to find the needle in the haystack
• Cross-referencing deployment history with metric changes
• Running the same diagnostic commands they ran last week
• Searching through documentation that may or may not be current

This is maintenance. This is the 80%. And this is where AI can make an enormous difference — not by generating more code, but by helping you understand, monitor, and operate the code you have.

The unsexy work is the important work

There is a reason AI code generation gets all the headlines and AI operations gets a footnote. Code generation is flashy. You type a prompt, code appears, it feels like magic. It makes for great demos and impressive Twitter threads.

Operational AI is boring by comparison. It reads logs. It checks metrics. It searches documentation. It runs diagnostic queries. It does the unglamorous work that keeps systems running. Nobody is going to make a viral demo of an AI agent checking your connection pool settings.

But here is the thing about boring, unglamorous work: it is the work that actually matters. It is the work that determines whether your team ships features or fights fires. It is the work that determines whether your best engineers stick around or burn out. It is the work that determines whether your customers have a good experience or a bad one.

Write fast, maintain smart

I am not anti code generation. Use it. It is a genuinely useful tool that saves real time on the 20% of software cost that involves writing new code.

But do not confuse cheaper generation with cheaper software. The total cost of ownership of a software system is dominated by operations and maintenance, and that has been true since before any of us were born.

If you want to actually reduce the cost of software — not just the cost of writing it, but the cost of living with it — invest in the boring stuff. Invest in monitoring. Invest in observability. Invest in automated investigation. Invest in tools that help your team understand and operate the systems they have, not just generate more systems to operate.

The code generation gold rush is real, and it is producing real value. But the real fortune is not in the generation. It is in making sure all that generated code actually works at 3AM on a Tuesday.

Because it will be 3AM on a Tuesday. It always is.