Inspiration
Debugging often becomes a repetitive trial-and-error process: read the test failure, find the relevant code, make a change, run the tests again, and repeat.
We wanted to build a developer tool that could automate this loop while keeping verification at the center. Instead of simply asking an AI model to generate code, DebugForge is designed to diagnose a failure, generate a targeted repair, safely apply it, and verify the result through tests.
What it does
DebugForge is an autonomous debugging and code repair agent.
When a test fails, DebugForge:
- Runs the project's test command.
- Parses the test failure and identifies the failing test.
- Localizes the failure to the relevant source function and file.
- Collects focused source context.
- Sends the debugging context to NVIDIA Nemotron through Nebius Token Factory.
- Receives a structured repair containing the diagnosis, target file, original code, and replacement code.
- Validates and applies the patch in an isolated workspace.
- Reruns the tests to verify the repair.
If a repair does not pass verification, the agent can continue with another repair attempt.
For our demo, DebugForge repairs a Python project where the add() function incorrectly performs subtraction. It identifies the bug, generates the correct patch, applies it, and verifies the fix by rerunning the test.
How we built it
DebugForge is built in Python as a modular debugging pipeline.
The core workflow connects test execution, failure parsing, source localization, AI-based diagnosis and repair, patch validation, patch application, and test verification.
We use NVIDIA Nemotron-3.5-Lightning through Nebius Token Factory to generate structured repair proposals. The model receives focused failure information and relevant source context rather than the entire repository.
The repair is represented as structured data so that DebugForge can validate the target file, verify that the expected original code exists, apply the change safely, and then run the tests again.
The project uses pytest for test execution and verification.
Challenges we ran into
One of the main challenges was making the AI-generated repair reliable enough to be applied automatically.
A generated answer is not necessarily a valid patch, so DebugForge needed validation before modifying the project. We also had to make sure that the repair targeted the correct file and source code instead of making unrelated changes.
Another challenge was designing the debugging context. Sending too much repository code can make the repair process less focused, while sending too little can prevent the model from understanding the bug. We therefore built source localization and focused context extraction into the workflow.
Accomplishments that we're proud of
We built a complete end-to-end debugging loop rather than only an AI code-generation interface.
DebugForge can go from:
test failure → failure analysis → source localization → AI repair → patch validation → patch application → test verification
The repair is not considered successful just because the model generated code. It must pass the project's tests.
We are also proud that the system uses NVIDIA Nemotron through Nebius Token Factory as an actual part of the repair pipeline.
What we learned
We learned that building an agentic developer tool requires more than connecting an LLM to a prompt.
The surrounding engineering is equally important: failure parsing, source localization, structured outputs, patch validation, isolated changes, retries, and automated verification.
We also learned that giving an AI coding agent focused and relevant context is important for producing reliable repairs.
What's next for DebugForge
We want to extend DebugForge beyond simple Python test failures.
Future improvements include supporting more programming languages and test frameworks, improving source localization for larger repositories, handling more complex multi-file bugs, adding stronger patch validation,
Log in or sign up for Devpost to join the conversation.