Turn repeat tickets into fixes with proposed pull requests

How an engineering lead can use the agent's proposed code fixes to turn repeat bug reports into pull requests, while the team still reviews, tests and decides when to merge.

The third ticket this month says the same thing as the first two. A customer's export fails when a field is empty. Someone replies with a workaround, someone else makes a note to look at it, and the bug stays where it is.

Repeat tickets are usually a bug with no owner. The fix is often small. What's missing is the time to go from "we keep hearing about this" to a change somebody can review.

Cerberius Agents can help close that gap. When it investigates a ticket and finds a bug it knows how to fix, it can propose the code change. If you approve, it opens a pull request. Your team still reviews and merges it. This article walks through how that works and where it stops.

What a proposed fix is

Sometimes the agent finds a bug and knows how to fix it. It then adds a Proposed fix to its reply. A fix is a code change the agent proposes. Nothing changes until an approver clicks Approve fix → open a pull request.

You'll find it in the Queue. Open a reply that's Waiting for approval, and look for the Proposed fix section. Open the row to see the agent's findings and decide. The Queue lists these oldest first, with the subject, ticket number, when the draft was made and the agent's confidence.

So the reply to the customer and the proposed fix arrive together. You can check what the agent found about the cause before you decide whether the change is worth making.

What happens when you approve

After you approve, the sequence is:

  1. The ticket's status changes to Fix approved, in progress. The Queue shows Making the fix….
  2. The agent changes the code in one repository.
  3. The service puts the changes on a new branch, with a name starting with support-agent/, and opens a pull request on GitHub, or a merge request on GitLab.
  4. The agent drafts a follow-up reply telling the requester a fix is on its way.

The pull request description says which ticket it's for and who approved it. It also says that the agent didn't run or test the change. That last line is worth keeping in mind, because it's the honest summary of what you're getting.

The follow-up reply

The follow-up shows in the Queue as Follow-up after fix. You approve it separately, whenever you're ready. On it, a Pull request card links to the pull request. You can send the follow-up before or after you merge, so you can choose whether to tell the customer now or once the change is live.

Why your team still decides on the merge

The service never merges. Your team reviews the pull request and decides.

A few limits sit around that:

That last point matters if you worry about a change quietly altering how your pipeline behaves.

What it doesn't do

Be clear with your team about this, because it shapes how you treat these pull requests.

It doesn't run your tests. The agent hasn't run or tested its fix. Check the pull request carefully, and run your usual tests before you merge.

It doesn't deploy. Opening a pull request is where its part ends. Getting it merged and released is your normal process.

It doesn't make the call for you. An approval gets you a pull request, not a shipped fix. A reviewer should read it as they'd read a change from a new contractor: useful, but not trusted until checked.

A proposed fix is a head start on the work. It isn't a finished fix.

Turning repeat tickets into a routine

Here's one way an engineering lead might use this week to week.

Look for tickets with the same cause

When you work through the Queue, pay attention to replies that carry a Proposed fix. If you've seen the same symptom on earlier tickets, that's your signal that fixing the code will save more time than answering again. Tickets and their history are covered in Tickets and history.

Approve the fix, then review it properly

Approve the fix when the findings make sense. Then treat the pull request like any other. Read the diff. Ask whether it fixes the cause or just the symptom. Run your tests. If the change is wrong, close the pull request. Nothing has been merged.

Send the follow-up when it suits you

Tell the customer a fix is on its way, or wait until it's merged. Either is fine. Keep the wording honest. "We've found the cause and a fix is being reviewed" is accurate. "It's fixed" isn't, until you've merged and released it.

Close the ticket

Once the work is done, close the ticket. See Closing tickets.

Setting it up

Code fixes are off until an owner or admin switches them on under Settings › Changes. Beyond that:

For a first trial, one application repository is enough. Leave shared code and infrastructure read-only until you're comfortable with the pull requests you see.

Code changes are one of three kinds of change. The other two, database and Kubernetes changes, are separate, and a code fix doesn't need them. See Allowing changes.

A realistic expectation

Not every ticket will come with a proposed fix. The agent only adds one when it finds a bug and knows how to fix it. Plenty of tickets will be questions, configuration problems or things that need a human decision.

For the ones that do, the saving is real but modest: someone has already investigated, written up the cause and prepared a change. Your engineers spend their time reviewing rather than starting from a blank page. The judgement about whether the fix is right, and when it ships, stays with you.

To read more about the approval screen, see Approving a fix.

All articles

Loading…