Repo-Medic

Home Screen
Dependence Upgrade bottleneck
Configure Repo
All task and repair
Execution and stream log
Verification and result
Code Difference/patch
Artifacts

Inspiration

What it does## Inspiration

Dependency upgrades should make software more secure and maintainable, but they can also break working applications. A package update may remove an API, change a return value, or introduce a new validation rule. The developer is then left to reproduce the failure, investigate the change, edit application code, and prove that the existing tests still pass.

We wanted to explore whether an AI agent could help with that repair process while giving the developer evidence to review—not just a suggested code snippet.

What it does

RepoMedic helps investigate Python dependency-upgrade regressions.

A user provides a public GitHub repository, selects a branch, and configures the dependency upgrade, test command, expected failure, and permitted source paths. RepoMedic resolves the branch to a commit, runs the repair workflow, and presents the resulting patch and verification evidence.

The workflow is designed to:

Check the existing tests against the pinned baseline.
Upgrade the dependency and reproduce the failure.
Use an NVIDIA Nemotron model to propose a source-code patch.
Verify the candidate against the existing tests.
Present the patch, verification log, and machine-readable evidence for developer review.

RepoMedic is a prototype. It supports a bounded Python workflow; a successful result depends on the repository, environment, configuration, and quality of its tests. A passing test suite does not guarantee that a patch is correct in every situation.

How we built it

We built the interface with Next.js and TypeScript and deployed it on Vercel. The backend uses FastAPI on AWS Lambda, with AWS SAM for deployment and Amazon SQS for queued repair work. Turso stores tasks, run state, and evidence metadata.

For live repair generation, we use NVIDIA Nemotron through Nebius Token Factory. ConTree provides the container environment in which the repair workflow runs. The application records run progress and makes the patch, verification log, and evidence available for inspection.

Challenges we ran into

One challenge was distinguishing a real dependency regression from a failure that already existed before the upgrade. We designed the workflow around a pinned commit and baseline checks so the repair begins with a known starting point.

We also had to keep the developer’s tests meaningful during repair. RepoMedic restricts candidate changes to configured source paths and checks results against the existing tests.

Connecting the browser, API, queue worker, model provider, sandbox, and persistent storage introduced additional challenges around progress recovery, duplicate submissions, errors, and deployment differences. We tested these paths and preserved run artifacts to make results reviewable.

Running code from user-supplied repositories also requires stronger isolation and budget controls. This remains an important limitation of the current prototype.

Accomplishments that we're proud of

We connected the full repair workflow to a deployed interface and produced reviewable patches and evidence using NVIDIA Nemotron through Nebius Token Factory.

Our controlled demonstrations covered different dependency changes, including SQLAlchemy, Pydantic, Click, and PyJWT. In the reported PyJWT custom-form run, the application reproduced a failure after upgrading from version 1.7.1 to 2.8.0; the generated patch was then checked against three unchanged tests.

We are also proud that the result is inspectable: developers can review the proposed diff and download the verification log and evidence rather than relying only on a success message.

What we learned

An AI-generated patch is only a candidate. Reproducing the failure, keeping tests unchanged, pinning the source commit, and making the verification results visible are essential to helping a developer assess the result.

We also learned that a successful controlled demo is different from supporting arbitrary repositories on the public internet. Repository setup, network isolation, provider limits, and test quality all affect what can be safely and reliably supported.

What's next for RepoMedic

Our next priority is to strengthen isolation and resource controls for user-submitted repositories, then test the complete form-to-repair workflow on a wider variety of previously unregistered public projects.

We also want to improve repository setup guidance, failure diagnostics, and the review experience. Longer term, we would like to explore integrations with existing dependency-update workflows and richer support for project environments.