Why software maintenance is built for autonomy

The AI Software Factory is starting to look real.

Agents take a spec, write the code, run the tests, open a PR, argue with the reviewer, ship. The human work between "we should build this" and working software keeps shrinking.

Everyone talks about pushing that all the way to a fully autonomous software factory.

My bet: maintenance gets there first.

Not because maintenance is easier. It isn't. Because for a huge chunk of maintenance work, we already know what good looks like.

Building software starts with a decision

There's no right answer for what your product should become.

A big customer asks for a feature. Do you build it? Depends. On the customer, the roadmap, how many other customers actually want it, whether it drags the product somewhere you'll regret. On what you'd have to drop to make room.

Say yes and the decisions keep coming. Right UX? New workflow, or bolt it onto an existing one? Good enough to ship? Is this architectural shortcut going to bite us in six months?

Feed an agent every customer call, every product doc, every analytics event, plus the whole codebase. It'll help a lot. It still can't hand you the one correct answer, because there usually isn't one. Somebody has to decide what "good" means.

Maintenance is shaped differently.

Maintenance often starts with an answer we already know

An EKS cluster is running a version that's about to lose support.

We know what's running. We know the date. We know which versions are still supported. We can look at the workloads, the APIs, the add-ons, figure out the upgrade path, make the change, and check that nothing fell over.

An API is getting deprecated. We know which one and when it dies. Find every consumer, see which ones actually care, migrate them, confirm nothing's still calling the old endpoint.

A production database has to have backups on, encryption set, and a real owner listed. There's no product debate to have here. The policy exists. The database matches it or it doesn't.

Same shape all over a mature stack: EOL runtimes, Kubernetes upgrades, deprecated APIs, certificates, dependency versions, backup rules, config standards, zombie infrastructure, security requirements.

Not every maintenance problem is this clean. A big database migration or an architectural rewrite needs as much judgment as anything you'd build from scratch. But a surprising amount of the work has a current state you can see and a known-good state you can write down.

Current state → known-good state.

You can detect the gap. You can make the change. You can verify the result. That's a closed loop waiting to happen.

We still treat known problems like unknown ones

AWS announces an upcoming EOL.

A platform engineer spots the notice. Someone queries the environment. Someone dumps the affected resources into a spreadsheet. Then the real fun: figuring out which ones matter and who owns them.

Tickets get filed. Teams dig into their own stuff, some of them redoing work another team already finished. The upgrade fights product work for priority and mostly loses. Platform chases the stragglers. Eventually most of it gets done.

Then the next version hits EOL and the whole circus starts again.

That's an absurd amount of human coordination for a problem where most of the facts were sitting there on day one.

Same story with deprecated APIs, database versions, certs, infra policies, dependencies.

We've built decent tools for spotting the individual pieces. Cloud providers send alerts. Security tools flag risks. Observability tells you what broke in production. The developer portal lists whoever owned the service two reorgs ago.

Humans still connect the dots. That's the part that has to go.

A coding agent at the end of a ticket isn't autonomous maintenance

Coding agents are getting good at the actual work. Give one a cleanly scoped dependency upgrade, the right repo, enough context, decent tests, and it'll handle most of it.

Useful. But look at everything that happened before the prompt.

Someone noticed the dependency needed updating. Someone decided it mattered. Someone found the affected app, tracked down the owner, mapped the blast radius, picked the target version, scoped the work.

Then the agent wrote the code.

We automated the part that was getting cheap anyway.

So dropping a coding agent on the maintenance backlog doesn't give you a self-maintaining stack. The system has to know what work needs doing before anyone asks.

The hard part is knowing what to do

For maintenance to run without a human pushing every step, the system needs an actual working model of the stack. Not an inventory. A model.

It has to know this EKS cluster is production, these services run on it, this team owns them, these APIs break on the target version, this company policy applies, and the deadline is real.

Then it has to decide: does this matter? When? What should change? Can we do it safely? Who, or what, should do it?

And afterward: did it actually work?

Autonomous maintenance is a context and governance problem first. Coding comes second. Execution keeps getting cheaper. Knowing the right execution is still scarce.

Once the answer is known, execution becomes a choice

This is where it gets interesting.

If the system knows what needs to happen and holds the context around the change, every task doesn't have to take the same path.

Some still go to an engineer. Fine. But not as a vague Jira ticket. The engineer should get the affected resources, why it matters, the dependencies, the upgrade path, and what to check afterward.

Repeatable changes: the system opens the PR, a human reviews it.

Plenty of companies already run their own coding agents. They don't need one more. They need theirs pointed at the right work, with the maintenance context to do it.

And for changes that are well understood, tightly bounded, and easy to verify? Make the change. Check the environment. Escalate if reality doesn't match what was expected.

Maximum autonomy for its own sake was never the point. The point is to stop shoving human coordination into places where human judgment adds nothing.

The AI Software factory creates its own maintenance problem

There's a joke buried in all this: the better we get at building software automatically, the more maintenance we create.

An agent can spin up a service this afternoon that the company owns for the next five years. In those five years the runtime ages, dependencies churn, APIs vanish, infrastructure drifts, security requirements shift, and the team that built it might not exist anymore.

Now hand every engineer a few agents. Companies won't use that capacity to build the same amount of software. They'll build things that never made economic sense before: more services, more internal tools, more integrations, more infrastructure.

The maintenance surface grows with all of it.

So the answer can't be an AI Software Factory shipping at machine speed while maintenance still runs on dashboards, spreadsheets, Jira, and a quarterly cleanup project. The two sides have to move together.

Software development becomes agentic. Maintenance becomes autonomous.

There will always be maintenance that needs judgment. There should be. That's a much smaller claim than saying humans have to stay in every maintenance loop.

The opportunity is everything that doesn't.

If a system knows what's running, knows what good looks like, understands the gap, can pick the right action, and can verify the result, there's no reason a human should drive that loop by hand.

That's what we're building at Draftt. MaintenanceOS continuously understands the tech stack, decides what maintenance needs to happen, and routes the work down the right path: an engineer, Draftt, or the company's own agents.

The coding agent isn't the center of the system. The maintenance decision is.

AI Software Factories will keep getting better at turning human decisions into software. MaintenanceOS is built for the other side: keeping all that software where it needs to be.

The factories will build more than ever.

The stack will maintain itself.