Can an AI agent fix production bugs by itself?
For a bug with a clear stack trace, code it can read and a test it can run, yes, up to a pull request. An agent can read the error, find the cause, write the fix and open the pull request with nobody watching. It fails when the cause is outside the code, and it should not decide what ships.
What the agent needs
| It needs | Why | Without it |
|---|---|---|
| The error: type, message, stack trace, request, breadcrumbs | Points it at a file and line, and shows what led there | It guesses from the code |
| The code, ideally at the failing release | The stack trace has to match what it reads | Line numbers point at the wrong code |
| A way to reproduce: tests, or the app running locally | Proves it understood the bug before it changes anything | A fix nobody has seen pass |
| Limited write access: a branch and a draft pull request | Lets it finish the work with no path to production | Either it stops at advice, or it holds too much |
| A signal after the deploy | Shows whether the error stopped | The fix is assumed to have worked |
Where it tends to work
The good cases are exceptions with a stack trace into your own code and one failing path: reading a property of undefined, an API that changed shape, an unhandled promise rejection, a validation that rejects a value you meant to allow. The evidence is in the error, and the fix can be proven with a test. The error fixes library lists many of these.
Where it fails
- The cause is outside the repository: a missing environment variable, an expired credential, a provider outage, a full disk. It can read the symptom but cannot see or change the cause, and it may patch the code anyway.
- The cause is in the data: bad rows or a half-run migration. A code change can hide it, and the repair still needs someone with database access.
- It cannot reproduce it: races, load, or state that only exists in production. Without a failing test, the fix is a theory.
- The stack trace does not help: a stack through bundled code, or an error with no in-app frames.
- There is no error at all: a wrong total, a swallowed exception, a silent no-op. No error tracker reports what never threw.
- It treats the symptom: a try/catch or a null check makes the error stop while the bug stays. The count falls and the behavior is still wrong.
- The right behavior is a product decision: retry or give up, block or warn. The code cannot tell it what you want.
Asking for a failing test before any code change catches the symptom patch and most misunderstandings, because the test has to fail for the stated reason first.
How much to leave to it
| Level | The agent does | You do |
|---|---|---|
| Report | Reads new errors and explains each against the code (daily digest) | Decide what to fix |
| Draft | Writes a failing test and the fix, and opens a draft pull request (GitHub Action) | Review and merge |
| Close | Marks the error resolved with the commit hash after the fix ships | Watch for it reopening |
Merging and deploying are the steps to keep. An agent that can do both can also ship a wrong fix to every user with nobody looking, and the next error report may be the first sign.
What Runheed changes, and what it does not
Runheed covers the first and last rows of the first table. Your app reports exceptions through the SDK, and the agent reads them over MCP, so nobody has to notice the error, find it and paste it in. A resolved error that happens again reopens on its own, which is the signal after the deploy.
It does not make the agent a better debugger, and it cannot deploy or reach your servers. The failures above still apply, and browser-only errors are not captured because there is no browser SDK yet.
Questions
- Does the agent need access to my production servers?
- No, not for bugs in your code. It needs the error data and the repository. Access to servers or the production database is a separate decision, and most code fixes do not depend on it.
- Should I let an agent merge its own fixes?
- Keep a person on merge and deploy for anything users depend on. A draft pull request gives you the finished work and leaves the decision with you.
- How do I know the fix worked?
- The failing test now passes, and the error stops arriving. In Runheed, an error marked resolved goes back to unresolved if the same error happens again.
- Which agents can do this?
- Any agent that can use MCP and edit your repository, including Claude Code, Cursor and Codex. Each client has a setup page under Connect your agent.