
1
1
India
2+ years of experience
Full-stack developer and technology entrepreneur focused on building practical AI-powered and SaaS products. I work across web application development, backend systems, cloud technologies, automation, and product architecture. I enjoy turning real-world problems into scalable software solutions and am currently building my own technology venture, Infovion. For this hackathon, I’m focused on building TriageRace with IBM Bob 2.0 and looking to collaborate with strong builders who are passionate about AI agents, software engineering, testing, and product innovation.

The Problem When a bug comes in, developers spend the majority of their time on investigation — reading logs, forming hypotheses, tracing code paths — not on typing the one-line fix. For a typical boundary or logic bug, a skilled engineer takes 3–5 minutes just to locate the problem, before writing a single character of fix. At scale, across hundreds of bugs per month, this investigation cost dominates engineering time. The Solution: TriageRace TriageRace compresses the investigation phase to seconds by running all plausible root-cause hypotheses in parallel, with the real test suite as the sole arbiter of truth. Here is the exact flow: 1. A developer pastes a bug report (a support ticket, log excerpt, or CI failure) into the Intake view. 2. Four IBM Bob subagents — each assigned a different debugging lens (boundary logic, numeric precision, input validation, order of operations) — independently read the bug report and the source code, then each proposes a root cause and a minimal patch. 3. TriageRace copies the repository four times, applies each patch to its own isolated copy, and runs the real failing pytest test in all four copies concurrently. 4. The hypothesis whose patch makes the test pass first is declared the winner. A green glow and WINNER ribbon appear on its card in real time. 5. One click applies the winning patch to a fresh copy and runs the full test suite. The result view shows the verified diff, full pytest output, and a measured before/after time comparison. What Makes It Unique The race format eliminates the single-agent anchoring problem — one AI asked to find a bug will commit to its first hypothesis. Four independent agents with constrained lenses explore the search space in parallel, and the test suite — not the AI's confidence score — decides who is right. This is objective, auditable, and honest. Every number shown in the UI is real: test results come from actual pytest subprocess runs, timings are wall-clock measurements, and null values display as "—" with "not measured yet" rather than invented figures. Target Users Engineering teams at software companies, especially those running CI/CD pipelines where failing tests block releases. The immediate value is in reducing mean-time-to-resolution for production bugs. Measured Result On the demo scenario (a boundary comparison bug in a Python pricing module), manual debugging took 4 minutes. TriageRace with IBM Bob subagents resolved it in 2 minutes and 2 seconds — a 2× improvement on a simple bug. On complex bugs in large codebases where investigation typically takes 1–2 hours, the same architecture delivers 10–20× gains because the human bottleneck is investigation, not typing. Tech Stack Python 3.11 + FastAPI backend, React + Vite + Tailwind frontend, SQLite for run state, pytest subprocesses for test execution, HTTP polling for live updates, Docker for single-image deployment on Render.
27 Sep 2026