AI Is Making Software Disposable

Last week, I hit a bug in a small script I had written a few months ago.

Normally, I would open the file, read through the code, understand what was happening, find the edge case, and fix it.

This time, I did something different.

I told AI what was broken, explained what the script was supposed to do, and asked it to rebuild it.

About 90 seconds later, I had a working version.

I never opened the old code.

It was a small moment, but I think it points to a much bigger change in how we build software.

Software used to be expensive

A lot of what we call “good engineering practice” exists because software used to be expensive to build.

And rewriting software was even more expensive.

We review code carefully because a bug today might become a huge problem later.

We worry about backward compatibility because breaking an existing consumer can be costly.

We refactor slowly instead of rewriting because rewrites have a long history of going wrong.

We write documentation because the person who made a decision might not be around when someone needs to change it.

All of this comes from one basic assumption:

Software is something you build once and maintain for years.

So we protect it.

We patch it.

We refactor it.

We carry it forward.

We treat a codebase almost like a house.

You don’t rebuild your house every time you want to change a room because rebuilding is expensive.

AI changes the equation

AI coding tools are not just making developers faster.

They are changing the cost of building software.

Earlier, the choice was usually simple:

Fix the existing code.

Because fixing it was cheaper than rebuilding it.

But what happens when rebuilding something becomes almost as cheap as fixing it?

You describe what you want.

AI generates it.

You test it.

You ship it.

And if the requirements change significantly, you might generate the next version instead of spending days trying to reshape the old one.

That changes how we think about maintenance.

Maintaining existing software is no longer always the obvious choice.

Sometimes, starting again is cheaper.

We can already see this happening

Look at the software we never cared much about.

A script that generates a report.

A small migration tool.

A dashboard built for a launch.

A prototype created to answer one question.

An internal automation that was supposed to run for a month.

These things used to become technical debt.

Someone wrote them.

Then requirements changed.

Then someone patched them.

Then someone else patched the patch.

Eventually, you have a 500-line script that nobody wants to touch.

AI changes that.

If rebuilding the script takes five minutes, why spend two days understanding every line of it?

You might just regenerate it.

The interesting question is how far this goes.

Maybe it starts with scripts.

Then dashboards.

Then internal tools.

Then modules.

Then features.

Maybe eventually, some entire services become cheap enough to rebuild rather than maintain.

The boundary of “software worth preserving” could keep moving.

But not everything is disposable

This doesn’t mean all software becomes throwaway.

Some things are difficult to regenerate because the difficult part was never the code.

Data doesn’t regenerate.

A production database contains years of information. You can’t simply ask AI to recreate it.

Contracts don’t regenerate.

If other systems depend on your API, you can’t casually change the contract just because you generated a better implementation.

Compliance doesn’t regenerate.

Sometimes the audit trail and the reason behind a decision matter as much as the code itself.

And then there is something even harder to regenerate:

Context.

Maybe a strange piece of code exists because something broke in production two years ago.

Maybe a weird validation rule exists because a customer lost money once.

Maybe an ugly workaround is there because an external system behaves differently on Fridays.

The code might look wrong.

But there may be a very good reason for it.

AI doesn’t automatically know that history.

This is where blindly regenerating software can become dangerous.

So what changes for engineers?

If rebuilding software becomes cheaper, the skills we value will change too.

We may spend less time trying to understand every line of code that already exists.

And more time making sure we can clearly describe what the software is supposed to do.

That means specifications become more important.

Constraints become more important.

Tests become more important.

Documentation becomes more important.

Because if the code can be regenerated, the thing you really need to preserve is the intent behind the code.

The code might be version 5 today and version 6 tomorrow.

The important question becomes:

Can we reliably produce the right software again?

Think about compilers

There is an interesting analogy here.

We don’t usually write machine code by hand anymore.

We write higher-level code and let the compiler generate the lower-level instructions.

When something changes, we change the source and compile it again.

We don’t normally open the generated machine code and manually patch it.

Why?

Because we trust the compiler.

AI-generated code could move in a similar direction.

Not today.

Not for everything.

But the direction is interesting.

As AI gets better, code may start to feel less like something humans need to maintain line by line and more like an output that can be generated from intent.

The source of truth might become the specification, the tests, the constraints, and the data.

The code becomes the output.

Maybe software doesn’t need to live forever

We’ve spent decades learning how to build software that lasts.

That’s still important.

Systems that handle money, customer data, infrastructure, or critical business processes need strong engineering.

But AI introduces another possibility.

Some software doesn’t need to last.

It just needs to solve the problem well enough today.

If the problem changes tomorrow, maybe we build the next version.

That doesn’t mean engineering standards disappear.

It means we need to get better at deciding what deserves to be maintained and what is cheaper to regenerate.

AI isn’t making software disposable because engineers are becoming careless.

It’s making software disposable because the cost of turning an idea into working code is falling.

And when the cost of rebuilding gets close to the cost of maintaining, the entire equation changes.

We spent decades learning how to build software that lasts.

Maybe AI is teaching us something different:

Sometimes the fastest way forward isn’t maintaining what you built.

It’s building the next version.

The question isn’t whether AI will make software better.

The more interesting question is:

Will we still expect our software to live as long as we once did?