Public Site (Tryit)
Red2Fix Success
Red2Fix Failed

Inspiration

red2fix started with my own frustration as a student developer. I struggled with GitHub merge conflicts, push errors, and figuring out why something that worked locally failed somewhere else. Debugging often meant reading unfamiliar logs, searching for answers, and trying changes without knowing whether they actually solved the problem.

That experience led me to a question: How can I give developers clearer evidence that a code change fixes a bug?

What it does

red2fix is a developer tool centered on a simple idea: run a test that fails before a change and passes after it.

The name reflects that process—moving from red, a failing test, toward a verified fix. This gives developers a concrete way to check whether a change addresses the behavior being tested. It does not prove that the entire application is bug-free, but it provides evidence they can inspect and reproduce.

How We built it

We built the project around a red-to-green verification workflow, bringing together AI-assisted debugging with executable tests. Along the way, I worked with the NVIDIA Nemotron API and learned how to use GitHub Actions for automated checks.

The guiding principle was to connect AI reasoning with observable results: a suggested explanation or change becomes more useful when developers can test it.

Challenges We ran into

One of the biggest challenges was understanding the different reasons a development workflow can fail. A Git problem, an environment issue, and an application bug can produce very different debugging tasks.

Another challenge was thinking carefully about verification. A passing test is only useful when it checks the relevant behavior, and a failing test needs to fail for the right reason.

What We learned

We learned how to work with GitHub Actions, integrate the Nemotron API, and approach debugging more systematically. we also gained a better understanding of regression testing and why reproducing a problem matters before attempting to fix it.

Our biggest takeaway was that confidence in a fix should come from evidence.

What's next for red2fix

we want to improve failure explanations, support more project setups, and make verification results easier to understand—especially for developers who are still learning, like us.