Agentic bug management: a ranked list a team can burn down.
AI agents scanned more than a dozen repositories, from backend services to front-end clients, for data-consistency problems, failure risks, security issues, and code smells. They logged what they found as prioritized Jira tickets, attempted a fix for each issue and opened a pull request for review, and gave the team a shared, ranked dashboard that linked every bug to its pull request.
About this project. I built the working system at Fanatics, where Claude agents, guided by a custom set of code-evaluation skills, scanned real repositories. Its findings and code are confidential, so the live demo is a simulation: fictional repositories and made-up findings that replay the same workflow. The ranking rule in the demo is illustrative.
- Project
- Agentic bug management: agents that scan repositories, rank what they find, and file the tickets
- Built with
- Claude agents guided by a custom set of code-evaluation skills, with Jira and a shared dashboard
- Scope
- More than a dozen repositories, from backend services to front-end clients
- Fixes
- The agent attempts a fix and opens a pull request; the ranked list links each bug to it for review
- First pass
- More than 150 bugs logged, from fatal to trivial
- What it found
- Mostly data-consistency issues and potential null-pointer failures that could have reached clients
- Cadence
- One sprint each quarter to burn the list down
- Data
- Simulated: fictional repositories, no code scanned
Defects that reach clients, and no shared list.
Defects that can reach clients, such as inconsistent data and code paths that fail on a missing value, are easy to miss in review and easy to defer when nobody owns a list of them. A team with many repositories needs one ranked view of what could hurt clients, a place for the work to live, and time set aside to do it.
From a scan to a sprint.
- ScanAgents read every repository
- ClassifyConsistency, failure, security, or smell
- RankFatal down to trivial
- Log to JiraOne ticket per finding
- Fix and open a PRThe agent attempts the fix
- Review and burn downOne sprint a quarter
The agents evaluate the code using a custom set of skills that describe what a problem looks like, so every repository is judged by the same standard. Each finding becomes a Jira ticket, and a shared dashboard ranks them, so the team always knows what to work on first.
Finding a bug is only half the work, so the agent also attempted the fix and posted a pull request. The bug list linked to that pull request, which made it easy for an engineer to review a proposed change straight from the list.
More than 150 bugs on the first pass.
The first pass logged more than 150 bugs, ranging from fatal to trivial. Most were data-consistency issues and code that could fail on a missing value, which are the kinds of defect that can reach a client. The team then spent one sprint each quarter burning the list down, which brought the repositories into production shape and kept them there. Because each bug linked to the agent’s pull request, reviewing a proposed fix was one click away.
Try the workflow yourself.
The live demo is a standalone app that scans twelve fictional repositories and produces 156 simulated findings in the same mix the real scans surfaced most. It then shows the agent opening a simulated pull request for each fix it can make. You can filter by severity, category, repository, and status, open a finding to see the code, the reasoning, the pull request, and the ticket that would be logged, and then run a review-and-burn-down sprint.
Five choices that made it useful.
One ranked list, not a pile.
More than 150 findings is a report nobody acts on. Ranking turns it into a queue, so a team can start at the top and know that the most important work is being done first.
Every finding arrives with a proposed fix.
The agent attempted the fix and opened a pull request, and the list linked to it. An engineer’s job became reviewing a proposed change, not diagnosing the problem and writing the fix from nothing.
Tickets go where the team already works.
Findings are logged in Jira, so they enter the normal planning flow instead of sitting in a separate document that has to be remembered.
Time is set aside to do the work.
A list only shrinks if someone has capacity for it. Giving the burn-down one sprint each quarter made the work a planned commitment, not something squeezed in between features.
Standards are written down as skills.
A custom set of evaluation skills captures what counts as a problem, so the agents apply the same judgment to every repository, and the standard can be improved in one place.
Agents that find, describe, and propose. Engineers who review.
Claude agents did the scanning and evaluating, guided by the skills that encode how to judge code. They wrote each finding up clearly, logged it, attempted a fix, and posted a pull request that the list linked to. The engineers on the team reviewed those pull requests and decided what shipped.