FixBugs is now live on the GitHub Marketplace!

why I built FixBugs

I built FixBugs because of a pattern I kept seeing in oncall rotations at Google and VMware.

When an API starts returning HTTP 500s, the question is not whether IF the team will fix the bug.

The question is, when?

As a developer, the hard part about alert investigations is stopping everything else, reading the alert,finding the right logs, deciding which service is actually at fault, figuring out the bug, and proving a hypothesis strongly enough that the fix is not just a plausible diff.

The same thing happens during PR review for a bug fix.

The author has a theory. The diff looks reasonable.

But without a reproduction, you are still mostly judging whether the theory sounds right.

That is the part I wanted to automate.

The FixBugs GitHub App is now available on GitHub Marketplace. Install it on a repository, comment solve-bug on an issue or apply the solve-bug label, and FixBugs starts the loop: triage, hypothesize, reproduce, fix, validate.

why GitHub

The obvious answer is that maintainers need help.

Useful repositories collect more issues than maintainers can reasonably process. Some projects are maintained by one person in spare time. Some are effectively unmaintained but still solve real problems for real teams. Users still hit bugs in them. Teams still need docs clarified, dependencies updated, and PRs reviewed.

The GitHub App is not meant to merge random patches into those repos. It is meant to make useful engineering work easier to start and easier to review.

A user can bring a real issue. A maintainer can get a hypothesis, a proposed fix, and evidence. The human still decides what ships.

what you can ask it to do

Install it on a repo. Start from an issue. Ask for the engineering work you would normally hand to a developer:

• Find the likely cause of this bug.
• Explain why this issue is happening.
• Generate a proposed fix.
• Open a PR from the latest fix.
• Explore this specific hypothesis.
• Write a reproduction test case.
• Validate whether this PR fixes the issue.
• Regenerate the fix with maintainer guidance.
• Turn this documentation request into a concrete docs patch.

The current public commands are:

• solve-bug - analyze the issue and generate a proposed fix.
• solve-bug-again - rerun with your additional guidance.
• solve-bug-pr - create a pull request from the latest fix.
• solve-bug-repro - generate a reproduction test case.
• solve-bug-validate <PR link> - check whether a PR actually fixes the bug.

That list is deliberately not limited to writing code.

Real repositories have contributor guides, weird test scripts, style rules, AGENTS.md, CLAUDE.md, and maintainer preferences that only look excessive if you have never maintained the project. FixBugs reads those files and treats them as instructions for how the fix should look.

You can also use the same workflow on a PR you wrote yourself, or a PR generated by another coding agent.

FixBugs does not care who wrote the patch. It cares whether the patch fixes the bug.

validation is the missing step

The interesting question is not:

"Can an agent generate a fix for this bug?"

The interesting question is:

"How do we know this is the right fix?"

For a real bug, I want three pieces of evidence:

1. The original failure can be reproduced.
2. The proposed fix removes that failure.
3. The change does not modify unrelated behavior.

That is why validation is built into FixBugs.

It can create a reproduction, generate a fix for a selected hypothesis, run the reproduction against the broken code, run it again against the fixed code, and attach the result to the issue or PR.

A reproduction test is not just a unit test with a better name.

Sometimes it is a unit test. Those are nice days.

Often it is not. You need the bad input shape, the surprising config, the dependency failure, the sequence of calls, the tenant-specific state, or the environment that made the bug real.

This is where FixBugs differs from a normal coding agent. Coding agents are useful once the task is already shaped. FixBugs tries to shape the task, test the hypothesis, and leave an evidence trail.

fire and forget

GitHub is a good place for this because GitHub is already async.

You should not need to babysit a chat window to debug a repo issue. Create the issue, add solve-bug, walk away, and come back to hypotheses, code, validation output, or a PR.

The free trial covers 3 bug fixes per month. Paid plans include more capacity and unlimited interactions on every bug covered by the plan.

That matters because debugging is rarely one-shot. The first hypothesis may be wrong. The first reproduction may be too narrow. A maintainer may ask for a smaller diff. CI may reveal a platform-specific failure.

The right product shape is not "one prompt, one answer."

It is an async thread that can keep working until the issue is in a reviewable state.

That also means non-developers can start useful work. A product manager, support engineer, QA engineer, or power user can file a good issue and ask FixBugs to investigate. A developer can then review the resulting evidence and PR instead of starting from a blank page.

the app is the doorway

The honest version: the GitHub App is not the whole product.

The deeper workflow lives in the FixBugs VS Code extension: richer local repo state, interactive triage, handoff, collaboration, and debugging sessions you can revisit.

But the GitHub App is the easiest place to try the core idea because the issue is already there.

We are not claiming every bug can be fixed automatically. Some bugs need product judgment. Some need access to production data the app should not see. Some need a human to decide that the correct fix is "do not support this behavior."

But for many repository bugs, the useful first step is mechanical and expensive: read the issue, inspect the code, form a hypothesis, write a reproduction, try a fix, review the diff, and leave a clear trail.

That is the part we are trying to automate.

data we need

FixBugs needs enough repository context to do the work.

It reads code, issues, pull requests, comments, commits, repository metadata, and the files needed for the workflow. It writes issue comments and pull requests when asked.

It does not need to permanently store your repository.

We collect the minimal GitHub repository data needed to run the workflow and keep it only as long as necessary to complete that run, support review, and satisfy account and security requirements. Complete repository contents are not stored as a product database.

try it on a real bug

The best test is not a toy issue.

Pick something real:

• A bug report you have been avoiding.
• An old issue with enough detail to reproduce.
• A PR from another agent that looks plausible but unproven.
• A docs request that deserves a patch instead of another comment.

We are launching the GitHub App as the public front door because it makes the core idea easy to inspect.

Not "AI writes code."

AI investigates a bug, reproduces it, generates a fix, validates it, and auto-reviews the result.

That is the part I want to put in front of other builders and see where it breaks.