I’ll get straight to the point: your AI coding agent, the one you use to write code, needs to reduce your maintenance costs.
Not by a little bit, either.
You write code twice as quick now? Better hope you’ve halved your maintenance costs.
Three times as productive? One third the maintenance costs.
Otherwise, you’re screwed.
You’re trading a temporary speed boost for permanent indenture.
Oh, you want to know why? Sure.
Let’s go for a drive.
On a dark desert highway...
Productivity is Determined by Maintenance Costs Every line of code you write has to be maintained: bug fixes, cleanup, dependency upgrades, and so forth.
I’m not talking about new features or enhancements.
Just maintenance.
For every month you spend writing code, you’ll spend some amount of time in the following year maintaining that code, and some in each year after that, forever, as long as that code exists.
Let’s say you asked a crowd of, say, 50 developers what those maintenance costs were.
Using a technique called Wisdom of the Crowd, you could get a reasonably accurate response.1 1You’re welcome to conduct your own wisdom-of-the-crowd survey! But it turns out that the specific numbers don’t matter for the overall point I’m making here.
Your crowd might tell you that, for each month you spend writing code, you’ll spend...
10 days on maintenance in the first year; and 5 days on maintenance each year after that.
If you were a particularly obsessive individual, you could spend hours making a spreadsheet modeling how those estimates affect productivity over time.
A spreadsheet like this.
The first month of a new project is glorious.
You spend all your time building fancy new features.
The next month is slightly less glorious.
A fraction of your time—not much, but a smidge—goes to fixing bugs and cleaning up design mistakes from the first month.
In the third month, a smidge more.
And the fourth month, the fifth, the sixth...
Eventually, it’s not glorious at all.
According to our crowd’s maintenance estimates, you’ll spend more than half your time on maintenance after 2½ years.
After ten years, you can hardly do anything else.
Halving the crowd’s maintenance estimates gives you three more years before you hit the 50% mark.
Doubling them sees you below 50% in less than a year.
The lesson is clear.
If you want a productive team, you have to focus on their maintenance costs.
All Models Are Wrong Do these numbers ring true to you? They do to me.
In my career as a consultant, I specialized in late-stage startups, and they all had the exact problem shown in the graph above.
About 5-9 years in, they’d notice their teams were no longer getting shit done, and then they’d call me.
Their teams weren’t quite as bad as the graph shows.
Maybe their maintenance costs were lower.
and this feels more likely to me...
their maintenance costs were exactly that bad, and they papered over the problem instead.
Maybe they: Decided not to fix every bug, or upgrade every dependency Added people when the team got slow...
and then kept adding more, because it was never enough Scrapped it all and started over....
