Every Software Factory Needs a Maintenance Line
Dominik Dorosz
August 5, 2026 · // 6 min read
The software factory is the most interesting idea in engineering right now: agents on an assembly line, work flowing through stages automatically, output that scales past headcount. Almost every version being built today is an assembly line for new code. That’s the problem.
Every engineering leader has a number they don’t put on the roadmap slide: the percentage of capacity that disappears into keeping the lights on. Across the hundreds of engineering organizations we’ve worked with, it sits between 30% and 50%. Dependency upgrades. CVE patches. Framework migrations. Config drift. None of it ships a feature. All of it has to happen anyway.
A factory with no maintenance line doesn’t get faster. It accumulates debt faster. And that debt doesn’t sit quietly off to the side. Unpatched CVEs block deploys. Stale dependencies break builds. Drift makes every agent-written change riskier to merge. Eventually the work you deferred becomes the thing throttling the whole line, and by then it’s far harder to dig out of than it would have been to keep up with.
The factory manufactures its own maintenance load
This is the part that makes the problem structural instead of just unfortunate.
Maintenance load is a function of how much software you have. More repos, more dependencies, more frameworks, more config, more surface area to keep current. A software factory’s entire purpose is to produce more software. So here is the catch, the faster the line runs, the faster the maintenance load grows.
Run the math on your own org. If 40% of your capacity goes to KTLO today, and you double feature output without adding any maintenance capacity, you haven’t improved the ratio. You’ve built a backlog that grows at twice the old rate against the same amount of people to work it down.
It gets worse than a queue problem, because maintenance is what keeps the rest of the factory fast. Agents do their best work on codebases that are consistent and current: predictable structure, dependencies that resolve, CI that passes, patterns that repeat across services. Every quarter of deferred maintenance makes the codebase less like that. The factory that skips the maintenance line degrades its own throughput, and the mechanism is invisible until it isn’t.
But wait… we already have bots that already handle it!
The obvious objection: we already automate this. Dependabot and Renovate have been opening dependency PRs for years.
They have, and they’re genuinely useful. They’re also solving a narrow version of the problem. Bot-based updates work when the change is mechanical and single-ecosystem: bump a version in one manifest, one repo at a time, and hope CI tells you whether it worked. Nobody decides what to prioritize, nothing adapts the change to how a given repo is actually set up, and no one is tracking the resulting 200 open PRs as a single piece of work.
Which is fine, because that describes maybe a tenth of the load. The hard part is everything is shaped differently. The CVE patch that has to land in 200 services by Friday. The dependency bump that breaks four frameworks in four different ways and needs a real code change in each. The CI migration off a tool nobody wants to touch. The internal library deprecation where every consumer calls it slightly differently. None of that is a version bump, and none of it is one repo.
Maintenance is wide, not deep
It’s not that maintenance is technically harder than feature work. It’s a different shape.
IDE-based AI tools, and coding agents generally, are built for one developer doing deep, careful work in one repo. That’s the shape of feature work. Maintenance is the opposite: the same conceptual change, applied correctly across many repos, teams, languages, and frameworks in the org, then coordinated through review and merge without anyone losing track of where things stand.
This is why “just point a coding agent at it” doesn’t close the gap. The generation step was never the bottleneck. Determining scope, adapting one intent to 200 different setups, sharing context between implementations, and then shepherding 200 PRs through CI and review is an orchestration problem. Orchestration is what maintenance backlogs are actually made of. That’s how these backlogs pile up at organizations with strong engineers and good tools.
What a maintenance line actually looks like
If you’re designing the factory, maintenance deserves its own focus, not an afterthought bolted onto the feature line. In practice that means:
- Plan the change once, in plain language, instead of writing a ticket per repo.
- Generate the change across every targeted repo, adapted to that repo’s actual setup, not a find and replace.
- Review every diff before anything ships, so nothing gets pushed blind.
- Open pull requests in bulk, then track them: CI failures, stalled reviews, who’s blocking what, in one place instead of a hundred tabs.
That last one is the piece everyone underestimates. Generating 200 changes is a Tuesday. Getting 200 changes merged is the initiative.
Where Tidra came from
We built Tidra around that model, and it came out of a specific frustration.
You could tell an engineering org exactly which repos were out of compliance, what version they were on, and who owned them. Teams would look at the report, agree it was accurate, and then not act on it for two quarters. The visibility was never the blocker. The last mile was: the actual repo-by-repo work of making the change.
Tidra closes that gap. You describe the change, and it plans, generates, and coordinates the pull requests across hundreds of repos. Humans review every diff and merge like they would any other PR.
One platform team recently used it to close over 200 pull requests on a single initiative.
The takeaway
If your org is building toward a software factory, don’t just design the line that ships features. Design the line that keeps everything running. It’s the part of the job that never makes the demo, it’s the part that determines how fast the rest of the factory can run, and it’s exactly the part worth automating first.
Curious what a maintenance line looks like for your stack? Start free now.