Jon CursiEvery engineering team I talk to has the same list. They just call it different things.
The flaky tests everyone works around. The dependency upgrade that means a week of build errors, so it waits. The component that should have been retired two quarters ago. Docs that disagree with the code. Dead code nobody has the nerve to delete. Tickets labeled "cleanup" that have quietly become permanent furniture in the backlog.
None of it is urgent. All of it is expensive. And every sprint, it loses to whatever product is asking for this week.
This post is about a different way to attack that list: assign it to an AI software engineer whose entire job is to clear it.
Why the maintenance list never shrinks
The maintenance list keeps growing because engineering time gets allocated somewhere else.
Your best engineers are fully booked on roadmap work, and that is the right call. Nobody is going to pull a senior engineer off a revenue feature to delete dead code for three weeks. So the maintenance work sits, and the cost shows up sideways:
- Pull requests take longer because reviewers wade through complexity that has nothing to do with the change
- The same categories of bugs keep coming back because patterns are inconsistent
- Engineers avoid whole sections of the codebase because nobody trusts them
- New hires ramp slowly because the docs and the code tell different stories
Every feature you ship pays this tax. The tax grows every quarter you defer the work.
Most engineering leaders already know exactly what needs to happen in their repo. They do not need an AI strategy deck. They need someone to pick up a defined slice of work, make the changes, test them, open the PR, respond to review, and keep doing it week after week.
The copilot trap
The obvious answer is "we already have coding assistants." Fair. They are useful. But they solve a different problem.
A copilot makes an engineer faster at the task they are already doing. It still needs a human to choose the work, gather context, check the output, run the tests, and drive the PR through review. That is great for the product work your team is already prioritizing.
It does nothing for the maintenance backlog, because the backlog exists precisely because nobody has time to start it. Faster autocomplete does not create a new person.
An Internal AI agent working as a managed software engineer is a different thing. You do not ask it for code snippets. You assign it a workstream: modernize the test suite, remove deprecated code paths, fix visual regressions, resolve stale issues, keep documentation aligned with the product. Then it executes inside a managed process with repo access, review rules, QA expectations, and a human owner keeping it pointed at work that matters.
The distinction is ownership. A tool helps someone do the work. An agent does the work.
What one month of this looks like
At NextraData, TaskAdmin deployed an Internal AI software engineer into a mid-size business codebase. In the first month, the agent:
- Merged 69 PRs and resolved 42 issues
- Touched over 278,000 lines of code
- Removed a net 59,000 lines
- Authored 57% of all merged team PRs
- Brought testing to 100% component coverage
- Built a self-QA workflow to visually verify changes before opening PRs
The number worth staring at is the net 59,000 lines removed. Nobody protects sprint time for deletion. But shrinking surface area, killing stale code, and consolidating patterns is exactly what makes the next month of engineering faster. That kind of work compounds, which is why it hurts so much when it never happens.
All of this ran through real review with real constraints. Human engineers approved every merge. That is the point, not a caveat.
How to pick the first workstream
Do not hand the agent something glamorous. Hand it something boring, specific, and reviewable.
A good first workstream looks like this:
- The team already understands the work and can describe done
- Output lands as pull requests a human can review
- Tests, screenshots, or acceptance criteria confirm quality
- The work repeats across the codebase, so the agent gets better at it over time
- It has been postponed for months because roadmap work keeps winning
Concretely: raising component test coverage, closing old UI defect tickets, standardizing error states, removing deprecated paths, improving developer scripts, or cleaning up design system usage. Maintenance work is the ideal entry point because it has clear boundaries and gives the agent room to learn your repo without betting the business on a rewrite in week one.
What has to be true first
This is not a fit for every team, and pretending otherwise wastes everyone's time. Skip it if:
- Your repo has no reliable way to run and review changes. Without CI and review, AI output is a liability, not capacity.
- Nobody on the team can review code. The agent produces PRs. Someone has to judge them.
- The work is undefined. If no one can describe what success looks like, no engineer, human or AI, can deliver it.
- You want zero management. The agent removes execution load, not leadership. Someone still sets priorities and decides what matters.
That last point is where the management layer earns its keep. Someone has to define the workstream, load the agent with repo and business context, set guardrails on what it can touch, and decide how QA and review work. That is why TaskAdmin runs this as a managed service rather than a tool you hand your team and hope. Unmanaged AI code creates work. Managed AI engineering finishes it. If you are weighing that trade, the managed agents vs. self-serve tools breakdown goes deeper.
The question worth asking
"Can AI write code?" is a settled question and not a useful one.
The useful question: what engineering work would move every single week if someone were assigned to it and nothing else?
If your answer is test coverage, code cleanup, stale issues, internal tooling, or documentation that has drifted for a year, you already know the backlog is real and the drag is expensive. The missing piece is not a better tool for your existing engineers. It is execution capacity that owns the work they cannot get to.
If you want to see whether an AI software engineer fits your codebase, book a live demo. We will start with your actual maintenance list, not a pitch, and tell you honestly whether an agent should own it.