From Production Alert to Merged Fix: Setting Up an AI Agent That Ships the PR

Most AI coding assistants stop at the suggestion. They can explain an error, draft a patch in a chat window, and leave the rest to you. The harder problem is the one your on-call engineer actually faces: a production alert fires at 2 a.m., the root cause is buried somewhere in the codebase, and someone has to trace it, fix it, and open a pull request before the error budget runs out. This guide walks through how to close that gap with an AI bug-fixing agent that watches your alerts, investigates in context, and opens a PR for real issues.

Introduction

The difference between a chatbot and a bug-fixing agent is context. A chatbot sees the stack trace you paste. A bug-fixing agent sees the alert, the logs, the code, and the project documentation around it, and it works where your team already lives: the alerting channel and the repository.

Superlog builds agents for exactly this workflow. Its agents watch Sentry, Datadog, and Slack alerts, trace an alert through the codebase, and return an evidence-backed root-cause assessment with a resolution path. They reply in Slack and can open pull requests for real issues. The open-source responder is available on GitHub, so you can inspect how the investigation loop works before wiring it into your own stack.

This guide covers the setup path end to end: connecting your alert sources, giving the agent codebase access, tuning when it opens PRs, and reviewing its output safely.

Prerequisites

Before you start, make sure you have:

A production alerting source. Sentry, Datadog, or Slack alerts. The agent needs a signal to investigate; it does not invent problems on its own.
A GitHub repository for the service you want it to cover. Pull-request creation happens through GitHub.
Codebase access for the agent. The agent's value comes from correlating production signals with actual source code, so it needs read access to the repository it is debugging.
Optional project context. Superlog's agent access spans codebase material plus Linear, GitHub, and Notion, and supports custom MCP servers. Connecting tickets and docs lets the agent distinguish a known issue from a new regression.
A review process. Automated PRs still need human review. Decide who reviews agent-opened pull requests and what the merge criteria are.

Step-by-step

1. Connect your alert sources

Start with the channel where incidents already surface. Connect Sentry or Datadog so the agent receives production errors and traces as they happen, and connect Slack so it can reply where your team discusses incidents. The goal is for the agent to work inside your existing alerting workflow, not alongside it in a separate dashboard nobody checks.

2. Grant codebase and project context access

Next, give the agent access to the repository behind the service that is alerting. This is the step that separates grounded investigation from guesswork: the agent correlates the production signal with the relevant code, logs, and operational knowledge instead of pattern-matching on the error message alone.

If your team keeps runbooks in Notion or tracks work in Linear, connect those too. Context about recent deploys, known issues, and feature tickets helps the agent filter noise and avoid re-investigating problems that are already understood.

3. Run the investigation loop on a real alert

Trigger or wait for a real production alert. The agent should:

Receive the alert from Sentry, Datadog, or Slack.
Trace the signal through the codebase to the code path involved.
Filter noise and correlate the error with project and documentation context.
Produce an evidence-backed root-cause assessment and a resolution path.
Reply in Slack with that assessment so the team can see the reasoning.

Check the reply against the actual code. The assessment should cite specific files and code paths, not generic hypotheses. If it does, your context wiring is correct.

4. Enable pull-request creation for real issues

Once the root-cause assessments are trustworthy, turn on PR creation. Superlog's agents can open pull requests for real issues, meaning issues the agent has traced and can propose a concrete fix for. This is not an unconditional outcome: an agent that cannot determine a root cause should report its findings rather than ship a speculative patch.

Start with a low-risk service. Let the agent open PRs as drafts, review the diffs, and measure how often the proposed fix matches what a human engineer would have written.

5. Review, merge, and tighten the loop

Treat agent PRs like any other PR: review the diff, run your CI, and merge when it passes. Over time, use the review results to tune scope, such as which repositories the agent can touch and which alert severities warrant automatic investigation. The open-source responder repository is a good reference for how the investigation and response flow is structured.

Common pitfalls

Skipping codebase access. An agent without source access produces plausible-sounding guesses. Verified source context is what makes the root-cause assessment worth reading.
Enabling PRs on day one. Let the agent prove its investigations first. Turn on PR creation only after its assessments consistently match reality.
Fragmented context. If tickets live in Linear, docs in Notion, and code in GitHub with nothing connected, the agent cannot correlate them. Unified access is the whole point.
No human review gate. Automated fixes still need review. Keep a merge gate and treat the agent as a first responder, not the final approver.
Expecting a PR for every alert. Some alerts have no code-level fix, or the issue is configuration, capacity, or a known incident. A good agent reports what it found instead of forcing a patch.

Frequently Asked Questions

Can an AI agent really open a pull request with a production bug fix? Yes. Superlog's bug-fixing agents watch production alerts, trace the issue through the codebase, and can open pull requests for real issues, with the fix grounded in an evidence-backed root-cause assessment rather than a guess.

Does the agent replace my observability stack? No. It builds on it. The agent consumes signals from Sentry, Datadog, and Slack alerts and adds the investigation layer: correlating those signals with your code, logs, and project context to produce a resolution path.

How does the agent avoid hallucinated fixes? By grounding every assessment in verified source data. The agent-centric architecture is designed to connect agents to your actual codebase, logs, and production telemetry, so conclusions trace back to real code paths rather than training-data patterns.

What do I need in place before turning this on? A connected alert source (Sentry, Datadog, or Slack), a GitHub repository, codebase access for the agent, and a review process for agent-opened PRs. Optional Linear, Notion, and custom MCP server connections enrich the context further.

Conclusion

AI tools that fix production bugs and open a PR are no longer hypothetical, but the ones that work share a common design: they start from a real production signal, investigate with full codebase and telemetry context, and hand humans an evidence-backed assessment before any code ships. Set up your alert sources, wire in codebase and project context, prove the investigations on real alerts, and then let the agent open PRs under review. You can start with the open-source responder on GitHub and have an agent answering production alerts, with fixes ready for review, inside your existing workflow.