Show HN: FixBugs – Reproduce production bugs and verify fixes

▲ Show HN: FixBugs – Reproduce production bugs and verify fixes(fixbugs.ai)

29 points by kirtivr 11 hours ago | 28 comments

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.

GitHub App: https://fixbugs.ai/go/github-app

  - we do access your code temporarily.
  - pick a repo to install FixBugs on.

What motivated me to build FixBugs were my years being on-call at Google and VMware. How many hours did I spend gathering logs, traces, reviewing metrics, and reading code only to find that,

* 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.

Do try it and let me know what you think!

I'd especially love feedback from engineers who work with distributed systems or handle high-volume production bug triage.

▲ Rishi1238 6 hours ago | parent | next [-]

Interesting project. How does it handle services with multiple dependencies (queues, caches, third-party APIs)? Can it recreate enough of the production environment to reproduce intermittent bugs?

	▲	kirtivr 5 hours ago \| parent [-]
		We either mock or fake out the interfaces. 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.

▲ kumari_b 5 hours ago | parent | prev | next [-]

Interesting approach. The investigaion phase is usually the most time-consuming part of debugging. Curious how well this works on large, distributed systems.

▲

kirtivr 4 hours ago | parent [-]

Nginx, Caddy, Flink and Firefox are some applications where we we've managed to consistently fix and reproduce reported bugs.

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.

	▲	kumari_b 4 hours ago \| parent [-]
		Thanks for the clarification. Those are some interesting projects to benchmark against.

▲ majestic8 7 hours ago | parent | prev | next [-]

This looks very useful! What type of sandbox are you using? How does the mocking work?

	▲	kirtivr 6 hours ago \| parent \| next [-]
		On Linux, we rely on a chroot-ed workspace at this time - although we are working on a prototype using the new landlock kernel interface (https://github.com/Zouuup/landrun). 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.
	▲	kirtivr 5 hours ago \| parent \| prev [-]
		On how does the mocking work, that's a really interesting question. 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.

▲ kirtivr 10 hours ago | parent | prev | next [-]

A different approach that we took to root causing bugs that you may find interesting is that we first try to reproduce the bug before coming up with a fix for it.

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.

▲ vasmiReddy 7 hours ago | parent | prev | next [-]

Nice idea! The reproduce → verify loop is what makes this stand out.

	▲	kirtivr 4 hours ago \| parent [-]
		Thank you! are you using any AI tools to debug productions bugs at this time?

▲ sriramkalluri3 9 hours ago | parent | prev | next [-]

Great tool to triage the reported issues in bugs and fix them swiftly. This will definitely improves your productivity.

▲

kirtivr 9 hours ago | parent [-]

Thank you so much.

are you using any AI tools to debug productions issues at this time?

	▲	gnabgib 7 hours ago \| parent [-]
		Your bots are failing: https://news.ycombinator.com/item?id=48901182 https://news.ycombinator.com/item?id=48901202

▲ Bheemaneni 7 hours ago | parent | prev | next [-]

This seems especially used for teams handling production incidents.

	▲	kirtivr 6 hours ago \| parent [-]
		It's really nice to hear that. 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.

▲ raghu16 9 hours ago | parent | prev | next [-]

Also, How is the VSCode extension reproducing the bug on my machine? That sounds dangerous.

	▲	kirtivr 9 hours ago \| parent [-]
		Oh the repro runs in an isolated sandbox, and all interactions outside the sandbox (with lets say other services or databases) are mocked. The repro harness doesn't have access outside of it. This also allows us to inject various types of faults, which is helpful with debugging more complex systems.

▲ Hemashrie 3 hours ago | parent | prev | next [-]

Really like the reproduce-first approach.

▲ rKulaSekhar 7 hours ago | parent | prev | next [-]

Love the focus on verification instead of just generating fixes.

▲ divvsaxena 7 hours ago | parent | prev | next [-]

Awesome man cool!

▲ mundanevoice 10 hours ago | parent | prev | next [-]

It seems like a cool idea.

	▲	kirtivr 9 hours ago \| parent [-]
		Thanks a lot! 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.

▲ ShaikMohammad 7 hours ago | parent | prev | next [-]

Very cool.Reproducing production bugs is usually the hardest part.

	▲	kirtivr 5 hours ago \| parent [-]
		War story time? xD

▲ sriramkalluri3 9 hours ago | parent | prev | next [-]

Great tool to triage and fix the issues in bug. Improves your productivity massively.

▲ yizluo 9 hours ago | parent | prev [-]

very nice tool! helpful and I love it

	▲	kirtivr 9 hours ago \| parent [-]
		Thank you so much. are you using any AI tools to debug productions issues at this time?