DEV Community: Shujaur Rahman Haadi

RepoPilot: Navigate Unfamiliar Codebases Without Getting Lost

Shujaur Rahman Haadi — Sun, 25 Oct 2026 09:59:36 +0000

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

What I Built

Have you ever discovered an interesting GitHub repository, wanted to understand how it works, and then spent hours jumping between files trying to figure out how everything connects?

That's the problem I wanted to tackle with RepoPilot.

RepoPilot is a repository analysis tool that helps developers explore unfamiliar codebases using Python static analysis, interactive function call graphs, and AI-generated insights.

Instead of manually piecing together a repository's structure, developers can submit a public GitHub repository URL and get a structured starting point for understanding the code.

What can RepoPilot do?

Explore repository structure: Inspect files, extensions, and file sizes.
Analyze Python code: Extract functions, classes, imports, and function calls using Python's Abstract Syntax Tree (AST).
Visualize function relationships: Explore connections between functions through an interactive call graph.
Generate AI-assisted insights: Get a project overview, architectural observations, potential issues, and recommendations.
Investigate code more efficiently: Bring repository structure, code relationships, and natural-language explanations together in one workspace.

The goal is simple: reduce the repetitive work involved in getting familiar with a project so developers can spend more time understanding the code and less time manually piecing everything together.

Demo

Project repository: RepoPilot on GitHub

The repository README includes screenshots of the landing page, interactive call graph, and AI-assisted analysis report.

Code

Source code: github.com/shujahaadi/RepoPilot

RepoPilot is organized into separate modules for repository analysis, graph construction, API routes, and AI integration.

The main analysis pipeline looks like this:

GitHub Repository URL
        |
        v
   FastAPI Backend
        |
        v
 Repository Cloning
        |
        v
 File Inventory + Python AST Analysis
        |
        v
 Function Relationship Graph
        |
        v
 AI-Assisted Repository Insights
        |
        v
 Interactive React Workspace

The frontend brings these results together so developers can explore repository files, inspect function relationships, and review the generated analysis.

How I Built It

I built RepoPilot using a combination of backend development, static analysis, graph visualization, and AI integration.

Tech Stack

React and Vite: Frontend application and development tooling.
React Flow: Interactive function call graph visualization.
FastAPI: Backend API.
Python AST: Extracting structural information from Python source code.
GitPython: Cloning and inspecting Git repositories.
Google Gemini API: Generating repository overviews and additional insights.
HTTPX: Making asynchronous HTTP requests to the AI API.

The Analysis Pipeline

The backend starts by cloning a repository and building an inventory of its files. Python files are then analyzed using the ast module to identify functions, classes, imports, and function calls.

The graph builder uses the extracted information to construct function relationships. Some relationships are straightforward to resolve, while ambiguous names and Python's dynamic behavior can make others more difficult.

The AI integration adds a natural-language layer to this structural information. It generates an overview of the project, architectural observations, potential issues, and recommendations based on the available repository context.

I also implemented processing limits to keep analysis manageable for larger repositories.

Challenges and Lessons

One of the more interesting challenges was turning raw function-call information into a useful graph. Detecting that a function calls another function is only part of the problem; identifying the correct target requires resolving names and handling ambiguity.

Another challenge was connecting the backend analysis pipeline to an interactive frontend that presents the results clearly.

Building RepoPilot gave me practical experience with API development, Python AST analysis, modular backend architecture, graph construction, React integration, and hosted AI APIs.

It also reinforced the importance of treating automated findings as starting points for investigation rather than unquestionable conclusions.

Why Does Open Innovation Matter?

Developer tools become more useful when people can inspect them, learn from them, adapt them, and contribute improvements.

By making RepoPilot's source code publicly available on GitHub, I want to give other developers a starting point they can examine, experiment with, and extend.

For a repository analysis tool, transparency matters. Developers should be able to inspect how the analysis pipeline works, understand how function relationships are constructed, and improve the implementation rather than relying entirely on unexplained results.

Open collaboration also creates opportunities to improve call resolution, expand language support, refine graph visualization, and develop better ways to explain how different parts of a codebase interact.

My goal is to make repository exploration more approachable and create a foundation that other developers can build on.

What's Next?

RepoPilot is a starting point for making unfamiliar repositories easier to navigate.

Potential improvements include:

Better cross-file function resolution.
Broader programming-language support.
More detailed explanations connected to source code.
Further improvements to graph exploration and repository navigation.

Building this project reinforced an important lesson for me: useful developer tools don't have to automate everything. Sometimes, making the first few steps easier is already a meaningful improvement.

If you've ever opened a repository and wondered, "Where do I even start?", that's the problem RepoPilot is trying to solve.

Built with curiosity, code, and a goal of making repository exploration easier.

Perspectivity: Go Outside. See Differently.

Shujaur Rahman Haadi — Sun, 11 Oct 2026 18:00:57 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Perspectivity — Go Outside. See Differently.

What if going outside could become an opportunity to think like a researcher?

Perspectivity combines Perspective + Activity into an AI-powered field investigation experience. Instead of endlessly scrolling on a screen, users receive a real-world mission that encourages them to observe their surroundings, collect evidence, and form their own hypotheses.

Here's how it works:

Generate a mission: Get an investigation based on your available time and experience level.
Observe the world: Head outside and record what you notice through written or voice-to-text notes.
Form a hypothesis: Develop your own explanation based on your observations.
Get an AI debrief: Review the evidence, identify assumptions, explore alternative explanations, and discover what to investigate next.

The goal isn't to let AI think for you. It's to use AI to help you become a better observer and thinker.

Demo

The project currently runs locally. I haven't deployed a public demo yet.

Code

GitHub repository: https://github.com/shujahaadi/perspectivity

The project is open source under the MIT License.

The repository includes the React frontend and FastAPI backend, along with instructions for configuring the required API key and running the application locally.

How I Built It

I built Perspectivity using React and Vite for the frontend and FastAPI for the backend. Pydantic validates structured data exchanged between the frontend and backend.

For the AI component, I used Google's hosted Gemma model (gemma-4-26b-a4b-it) through the Google GenAI SDK.

Gemma powers two key parts of the experience:

Mission generation: It creates structured field investigations with a role, central question, mission, rules, and required observations.
AI debriefing: It reviews the user's observations and hypothesis, helping distinguish evidence from assumptions and suggesting useful next steps.

The backend validates the model's structured output before returning it to the frontend. I also added input validation and error handling for invalid requests.

I chose hosted inference because my development machine has limited RAM, making local inference less practical. This allowed me to focus on building the complete experience around an open-weight model rather than requiring powerful hardware.

Why Does Open Innovation Matter?

Open innovation makes it possible for developers to experiment with AI, build on open-weight models, and create applications that go beyond generic chat interfaces.

With Gemma, I could build a focused experience around real-world observation and reasoning, shaping the prompts and workflow for a specific purpose.

For me, this project was also an opportunity to learn by building: connecting an AI model to a full-stack application, validating its output, handling failures, and thinking about how AI should support human reasoning rather than replace it.

I hope Perspectivity can eventually grow into an open-source collection of field investigations that anyone can adapt, extend, and contribute to.

Prize Categories

Best Use of Gemma — uses a hosted Gemma model for mission generation and AI-powered debriefing.

CentralResolve - One Project. Multiple Conversations. One Clear Picture.

Shujaur Rahman Haadi — Sun, 04 Oct 2026 08:10:42 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

During a recent SIH project, my team and I ended up communicating about the same project across both a WhatsApp group and a Discord server.

The problem was not that we were not communicating. The problem was that we were communicating in different places.

A task could be assigned on WhatsApp and later discussed differently on Discord. A deadline mentioned on one platform could be different from the one mentioned somewhere else. Updates could also get buried, leading to confusion about who was responsible for what or whether something was actually finished.

That experience inspired me to build CentralResolve.

CentralResolve takes exported WhatsApp and Discord conversations and analyzes them together to identify contradictions that may otherwise be missed.

It currently looks for:

Conflicting task ownership
Different deadlines
Contradictory project statuses
Unresolved decisions

Instead of producing another long summary of everything a team said, CentralResolve focuses on the parts that may actually require attention.

The idea is simple:

One project. Multiple conversations. One clear picture.

I built this for one of my friends from that project because we had already experienced the communication problem that CentralResolve is designed to solve.

Demo

Demo video: https://youtu.be/n1In5QHXMN4

The demo shows the complete end-to-end workflow:

Open CentralResolve.
Upload a WhatsApp chat export.
Upload a Discord JSON export.
Start the analysis.
Let Gemma extract structured project facts.
View the detected conflicts.
Inspect the supporting evidence from each platform.
Start a new analysis.

Code

GitHub Repository: https://github.com/shujahaadi/CentralResolve

How I Built It

The core of CentralResolve is Gemma 3 4B, running locally through Ollama.

The application is divided into four main stages:

WhatsApp Export ──┐
                  ├──> FastAPI ──> Gemma 3 4B
Discord Export ───┘                 │
                                    ↓
                             Structured Facts
                                    ↓
                       Deterministic Conflict Detection
                                    ↓
                              React Dashboard

Parsing

CentralResolve accepts:

WhatsApp chat exports as .txt
Discord message exports as .json

Both formats are parsed into a common message structure containing:

Platform
Sender
Timestamp
Message content

The platform is preserved throughout the pipeline so that the system knows whether a piece of evidence came from WhatsApp or Discord.

Understanding the Conversations

Gemma 3 4B is used to turn messy conversation text into structured project facts.

For example:

[whatsapp] Rahul: I'll handle deployment.
[discord] Rahul: I can't handle deployment anymore.

Gemma extracts facts such as:

Task assignments
Deadlines
Status updates
Decisions
Unresolved issues

The model also returns the original message as evidence.

The prompt explicitly tells the model not to invent information and to preserve the original meaning of the conversation.

Conflict Detection

The structured facts are then passed to a deterministic Python conflict detector.

CentralResolve currently checks for:

Ownership conflicts
Deadline conflicts
Status conflicts
Unresolved decisions

The LLM does not make the final conflict decision by itself.

Instead:

Conversation
     ↓
Gemma 3 4B
     ↓
Structured Facts
     ↓
Python Conflict Rules
     ↓
Explainable Conflict

This separation makes the final conflict logic explicit and inspectable.

For example, if one fact says:

Rahul will handle deployment

and another says:

Rahul can't handle deployment anymore

the deterministic detector can identify that as an ownership conflict and return the original messages as evidence.

Frontend

The frontend is built with React and Vite.

The dashboard displays:

WhatsApp message count
Discord message count
Total messages
Number of conflicts
Conflict type
Conflict severity
Supporting evidence
Original platform for each evidence item

The goal of the interface is to take a large amount of conversation data and quickly show the small number of issues that need attention.

Why Does Open Innovation Matter?

CentralResolve works with potentially private team conversations.

The current implementation uses Gemma 3 4B locally through Ollama rather than relying on a closed third-party AI API.

Conversation Files
       ↓
    FastAPI
       ↓
 Local Ollama
       ↓
 Gemma 3 4B
       ↓
Structured Facts

This matters because the conversation data can be analyzed on the user's own machine without requiring it to be sent to a proprietary AI provider just to perform the model inference.

For a tool dealing with private team communication, that is an important difference.

The open approach also gives the project more control over the AI layer. Because the model is open-weight, the system can be adapted as the project evolves instead of being completely tied to one closed API.

It also makes it possible to:

Run inference locally
Swap models
Change prompts and model behavior
Experiment with different open models
Avoid being locked into a single proprietary AI provider

For CentralResolve, local inference was not just a technical experiment. It fit the problem.

We wanted a tool that could look at conversations without making privacy an unnecessary tradeoff.

Prize Categories

Best Use of Gemma

I am entering Best Use of Gemma.

CentralResolve uses Gemma 3 4B as the core language model for understanding cross-platform team conversations and extracting structured project facts.

Gemma runs locally through Ollama, while deterministic Python logic handles the final conflict detection.

Final Thoughts

CentralResolve started with a problem that felt very real during a project with friends.

We were already communicating.

We were already sharing updates.

But because those conversations were spread across WhatsApp and Discord, we sometimes ended up with different understandings of the same project.

That led me to a simple question:

What if we could look at all of those conversations together and identify where the team stopped agreeing?

CentralResolve is my attempt at answering that question.

Not another tool that summarizes everything.

A tool that tells you where your team might no longer be on the same page.