RepoMedic: An AI Debugging Assistant That Runs Locally 🔧

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

Every developer has experienced the frustration of a project that suddenly stops building. Dependency conflicts, TypeScript errors, broken configurations, and ESLint failures can consume hours that could have been spent building something useful.

RepoMedic aims to make that process faster.

Instead of simply explaining an error, RepoMedic follows a structured repair workflow:

The goal is to move beyond an AI chatbot that suggests code and toward a tool that can provide evidence that a proposed fix actually works.

RepoMedic is designed for freelance developers, independent programmers, students, and small development teams who regularly troubleshoot existing projects.

For freelancers maintaining multiple client repositories, reducing repetitive debugging work can save valuable time.

My long-term plan is to explore a free local version alongside paid features for advanced repair workflows and developer teams.

The current project is being developed as a local application. It requires the appropriate backend dependencies, MySQL, and a compatible Qwen model running through Ollama.

GitHub repository: https://github.com/Uncooperativecase225/repomedic

The project uses a modular architecture with separate frontend, backend, AI integration, repository analysis, and repair components.

The repository includes setup documentation and instructions for running the application locally.

I chose a stack that combines familiar web technologies with local AI inference.

The React frontend communicates with the Spring Boot backend through REST APIs.

When a developer starts a scan, the backend inspects the selected repository and collects diagnostic information from the available development tools.

Relevant error messages and source context are then sent to Qwen 3.5 9B through Ollama.

The model generates a diagnosis and proposes a repair. The backend validates the proposed changes and can apply them in an isolated Git worktree before running the relevant checks.

MySQL stores repository metadata, scan history, diagnostics, repair proposals, and validation results.

The developer can then review the proposed changes and decide whether to apply them to the original repository.

An important architectural decision is that the AI model does not determine whether a repair succeeded. The actual build, lint, and test results provide that evidence.

I wanted RepoMedic to make local AI useful for a real development problem rather than use an open-weight model as a thin wrapper around a chatbot.

Repositories can contain proprietary source code, client business logic, internal APIs, and configuration details. Sending all of that information to an external AI service may be undesirable for some developers and organizations.

By using Qwen 3.5 9B through Ollama, RepoMedic can perform its AI inference locally, provided the model and its dependencies are installed on the user's machine.

Repository context can remain on the developer's machine rather than being sent to a third-party model API. Local inference does not eliminate every security risk, but it reduces the need to transmit source code externally.

The AI layer can be designed to support alternative compatible models. Developers can experiment with different models and quantizations without rebuilding the entire application.

3. Reduced dependence on per-request API charges

Once the local runtime and model are installed, inference does not require paying a separate hosted-model API fee for each request. Hardware, electricity, and maintenance still have costs.

I can evaluate different prompts, context-selection strategies, and model configurations against the same diagnostic cases.

For example, I want to compare how different local models handle dependency conflicts, TypeScript errors, and broken build configurations.

RepoMedic combines AI reasoning with conventional development tools. The model proposes a solution, while Git, compilers, linters, and test commands help verify it.

This is where I believe open innovation is especially valuable: developers can inspect the workflow, choose their model, and adapt the system to their own development environment.

RepoMedic started with a simple observation: developers often spend too much time understanding and fixing routine project failures.

AI can help explain those failures, but an explanation is not the same as a working repair.

My goal is to build a tool that connects local AI reasoning with real development tools and verifiable results.

Using an open-weight model makes it possible to explore that workflow while retaining greater control over source code, model selection, and inference costs.

The next step is to evaluate RepoMedic against a repeatable set of broken repositories and measure how often its proposed repairs actually pass validation.

Build locally. Diagnose intelligently. Verify every repair.