A production bug comes back to the team as a ready fix, not a ticket

Who the client was and what was getting in the way

This is our own product, built for ourselves and used every day. It came from a simple observation: many production incidents are not interesting problems. They are small things. An external service changes its response format, a website we collect data from changes its layout, or an edge case stops matching the code’s assumptions. The fix takes a dozen minutes, but before getting to it, someone has to read the report, reproduce the issue, find the relevant code, and recover the context. Those dozen minutes turn into an hour, and several hours like that add up each week.

The obvious idea — let a model write the fix — has one serious flaw. A model can write a fix and tailor a test to it that passes even though the original bug has not been fixed. It is marking its own work. We needed evidence independent of the person or agent that wrote the code.

The second issue was safety. Not every change can go live without a person. A fix affecting payments or permissions is in a different risk category from adapting to a changed data format. Third, not every incident can be fixed in code. Some are caused by external-service blocks or expired access. The agent needed to recognize these and stay quiet rather than create tickets no one could resolve.

What we built

We built a loop where one independent agent makes the fix, another verifies it, and a rule — not a model — decides whether the change can go live.

Everything starts with an event. The application where something broke sends a signal with a diagnosis and an error fingerprint, so the same incident does not start the process ten times. The loop is packaged as a reusable component in GitHub Actions, so connecting another project takes a few lines of configuration rather than a separate implementation.

The first agent, powered by Claude Code, starts by writing a test that reproduces the bug and only then makes the smallest possible fix. The order matters: first prove the problem exists, then solve it. The result is an ordinary change proposal, just like one a person would open.

A second agent runs separately and does not know how the first one reasoned. It checks one thing: whether the test fails on the old code and passes on the new code. That is the objective evidence missing when the author of a fix is also its reviewer.

At the end is a gate that is not an agent. It is a straightforward rule: if the change is low risk, the full test suite passes, and independent verification is documented, the fix goes in automatically. Otherwise, it waits for a person. A dashboard for those cases and the history of the whole loop are stored in Supabase.

How it works today

The loop is part of our daily process. When something breaks, the team does not get a ticket to investigate; it gets a ready change proposal and a test proving that the problem existed and has been fixed.

Small, recurring failures disappear without anyone getting involved. In the morning, the team can simply see that something broke yesterday and was fixed. Changes marked as sensitive wait in the dashboard for a person’s decision, and that is the only part that needs manual attention. Incidents that cannot be fixed in code are recognized and set aside instead of clogging the queue.

The outcome

Two independent agents handle each fix: one writes it, the other verifies it. Low-risk fixes go in automatically; risky ones wait for a person. Every change has hard evidence in the form of a test that failed before the fix and passes afterward.

What we would do differently

The first version had one agent write and review its own fix. It looked great until we started checking exactly what had been fixed. Splitting the roles into two independent runs was the only change that truly solved the problem of fabricated successes, and it should have been part of the design from day one.

We also underestimated how many reports involve problems that cannot be fixed in code: expired access, external-service blocks, and outages in systems owned by others. Before we added detection for these cases, the loop generated noise that made people stop looking at the results. Cause classification should come before the repair agent, not after it.