We all get more excited about new stuff. New product, new system, new infrastructure. Something cool and original to build or implement.
Who owns the boring update, five years from now?
Not the builder. Not the person who got the idea approved, or presented the demo to execs.
When the original team moves on, and the documentation has gone stale, and something that depends on it changes - who fixes it?
We’re better at building than maintaining.
Greenfield projects have a story. See the problem, build it, launch it. Celebrate.
Maintenance is boring. Repetitive. Invisible. It only gets attention when something breaks.
Nobody celebrates the bridge that doesn’t collapse. Or the security exploit that gets patched before anyone else notices. Your internal tool that everyone uses, well after the original team left the company.
“Stuff didn’t break” isn’t generally a path to promotion.
Maintenance is cost. Creation is investment.
At least until there’s a failure. At which point everyone wants to know why we didn’t invest more in that maintenance.
Things! Stuff! New!
And we’ve accelerated software creation. AI’s changed our economics.
We can generate code, applications, complex systems. Faster than we ever thought possible.
I do this. It’s cool. Sometimes it feels like magic.
What happens afterwards?
Whether a new application gets developed in an afternoon or over two quarters, it still has a lifecycle. There’ll be updates and security review. It needs monitoring. Someone is responsible for it not breaking.
The speed of AI creation means we’re accumulating a huge amount more infrastructure. GitHub has seen a 10x growth in commits and code just from 2025 to 2026. That’s entirely the result of AI. Now GitHub is planning for a 30x expansion in its own capacity.
All these things need maintaining.
And the number of people who depend on something doesn’t always have any relation to the resources available to maintain it.
When I worked on Carbon a few years ago, we used an open source calendar interface as the foundation for our own calendar pattern. Other major enterprises did, too. Facebook used it.
It was maintained by one person. A student who lived in Canada.
A student who’d built something that at least two Fortune 100 companies had integrated into their front-end infrastructure. A dependency those companies didn’t control, didn’t fund, and didn’t know if it would even continue to exist.
With AI, we can reproduce that problem at a massive scale.
Information gets old
Our AI doesn’t just create software. It’s also consuming information about how software is supposed to work.
Design systems. API specs. Coding standards. Architecture decisions. Internal documentation.
We’re trying to provide this context to agents in ways that let them work within an organization’s own standards.
But that information can get old.
An API changes. A component is deprecated. A security policy is updated. An architectural decision gets reversed.
The agent keeps working.
We could deprecate a design component. The docs get old. The team remembers a conversation about the change. Humans fill the gap by asking each other questions. Is this still supported?
If the agent has outdated context, and implementation has moved on, it’ll keep generating the deprecated component over and over again. It might pass tests - especially if the tests use the same old assumptions.
We’ve given the agent the wrong information.
We used to have to update our documentation and then get our teams to start adopting the latest version. Now the machines will consume that information, and make decisions using it.
The persuasion problem is less. The update problem is more critical. We need to maintain the information that determines what gets made.
Agents produce at scale. So the cost of getting the information wrong scales too. The alignment becomes infrastructure itself.
Keeping things true
I think this has implications for how we think about software’s value.
Open specifications are getting more important. Freely available formats open up our opportunities to build businesses.
But those specs need their own maintenance.
We need to keep implementations synchronized and conformant. We need to verify that. Someone needs to determine which version is right.
Open specs get out of date, too. They might tell you what was true last month, not today.
That was a meaningful distinction that compounds when AI agents consume the specs without question. Our capability to keep software correct, and the foundational specs updated, is even more important.
When information eats itself
The problem can also make up part of the solution.
Just get AI to help with the maintenance, too.
Sensible enterprises are doing that already. Use agents to identify dependencies. Propose patches. Update documentation. We’ve seen reports of how new frontier models identify old security vulnerabilities in critical software.
We should keep doing that, and do it more.
Although this starts to turn into a bit of an ouroboros.
If we use an agent to maintain a system, it needs reliable information on how the system is supposed to work. The information about how the system is supposed to work also needs maintaining.
And so on.
Sure, we can automate a lot of that work. But at some point, people will still need to decide what’s the authoritative answer. Whether this change is acceptable. And, perhaps most important, who’s accountable if it breaks.
Someone still needs to own the boring update.
A lot of my career has been working on design system and platforms. Things that other people depend on.
Building the first version is the fun part. It’s rarely the hardest part.
Organizations change. Technology changes. Team members change.
AI doesn’t just make the creation part easier. It makes the maintenance part even more important.
We’re still funding, organizing, and celebrating the creation part - even as the volume shows it’s getting easier.
Maintenance has always been the thankless task. We’re making it harder. We still haven’t figured out who owns it.
Further reading:
Fedorov, V. An update on GitHub availability. GitHub Blog, Apr 2026.
Buhl, B. You Built It. Now Pay Up. The Brutal Truth About Software Maintenance Costs. Broadleaf Commerce, Jan 2026.
Shore, J. You Need AI That Reduces Maintenance Costs. James Shore, May 2026.