Can an AI Agent Maintain Your Software After Launch?

The software conversation happens almost entirely before launch. 

You scope the build, agree on a price, set a date, and everyone works toward getting it out the door. 

The year after launch gets a fraction of that attention, and it is the year your product either holds up or gets worse.

Maintenance has traditionally meant waiting for somebody to report a bug and assigning a developer to it. 

AI agents can now do part of that job directly, watching a live system and repairing some of what they find. An agent can handle real maintenance work when it can see how the software behaves in production and a developer reviews what it changes. 

Without both of those, it is working from the code alone and has no way to tell a defect from a design decision.

‍

Why don't users report software bugs?

Reporting a bug takes effort, and the person who hit it has somewhere else to be. 

They refreshed the page, it worked the second time, and they got on with their day.

That leaves your bug tracker holding the problems somebody was annoyed enough to write up, which is a much shorter list than the problems in your software. 

The ones that go unreported have a pattern:

• A customer abandons a form after an error and finishes by phone instead
• A background job fails and recovers, leaving data delayed rather than wrong
• A server connection drops for a few minutes during off hours
• One user role hits a broken state that nobody with a different role can reproduce
• A code anomaly creates inconsistent behavior without breaking anything outright
• A missing test lets an old bug come back unnoticed

None of that reaches you through support, which is why teams usually find these while investigating something bigger.

‍

What context does an AI agent need to fix code?

An agent needs much more than the code. 

A codebase records what somebody intended to build, and everything about how the software actually behaves lives somewhere else:

• Logs show what happened when real people used it
• Anomaly detection shows where behavior drifted from its own baseline
• Server health and connectivity show whether the product is stable underneath
• Security signals show where risk is accumulating in dependencies
• Test coverage shows which paths nobody is checking
• Pull requests create a reviewable handoff back to a person

Google's CodeMender, announced last October, upstreamed 72 security fixes in six months into projects as large as 4.5 million lines. It gets there on static analysis, fuzzing, differential testing, SMT solvers, a debugger, and a critique step that checks whether the patched code still does the same thing. 

Nearly all of that stack exists to give the model something reliable to work from and to check what it produced afterward.

‍

Why do AI-generated fixes still need a developer to review them?

AI-generated fixes need a reviewer because agents do well on narrow, contained work and lose the thread on anything sprawling. A January study of 33,707 AI-authored pull requests across 2,807 repositories found a split result: 28.3% merged immediately, which is real automation working on well-scoped changes. The ones that entered back-and-forth review went differently, with agents abandoning the work rather than iterating on feedback. The strongest predictor of abandonment was an unplanned change that touched several components at once.

An agent can own a narrow fix with a clear signal behind it, and anything touching several components at once should route to a developer before a line changes.

Google reached the same conclusion with far more resources behind it, and every patch CodeMender generates gets reviewed by a human before it goes upstream. That is a reasonable floor for whatever agent ends up working on your product.

‍

What should a maintenance agent never change on its own?

A maintenance agent should leave alone anything where the current behavior might be deliberate. An error in the logs looks the same whether it is a defect or a business rule doing its job, and an agent that makes the error disappear can take the rule with it.

Before an agent touches maintenance work, somebody has to write down:

• Which workflows are critical enough that changes wait for a person
• Which odd behaviors are intentional
• Which tests protect the core paths
• Which user roles a change is allowed to affect
• Which categories always become a pull request instead of a direct fix
• Which findings are product conversations rather than bugs

Some of what an agent surfaces is a design problem wearing a bug report. Routing that to a developer to patch is how a company automates around a decision it should have reopened.

‍

Why should an AI agent open a pull request?

A pull request turns the agent's work into something a person can actually inspect. It shows what changed, which files were touched, what tests moved, and which signal set the whole thing off, and it does that before anything reaches production.

We build audit trails into the tools we deliver for the same reason. An agent that fixes things without leaving a record asks your team to trust output they cannot check, and we believe that business is built on transparency and trust, and that good software is built the same way.

‍

How does an automated maintenance agent work in practice?

Tinker is our answer to the category of problem that never reaches your tracker. It runs daily, integrates directly with the codebase, watches logs, identifies anomalies, and fixes issues on its own. When a fix needs judgment, it opens a pull request. When it cannot resolve something directly, it builds a workaround. Every fix gets reviewed by one of our developers before it reaches production.

It monitors four things:

• Bugs and code anomalies
• Server health and connectivity
• Security vulnerabilities
• Test coverage gaps

A test coverage gap is a place where the team has no way of knowing whether the next change broke something. Those gaps widen every time a feature changes without its tests changing with it, and nobody notices until a regression comes back.

Tinker comes with every project we take on, because a product that launched well can still weaken over the following year as dependencies age, usage patterns shift, and integrations get less reliable.

The part clients notice first is the change in how problems reach them. A customer email describing something odd gets replaced by a pull request naming what happened, what changed, and which signal caught it.

‍

What should you ask a firm about maintenance before you sign?

Ask these six while you still have leverage in the conversation:

1. What happens after launch, specifically? A warranty period, a support arrangement, and what each one covers.
2. What is watching the product when nobody is looking at it? Logs, anomalies, uptime, and security all tell you different things.
3. What gets fixed automatically, and what waits for a person? There should be a line, and somebody should be able to describe it.
4. Who reviews a fix before it reaches production? Name the role.
5. How will I see what was found and changed? A record you can read without asking for it.
6. What happens when something breaks six weeks after launch? Get the answer in writing while the contract is still being negotiated.

‍

How do you know if your software is getting worse?

Software gets worse on its own without maintenance, so the thing to check is whether anything in your process pushes the other direction between releases. Dependencies age, integrations drift, and usage patterns move away from what the product was designed around.

Ask your team how they currently find out about problems nobody reported. If the honest answer is that they do not, you have found the gap where an agent with real context and a review path would earn its keep.