Debugging production errors with an AI coding agent

What an agent can't see on its own

An agent works from what's in front of it: your repository, your terminal, and whatever you paste in. Production errors happen somewhere else, on your servers and in your users' browsers and phones, and most of them never reach anything the agent can read.

Pointing it at your logs helps less than it sounds. Plenty of errors are never logged at all:

• An exception in a browser or a mobile app happens on the user's device. Unless something on the device catches it and sends it somewhere, there's no record of it anywhere you control.
• A log line usually has the message and maybe a stack trace, without the release that was running, the request, or what led up to it.
• Logs don't count. "This failed 4,000 times for 31 users since Tuesday's deploy" means grouping thousands of lines into one problem, and an agent doing that from raw logs spends most of its context on it, every time you ask.
• An agent only works when someone asks. A spike at 3am is noticed by whatever is watching, not by an agent waiting for a prompt.

So the agent is the part that fixes, and something else has to be the part that catches. The better that something records each error, the less the agent has to guess.

What it needs to reproduce an error

Reproducing the error in a failing test is what turns a plausible guess into a fix you can trust, and it's the step an agent most often skips when it doesn't have enough to go on. For one occurrence, give it:

• The full stack trace, with frames from your own code marked, since that's usually where the fix goes
• The release or commit that was running, so it reads the code as it was, not as it is now
• The request: method, route and parameters, with personal data already removed
• The breadcrumbs: the queries, requests and log lines in the seconds before it failed
• The failing SQL statement, if a query raised
• How often it happens, since when, and to how many users, so it can tell a new bug from an old one and judge how urgent it is
• What changed around the time it started: deploys, migrations, feature flags

One good event is worth more than twenty partial ones. Ask for the most recent occurrence in full rather than a summary of many.

Give it narrow access

The quickest way to give an agent production data is to give it a production credential: a database URL, a log shipping key, an SSH login. Don't. It can read far more than errors, and whatever it reads goes into its context and to its model provider.

Give it access to the errors only, through a credential you can see and revoke on its own. Start it read-only; reading is all it needs to reproduce and fix. If you want it to resolve or comment on issues as well, make that a separate, deliberate grant.

And remove personal data before it's ever stored, not when the agent reads it. Emails, tokens and card numbers scrubbed when an error arrives can't end up in a prompt later.

A prompt that works

Ask for one error at a time, and for the steps in order, so the agent reproduces before it fixes and you review before anything ships:

Prompt

Look at the unresolved issues in the checkout project and pick the one with the most events.
Get its most recent event in full: stack trace, breadcrumbs, request and SQL.
If it led an incident, check what changed around then and which change is the likely cause.

Then, in this repository:
1. Check out the release that event came from and find the failing code.
2. Write a test that fails the same way. Stop and tell me if you can't reproduce it.
3. Fix it on a new branch, run the whole test suite, and open a pull request for me to review.
4. Comment on the issue with a link to the pull request.

Step 2 is the one that matters. If the agent can't reproduce the error, the event is missing something, and the honest answer is to say so rather than ship a fix for a bug it hasn't seen.

Connecting it over MCP

MCP (Model Context Protocol) is how coding agents and AI apps call tools outside themselves. An error tracker with an MCP server gives an agent the errors directly, as tools it can call, with no credential pasted into a config file. ForgeOps runs one at https://getforgeops.net/api/v1/mcp. When a client first connects, it registers itself and sends you to a consent screen in your browser, where an organization owner chooses read-only or read-and-act.

In Claude Code, add the server (-s user makes it available in every project, not only the folder you run this in), then run /mcp inside Claude Code and choose to authenticate:

Shell, Claude Code

claude mcp add -s user -t http forgeops https://getforgeops.net/api/v1/mcp

JSON, .cursor/mcp.json (Cursor)

{
  "mcpServers": {
    "forgeops": {
      "url": "https://getforgeops.net/api/v1/mcp"
    }
  }
}

JSON, .vscode/mcp.json (VS Code)

{
  "servers": {
    "forgeops": {
      "type": "http",
      "url": "https://getforgeops.net/api/v1/mcp"
    }
  }
}

On Claude.ai, add it as a custom connector under Settings, Connectors, with the same URL. Any other client that supports remote MCP servers with OAuth connects the same way.

See it on a real incident

Two deploys, and the wrong one looked guilty
Two deploys minutes apart, part of the telemetry missing, and the most recent deploy isn't the one that did it.