Show HN: FixBugs – Reproduce production bugs and verify fixes
I built FixBugs, an agent that ingests the rich context surrounding production bugs to reproduce them in a sandbox and generate verified fixes. It's available in the form of a self-hosted VSCode extension and as a Github app:
VSCode Extension: https://fixbugs.ai/go/vscode-extension
- full code and data privacy.
- zero data retention models opted out of training.
- we do access your code temporarily.
- pick a repo to install FixBugs on.
* Some context was missing.
* The bug wasn't reproducible.
* The alert was caused by a transient infrastructure issue.
Too many. Inefficiency in investigating staging/production bugs has a real cost, and it's paid both by developers and customers.
Current capabilities:
- Reproduce the bug.
- Identify the root cause.
- Generate a fix.
- Verify the fix.
- Review the generated code using multiple AI models to help catch potential regressions.
I'd especially love feedback from engineers who work with distributed systems or handle high-volume production bug triage.
(
39 comments
| 6 points
| on HN
)
I think FixBugs is most useful during high volume bug triage. This is where having a low false-positive async debugging agent is most helpful.
This is essentially a (RCA <-> Repro test case) loop until we're recreated the bug. If our attempts are not converging and we’re on the wrong track, we ask for human input.
are you using any AI tools to debug productions issues at this time?
This also allows us to inject various types of faults, which is helpful with debugging more complex systems.
are you using any AI tools to debug productions issues at this time?
https://news.ycombinator.com/item?id=48901182
https://news.ycombinator.com/item?id=48901202
OSX is the best, we use the in-built (seatbelt) sandbox via sandbox-exec.
For Windows, we use WSL containers when available.
By default, if a safe sandbox environment is not available, we inform the user that a repro is not possible in the current conditions.
We do a lot of AST parsing - for both code and build configuration languages. Even then, we still have to rely on the LLM to figure out a lot of the details.
Making this work reliably for non-frontier models and codebases that don't have existing test harnesses is where a lot of the design work goes in.
are you using any AI tools to debug productions bugs at this time?
FixBugs was built because while investigating prod incidents, I had an epiphany.
SWEs build tools to solve all types of problems, but we ourselves use the flakiest tools.
While working at Google for example I was surprised GDB support for any type of binary debugging was almost non-existent.
I much prefer faking to mocking, because that still preserves a lot of the real-world behavior relevant to prod bugs.
A full prod reproduction would be a holy grail, but probably only attainable for complex distributed systems if we have access to a prebuilt staging-like environment.
We're traversing the bridge between mocks, fakes and staging at this time.
Of course, we did not send the PRs to the repos seeing how they're already overloaded with them.
Nginx for example has 181 open PRs right now, but they only merge 2 or 3 in a day.
are you using any AI tools to debug productions issues at this time?
Would love to have you join our Discord- https://discord.gg/XNXVD34P8
And we will have to build better tools if we want to accelerate shipping velocity.
We'd love to have you join our Discord: https://discord.gg/XNXVD34P8
- Copilot may be better at implementing features. We're better at investigating bugs and fixing them.
- We handle huge context very easily. We specialize towards investigating large amounts of logs/metrics and traces.
- We do a lot of work to generate a non-trivial reproduction test case in a sandbox, which allows us to verify bug fixes. Ship confidently, not just based on the best available hypothesis.
- You can apply and remove code changes with the click of a button. We have an in-built VCS that allows you to add or remove sets of changes from a long coding session.
- Our pricing model is different. While with the standard Copilot developer plan you get $10 of AI usage (nothing if you're using Claude or GPT), we allow you unlimited triages on a fixed number of bugs. It's not about AI credits, it's about investigating and fixing complex bugs.
Though, i wonder if it could also be an integration to alerting platforms directly (like NewRelic, Datadog etc.), so that for on-call alerts, it could cover the foundation work, and have some hypotheses ready for the on-call engineer to directly jump into
At this time we are focussing on evaluation benchmarks like SWE-bench (verified). This is a simpler benchmark and does not really map well to investigating alerts that have a huge amount of context. But its a start.
I am wondering if we can improve upon foundation models with our reproduction <-> hypothesis loop approach.
Foundation models tend to be precision first, and context limited, so they can get sidetracked by various things.
This is an interesting problem to be working on right now!