RepoMedic: An AI Debugging Assistant That Runs Locally 🔧

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

What I Built
RepoMedic is a local-first AI debugging and code repair assistant designed to help developers diagnose and fix broken JavaScript and TypeScript projects.

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:

Scan: Inspect a local repository and identify common build, dependency, and lint errors.
Diagnose: Use an open-weight AI model to explain the likely root cause.
Propose: Generate a targeted code repair.
Validate: Apply the proposed changes in an isolated Git worktree and run relevant checks.
Review: Show the developer the proposed changes and validation results before they decide whether to apply the repair.
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.

Who would pay for it?
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.

I plan to demonstrate the complete workflow using a deliberately broken JavaScript or TypeScript repository, from the initial diagnostic to the proposed patch and validation results.

Code
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.

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

Technology stack
Frontend: React, TypeScript, Vite, Tailwind CSS, and shadcn/ui.
Backend: Java and Spring Boot.
Database: MySQL with Spring Data JPA and Hibernate.
AI model: Qwen 3.5 9B.
AI runtime: Ollama.
Repository analysis: Git, TypeScript diagnostics, ESLint, and npm.
Repair isolation: Git worktrees.
Database migrations: Flyway.
How the system works
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.

Why Does Open Innovation Matter?
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.

This creates several opportunities.

1. Privacy through local inference

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.

1. Control over model selection

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

1. 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.

1. Freedom to experiment

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.

1. A practical hybrid architecture

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.

Final Thoughts
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.

Hacktoberfest #OpenSourceAI #Ollama #Qwen #Java #SpringBoot #React #DeveloperTools