LazyRepo: Let Local AI Investigate the Repository Before You Dive In

sahaj srivastava — Sat, 24 Oct 2026 08:38:09 +0000

An open-source, local-first AI tool for contributors who want to spend less time searching unfamiliar codebases and more time understanding them.

When you contribute to an unfamiliar open-source project, the first challenge often isn't writing code. It's figuring out where to begin.

You receive an issue, open a repository with hundreds of files, search through filenames, jump between implementations and tests, and try to understand which parts are relevant. Then you ask an AI for help—and discover that a confident explanation isn't necessarily a correct one.

I wanted to make that first investigation less tedious without handing my repository to a cloud-based AI service.

So I built LazyRepo, a Python CLI that uses a locally running AI model to investigate repository issues using selected source-code evidence.

This is my submission for the Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady.

What I Built

LazyRepo helps developers get oriented in an unfamiliar repository before they start changing code.

You provide a repository path and a description of the issue. LazyRepo then:

Scans the repository while excluding common generated and dependency directories.

Ranks potentially relevant files using explainable keyword-based selection.

Reads selected files with safety and size limits.

Builds a bounded evidence package with line-numbered source.

Sends that evidence to a locally running AI model for analysis.

Checks citations and applies safeguards against certain unsupported or contradictory claims.

Produces a report containing relevant evidence, a possible explanation, unknowns, and next verification steps.

The goal isn't to generate a patch automatically. It's to reduce the effort required to understand where a problem might live and what to investigate next.

LazyRepo does not modify the target repository or execute its code and tests.

Demo

Watch LazyRepo investigate a repository issue:

The demo shows a real CLI investigation against my Java project, Nexus. The example issue is that the project registry appears to fail to find a project by ID.

The important part isn't whether the model produces a clever explanation. It's whether the available evidence actually supports one.

In this example, existing tests already cover registered-project lookup and unknown IDs. LazyRepo recognizes that the supplied evidence doesn't establish the reported defect and recommends checking the actual failing runtime input instead of inventing a root cause.

That is the behavior I want from a useful investigation assistant: help me narrow down the problem without pretending uncertainty has disappeared.

Code

Repository: https://github.com/sahajsrivastava044-spec/LazyRepo

LazyRepo is built in Python and uses Ollama to run the qwen2.5-coder:3b model locally.

The code is organized into focused modules for repository scanning, file reading, evidence construction, file selection, and local analysis. Unit tests cover important behavior such as evidence limits, malformed model responses, citation validation, and safeguards around unsupported conclusions.

To try it, you'll need Python, Ollama, and the model used by the project.

ollama pull qwen2.5-coder:3b
ollama serve

In another terminal, from the project directory with its Python environment configured:

python -m src.main --repo "PATH_TO_YOUR_REPOSITORY" --issue "Describe the issue you want to investigate"

See the repository README for installation, setup, usage, and testing instructions.

How I Built It

I built LazyRepo as a small, modular CLI rather than starting with a web interface. The core challenge was making the investigation pipeline useful and predictable.

The workflow is:

Repository scan → file selection → bounded evidence → local AI analysis → guarded report

I used Python for the pipeline and tests, Ollama for local inference, and Qwen2.5-Coder 3B as the model.

One important design decision was to separate finding evidence from asking the model to interpret it. The model should not need the entire repository dumped into its prompt. LazyRepo selects relevant files first and limits how much source it reads and sends for analysis.

I also learned that safeguards have to be designed carefully. A citation checker can verify that a referenced path and line exist in the supplied evidence, but that alone cannot prove the cited code supports the claim. Likewise, detecting certain contradictions is not the same as proving a model's reasoning correct.

Those limitations matter. LazyRepo's checks are guardrails, not a guarantee of correctness.

Why Does Open Innovation Matter?

The local-first design is central to this project, not an optional feature.

Using an open-weight model through local inference means LazyRepo can analyze selected repository evidence without requiring a cloud AI API. The source evidence and model prompts are sent to the local Ollama service rather than a remote AI provider.

That gives developers more control over their code and their workflow. It also makes the model replaceable: contributors can experiment with different compatible local models as their hardware and requirements allow.

Local inference has trade-offs. Model quality, memory usage, and response speed depend on the machine and the model. Running locally also doesn't mean every part of the workflow is automatically offline; setup and model downloads may require internet access.

For me, open innovation means being able to inspect, adapt, and run the core AI workflow on my own terms instead of treating the model as an inaccessible service.

The Lazy Payoff

LazyRepo is designed to reduce the repetitive first steps of investigating an unfamiliar codebase: locating relevant files, gathering source context, and identifying what to verify.

I haven't established a reliable time-saved benchmark yet, so I won't claim a specific number of minutes saved. The immediate payoff is a more structured starting point for an investigation, with evidence and uncertainty made visible.

The larger goal is to help contributors spend less time wandering through a repository and more time understanding it.

Built for the Slow and Steady theme of the Hacktoberfest Open-Source AI Challenge.

hf26challenge #devchallenge #hacktoberfest #python #opensource #ai

My open-source experience

sahaj srivastava — Tue, 06 Oct 2026 07:03:46 +0000

When I first entered the college I head of the word Github and open-source contribution. It sounded strange at first that how solo developers can make a contribution to major software which people use in their daily lives. When I entered the field of open source development I understood that there is more to it that meets the I. Open-source development is actually about developers find potential bugs and enhancements and how to work on them thoroughly and making sure that out work is recognized. This makes a good developer portfolio or what I am told by the way.

Well here are the three learnings that I faced and reflected over my first official open source contribution through kalvium Ed-tech organization:-

=> The problem and the work: This week I worked on BookCars (aelassas/bookcars), a TypeScript-based car-rental platform, and investigated a possible authorization issue in the booking system. I focused on the updateStatus() endpoint, where a supplier can update booking statuses after passing authentication and the supplier-role check. While tracing the code, I noticed that the endpoint looks up bookings only by their IDs and does not verify that the booking actually belongs to the supplier making the request, unlike the existing deleteBookings() logic which explicitly checks supplier ownership. I compared the relevant route, controller, and authorization code instead of assuming that the issue existed from the endpoint name alone. My work was therefore mainly code investigation and evidence gathering, with the potential issue being that one supplier could change another supplier's booking status if they obtained its booking ID.

Issue: Github Issue link

=> How you used and verified AI: I used AI mainly as a second pair of eyes for code exploration and reasoning, rather than treating its answers as proof. For example, AI helped me identify that I should compare the updateStatus() controller with other booking operations and inspect how supplier authorization was implemented. I then opened the actual repository code myself and verified that the route uses authJwt.verifyToken and authJwt.authSupplier, while updateStatus() queries bookings by ID without checking the supplier ID. I also checked deleteBookings(), where an explicit comparison between the logged-in supplier and the booking's supplier already exists. This comparison was important because it showed that the concern was based on an actual difference in the code rather than simply trusting AI's claim that the endpoint was vulnerable.

=> Reflection: The hardest part this week was not finding something that looked suspicious, but proving that it was actually worth reporting. I had to trace the request from the route through the authentication middleware into the controller and then compare it with another endpoint before I could understand the authorization gap properly. I learned that good open-source work requires much more than spotting a possible bug: I need to understand the surrounding architecture, existing security patterns, expected behavior, and potential impact before making a claim to maintainers. Next week, I will spend more time creating a minimal local reproduction or regression test before proposing an issue, so that my reports contain executable evidence rather than only static code analysis.

DEV Community: sahaj srivastava

LazyRepo: Let Local AI Investigate the Repository Before You Dive In

hf26challenge #devchallenge #hacktoberfest #python #opensource #ai

My open-source experience