Egor Urvanov

Short bug feedback loopFrom a “Report a bug” button to a fix with an AI agent

How to fix bugs faster with no game of telephone: staff report from the app, context is collected for them, an AI agent finds the cause, a human approves.

created · updated · 7 min · · Harness

A short feedback loop works like this: an employee sends a bug with a button inside the app, the app attaches technical context itself, an AI agent finds the cause and proposes a plan, and a human approves the plan and the fix. No manager or ticket retells the bug. Below: where time goes, two modes, risks.

Where time is lost

A bug usually travels a long way from the person who saw it to the person who fixes it. The top chain shows the usual path: employee, manager, ticket, clarifications, reproduction. The bottom chain shows the short loop: a button in the app, a report with context, an agent, human approval, release. The bars below show how often reports are incomplete: 92% of Android bugs have no reproduction steps, about 70% of GitHub reports are incomplete, and only 37–44% of bugs get passed on.

The usual path
The short loop
Share of bugs and reports
No steps (Android)92%
Incomplete (GitHub)~70%
Passed on37–44%
Takeaway
In this exampleEvery retelling drops what the developer needs most: the steps, the expected result, the state of the screen.
In generalDevelopers need reproduction steps and the error stack most, and users find those hardest to give. An incomplete report takes 201 minutes to reproduce versus 120.
Next stepCount how many hands a bug passes through, from the person who saw it to the person who fixes it.

A button instead of retelling

The person gives only what a machine cannot know: what they wanted and what they saw. The app records the rest by itself.

Screenshot with a frameThe person circles the spot, and the frames are burned into the image
Three questionsWhat you did, what you expected, what happened; the first is prefilled from the latest clicks
VoiceSay it aloud, and the transcript is added to the right step
ActionsClicks, navigation, input without values
Requests and errorsThe latest server requests with responses, console errors, server state
Personal data hiddenNames, contacts and messages in text are masked, keys are cut out
Takeaway
In this exampleDescribing the bug takes seconds: answers are picked with one tap.
In generalThe report is written for an agent that can read any amount of technical detail, so all of it is collected at once.
Next stepPut the button where people see the problem, in place of a separate tracker.

Agent and human

The agent does the analysis, the human makes the decisions. The agent takes each report separately, investigates it and brings back a write-up: what is visible, the likely cause with the place in the code, a plan and risks. It changes no code and no statuses. The human approves the plan. Then the agent makes the fix in a separate branch, and the human merges the change and releases it. The boxed phrase is a ready-made request to the agent.

  1. 1
    Agent takes a report
    each report goes to its own agent, with no shared guesses
  2. 2
    Investigates and reports
    what is visible, the likely cause with the place in the code, a plan, risks, questions; touches no code and no statuses
  3. 3
    Human approves the plan
    or asks questions
  4. 4
    Fix
    branch, checks, merge request
  5. 5
    Human merges and releases
    the agent replays the report’s scenario to the end before saying “fixed”

Tell the agent

Take the open bug reports, analyse each with a separate agent and come back with a summary report. Change nothing until I approve.
Takeaway
In this exampleThe tracker hands the working rules to the agent itself on connection, so every session behaves the same way.
In generalAgents give the speed, and decisions stay with the human at two points: the plan and the merge.
Next stepWrite the order “investigate → report → wait for approval” where the agent will read it without you.

Two modes: on a button or automatic

There are two modes. On a button, the developer starts the agent with one command, the agent finds the cause and a plan, and the human approves. In automatic mode, the system starts an agent on every report, and it writes the fix right away. The table compares the modes by speed and cost.

On a buttonAutomatic
Who starts itthe developer, with one commandthe system, as soon as a report arrives
What the agent doesfinds the cause and a planwrites the fix right away
Developer’s roleapproves the plan, checks the changechecks the finished change
Speedminutes to a reportthe change is ready when the human arrives
Costthe agent works only on the reports that matterthe agent is spent on every report, including duplicates and non-bugs
Takeaway
In this exampleAbnormal AI makes both modes labels on a task: the first asks the agent to find the cause, the second to write the fix.
In generalIt is cheaper to start with the on-a-button mode: the developer filters out noise before the agent starts writing code.
Next stepTurn on automatic mode when the flow of reports is clean and duplicates are rare.

Cases and numbers

Numbers from company practice show the scale of the effect: at Wix the time went from weeks to hours, and at Ramp with Jam a report takes seconds instead of 15–20 minutes. The line under the table refers to the author’s own example: of 25 reports in the built-in tracker, 23 are closed.

WhoWhat they didBefore → after
Wixagents collect context, write and check the fix, a human approvesweeks → hours
Salesforcea model analyses customer bugs~300 person-days → under a week
Metaviewan agent analyses incidents, a human checks30–45 min → ~5 min
LaunchDarklyagents find bugs and open fixes~40% of unique bugs reached a fix
Ramp + Jama report with a screenshot and automatic context collection15–20 min → seconds per report
23 of 25reports closed in the built-in tracker of a working app
Takeaway
In this exampleAll the cases share one move: context is collected before a human sits down with the bug.
In generalShorter time to fix (MTTR in DORA metrics) comes from collecting context and a short chain of people.
Next stepMeasure the time from report to release now, so you have something to compare with.

Risks

The agent reads text written by people, so the method has its own risks: fake reports, personal data in screenshots, green tests with a broken feature, and blurred responsibility. The four cards below name each risk and how to remove it.

Fake reportPeople write the report text; the agent reads it as data, never as commands
Personal dataText is masked, the screenshot goes as is, and a dialog warns about it
Green tests, broken featureThe check is a replay of the report’s exact scenario on the same kind of data
Blurred responsibilityA human approves the plan and merges; silence does not count as consent
Takeaway
In this exampleAn agent with write access and text from users is a channel for deception through text.
In generalFor more on keeping data from turning into commands, see the article on data plane and control plane.
Next stepGive the agent a separate key: read-only for analysis, write only after approval.

How to start

Start with measuring: first measure the bug’s path, then add the button, then give the agent read access and the rule “report first, approval second”. Add write access and automatic mode later.

  1. 1
    Measure the bug’s path
    how many people and days from “saw it” to “fixed”
  2. 2
    Add the button
    screenshot, three questions, automatic collection of actions and errors
  3. 3
    Give the agent read access
    and the rule: report first, approval second
Takeaway
In this exampleThree steps with no automatic mode and no write access.
In generalFirst a short chain of people, then the agent’s speed.
Next stepStart with one app and ten reports.
Numbers come from bug report studies (Zimmermann et al.; arxiv 2203.12093, 2301.01235; Jeong et al.) and engineering blogs of Wix, Salesforce, Metaview, LaunchDarkly, Abnormal AI and Jam. The example is the built-in bug tracker of a working app, October 2026.

Same terms

© 2026 Egor Urvanov