There’s a moment every developer knows. You’re three hours into a bug. You have a partial stack trace, a screenshot of an error you can barely read, some copied terminal output, and a vague sense that something in your config is lying to you.
So you open your AI tool of choice, paste everything in, and ask: “What’s wrong?”
And it tells you what’s wrong. Confidently. Sometimes correctly. Sometimes not.
The problem isn’t the answer. The problem is the framing. When you ask “what’s wrong,” you’re asking for a conclusion. What you actually need — especially on the bugs that matter — is an investigation.
What most AI debugging tools skip
Generic AI tools are good at pattern matching. Give them a known error, they’ll give you a known fix. That works maybe 60% of the time. The other 40% — the race conditions, the environment-specific failures, the dependency mismatches that only reproduce in staging — that’s where you need something different.
You need to know: what’s the prime suspect, and what’s the supporting evidence? What looks suspicious but is probably a false lead? What evidence are you missing that would raise your confidence? What’s the quickest safe fix versus the clean long-term fix?
These are the questions a good senior engineer asks. They’re also the questions most AI tools never bother with — because they’re optimised to give you an answer, not to help you think.
That’s the gap I decided to build into something.
What I built: BugTheatre AI
BugTheatre AI treats every bug as a case file, not a query.
You bring in whatever evidence you have — a title, a description, a stack trace, logs, a code snippet, a screenshot — and instead of a generic “here’s your fix,” you get a structured investigation. Think of it as the output a sharp senior engineer would produce before touching the keyboard:
- Prime suspect — the most likely root cause, with confidence and severity
- Supporting evidence — what in your input supports that conclusion
- False leads — what looks suspicious but probably isn’t the real issue
- Missing evidence — what you’d need to raise your confidence
- Fix plan — both the quickest safe patch and the proper clean fix
- Validation steps — how to confirm the fix actually worked
- Postmortem — a workplace-ready incident summary, ready to share
The UI is organised around these artifacts. There’s a Dashboard, an Investigation Board, a Patch Room, and a Postmortem view. It’s not a chatbot. It’s a workflow.
Why local Gemma, and why it matters
Everything runs locally. Inference goes through Ollama, using a local Gemma 4 model — no cloud API, no data leaving your machine.
This is more than a privacy preference. You shouldn’t have to think twice before pasting a stack trace that contains an internal service name, a database URL, or an environment variable. Local inference removes that friction entirely. There’s also a quieter shift happening here that’s worth naming: more engineering teams are moving toward “bring your own model” tooling — not just for privacy, but for consistency and reproducibility across environments. BugTheatre is built with that direction in mind.
Before any model call, the app scans and redacts secrets — API keys, bearer tokens, database URLs, private keys. But the real point is that local-first architecture means you never have to audit your own paste before hitting enter.
Gemma 4 handles both text evidence and screenshot analysis. Upload a terminal failure or a browser console error, and the model reads it visually — useful when you’re starting with nothing but a screenshot and a sinking feeling.
The architecture in brief
The prompt asks Gemma for a strict JSON case object covering every investigation artifact. The UI renders each field into its corresponding view. Cases are saved locally and accessible from the Dashboard. Exports are clean Markdown or JSON — ready to drop into a Jira ticket, a Slack thread, or a postmortem doc.
Current stack is Python and Streamlit — fast for a local POC, honest about its limitations. The intended next architecture is React/Next.js frontend, FastAPI backend, SQLite persistence, same local Gemma core.
What this is and what it isn’t
This is a POC, submitted to the Google Gemma 4 Challenge on DEV.to. It works, it runs, and the investigation output is genuinely useful. But it’s not production software — no auth, no multi-user support, no robust JSON retry loop, no GitHub or Jira integration yet.
What it is: proof that the framing of an AI debugging tool matters as much as the model underneath. The same evidence, restructured as a case file instead of a chat prompt, produces a meaningfully different — and more actionable — result.
The bigger point
We’ve spent the last two years asking AI to give us answers faster. That’s useful. But for the problems that actually slow teams down — the bugs that take days, the incidents that need postmortems, the failures that only show up under load — speed of answer isn’t the bottleneck.
Clarity of investigation is.
Linus Torvalds once said: given enough eyeballs, all bugs are shallow. BugTheatre AI is an attempt to give you better eyeballs — not just a faster guess.
BugTheatre AI is open source: github.com/AkshatUniyal/bugtheatre-ai
Submitted to the Google Gemma 4 Challenge on DEV.to
