🤓 Latest Submissions
DebugSignal — Evidence-Triggered Voice Debugging
Debugging often starts with a developer thinking aloud: “I think the database might be the problem.” The challenge is that useful evidence may already exist inside the codebase, but manually searching commits and diffs interrupts the developer’s flow. DebugSignal is a voice debugging agent designed around a simple idea: weak evidence should stay silent, while strong evidence should earn an interruption. The developer speaks naturally while debugging. AssemblyAI Voice Agent handles the real-time voice interaction and can trigger an investigation when useful debugging context is detected. DebugSignal then searches the repository’s Git history, inspects relevant commit diffs, evaluates the evidence, and applies an interruption policy. For example, when a developer suspects a database issue, DebugSignal may find no strong supporting evidence and remain silent. When the developer later says that payment started timing out, the system can discover a relevant commit where PAYMENT_TIMEOUT changed from 30 seconds to 5 seconds. Because the repository provides strong corroborating evidence, DebugSignal interrupts and presents the commit and code change. The key innovation is not simply adding voice to debugging. It is giving the agent a reason to decide when NOT to speak. DebugSignal combines AssemblyAI Voice Agent, real-time audio processing, Git investigation, evidence scoring, and an interruption policy into one focused developer workflow. Weak evidence → Silence. Strong evidence → Evidence-backed interruption.
30 Sep 2026
WhyBroke — Regression Investigation AI
Problem When a test that previously passed suddenly fails, developers often have to manually investigate Git history, run tests against previous commits, inspect diffs, identify the first bad commit, and determine how the changed code affected the failing test. This process can require repeated context switching and does not always make the causal relationship obvious. Solution WhyBroke is a regression investigation tool designed to turn this manual investigation into a structured workflow. The user provides a local Git repository and a failing test. WhyBroke first verifies that the test currently fails, analyzes the repository's commit history, and uses Git bisection to identify the boundary between the last known good commit and the first bad commit. It then analyzes the code difference between those commits and investigates the relationship between the failing test and the changed code. The final report combines the Git history, test results, code diff, test-to-code relationship, confidence level, and suggested next step into a single evidence-backed regression report. For example, in our demonstration regression, WhyBroke identified commit 65c0f4c as the first bad commit. The investigation showed that formatOrder() changed from returning a formatted string to returning an object, while the existing test still expected the previous behavior. Target Users WhyBroke is intended for software developers, engineering teams, and anyone maintaining Git-based applications who needs to investigate regressions quickly. How Users Interact With It Users provide the repository and failing test through the WhyBroke interface and start an investigation. The system performs the investigation automatically and presents the progression from test failure to Git history, first bad commit, code change, evidence, root cause, and suggested fix. What Makes It Different WhyBroke does not stop at identifying a failing test or displaying a Git diff. Its workflow connects the failing test, Git history, first bad commit, changed code, and test-to-code relationship into one investigation. The core idea is: Git tells you WHAT changed. WhyBroke tells you WHY it broke.
27 Sep 2026
