Jon CursiAsk any engineering leader to name the work their team should be doing but isn't, and you'll get the same list.
The flaky test suite everyone has learned to rerun. The dependency upgrades that keep slipping. The docs nobody trusts. The dead code, the deprecated patterns, the migration that has been ninety percent done since last year.
None of it is urgent. All of it is important. And it never gets staffed, because every sprint has a feature, a fix, or a deadline that beats it.
That backlog is exactly where internal AI agents earn their keep. Not as a chatbot that explains your repo. As a managed worker that owns the maintenance lanes your team keeps deferring.
Maintenance sets your speed limit
Maintenance has a branding problem. It sounds like chores. In practice, it decides how expensive every future project will be.
A codebase with good tests, current dependencies, and accurate docs lets new features ship fast. A brittle one means every project starts with archaeology: figuring out what's safe to touch, why a test fails, whether the docs are lying.
Most teams already know this. The problem is sustained ownership. Nobody can consistently spend hours on it.
Why it never gets staffed
The engineers who could safely do this work are your most senior people. They know the history and the dangerous corners, so messy work finds them by default. But they're also the people product, support, and leadership need for everything else. Their maintenance hours get borrowed first and returned never.
The usual alternatives don't fit either. A new hire needs onboarding and management before they can touch anything risky. A contractor needs narrow scope and close oversight. A coding assistant makes one developer faster at whatever they're already doing, which by definition isn't the deferred work.
The gap is ownership. Someone has to be responsible for the lane, week after week, whether or not anyone remembers to ask.
What an internal AI agent actually owns
Good agent workstreams have a specific boundary, a recurring trigger, and work that can ship. Platform maintenance has a few obvious places to start.
Test coverage and regression cleanup. The agent finds untested components and flows, adds coverage around stable behavior, fixes brittle tests that no longer match the product, and runs checks before opening a pull request. Your engineers still review everything. They just start from a concrete PR with passing checks instead of a blank backlog item.
Dependency and migration work. Upgrades sound simple until they touch your build, types, lint rules, and deployment path. An agent works through them in batches, handles the mechanical fixes, documents exceptions, and escalates judgment calls to a human. The value is that your team stops carrying silent risk because nobody owned the update path.
Documentation that tracks the code. Docs fail when they're a one-time project. An agent treats them as maintenance: READMEs updated when code changes, runbooks aligned with what the system actually does, repeated onboarding questions turned into setup notes.
Notice what all three have in common. Clear boundaries, human review, and output you can count.
What this looks like in practice
In the first month of a mid-size deployment, a TaskAdmin internal AI software engineer at NextraData merged 69 pull requests, resolved 42 issues, and touched 278,000+ lines of code with a net 59,000 lines removed.
It authored 57% of all merged team PRs that month, modernized testing to 100% component coverage, and built a self-QA workflow to visually verify changes before opening PRs.
The number I care about most is the negative one. Net 59,000 lines removed means the agent wasn't just generating code into the repo. It was doing the surrounding work that makes code safe to merge: tests, cleanup, QA, verification. That's the difference between a managed agent and a coding toy.
Why managed matters here
Self-serve AI tools are useful and your engineers should use them. But they amplify whoever is at the keyboard, and platform maintenance fails precisely because nobody is at the keyboard for it.
A maintenance lane needs assigned work, repo context, defined boundaries, repeatable QA, a human review path, and someone accountable for improving the agent over time. That's the model TaskAdmin runs. We build, manage, monitor, and improve the agent around the work instead of handing over a tool and hoping. The How It Works page covers the setup in more detail.
Picking the first lane
Don't start with the riskiest corner of the codebase. Start where the work is bounded and easy to review:
- Increase component test coverage in one package
- Fix bugs tagged
maintenanceorpapercut - Clean up deprecated UI patterns across a defined set of pages
- Prepare dependency update PRs under human review
- Reduce flaky tests in one suite
- Keep docs current whenever specific shared utilities change
Avoid goals like "modernize the app" or "improve velocity." They can't be scoped, measured, or reviewed. A bounded lane gives the agent a real job and gives you a clean way to judge the output.
Then judge it the way you'd judge any engineer: merged PRs, resolved issues, coverage numbers, and whether your senior people are spending fewer hours untangling the same problems.
The three-month test
The honest measure of engineering AI is whether the codebase is healthier a quarter later. Better tests. Fewer old issues. Docs closer to reality. Senior engineers building instead of excavating.
If your maintenance backlog has been flat or growing for a year, more awareness won't fix it. Ownership will. Book a live demo and bring your worst maintenance lane. We'll walk through where an agent could start opening useful PRs in the first few weeks.