Inspiration

Opening an unfamiliar codebase often feels like investigating a crime scene: there are hundreds of files, unclear dependencies, and just enough context to make a wrong change confidently.

I built Codebase Coroner to make that first investigation faster and safer. Instead of showing developers an overwhelming “spaghetti graph,” it starts with a readable package-level map and lets them progressively inspect the files, functions, runtime evidence, and downstream impact that matter.

The goal is simple: help a developer answer:

  • What does this codebase do?
  • Where does this file or function fit?
  • What caused this failure?
  • What could break if I change this?
  • What evidence supports the answer?

What it does

Codebase Coroner accepts a public GitHub repository URL, or a private repository through optional GitHub OAuth, then clones and analyses it locally.

It builds one typed dependency graph across Python, JavaScript, TypeScript, Java, Kotlin, Go, Rust, Ruby, PHP, C/C++, C#, and Swift. From that graph, the app provides three workflows:

  • Understand: package-first architecture map, repository brief, file summaries, function explanations, source citations, and architecture Q&A.
  • Diagnose & Fix: stack-trace mapping, opt-in sandboxed runtime capture, evidence-based failure location, constrained patch generation, and disposable patch verification.
  • Impact Analysis: downstream files, tests, packages, hotspot signals, change risk, and a “Why?” action that explains the exact import path behind an impact claim.

Every AI-generated claim includes source evidence links. Generated patches are review-only and are never silently applied.

How I built it

The backend is built with FastAPI, NetworkX, GitPython, Tree-sitter language parsers, and a canonical typed graph model. Python receives deeper AST analysis, while the other supported languages use Tree-sitter-backed extraction with resilient source-level fallbacks.

The frontend uses React, TypeScript, Vite, and React Flow. We deliberately redesigned the graph to avoid visual clutter: users begin with packages, then select a file to reveal only its direct dependency lines.

For explanations, Codebase Coroner supports an OpenAI-compatible AI provider. The model is given only the narrow repository evidence required for the requested repository brief, file brief, function brief, architecture question, or patch task. If no AI provider is configured, the application still produces static evidence-based summaries.

We used Codex with GPT-5.6 throughout the build to accelerate implementation: shaping the canonical graph model, iterating on the React interaction design, adding multi-language extraction, writing tests, tightening runtime safety controls, and turning feedback into product improvements quickly.

Challenges I faced

The largest challenge was making codebase maps useful rather than impressive-looking but unreadable. Early graphs showed too many nodes and crossing lines. We solved this with a package-first view, file-focused dependency lines, edge filters, search, hotspot emphasis, and relationship explanations only when a user asks for them.

A second challenge was making AI explanations trustworthy. A generic summary can sound confident while being wrong, so we designed the system around evidence: every repository, file, function, and Q&A response can link back to line-numbered source excerpts.

Finally, supporting multiple languages required a pragmatic approach. Rather than pretending every language has identical parser depth, we normalize available definitions, imports, and calls into one graph while preserving a robust fallback path when a grammar is unavailable.

What I learned

I learned that developer tooling should prioritize decision-making over visualization. Developers do not need every relationship at once, they need the right relationship, with proof, at the moment they are about to inspect, debug, or change code.

I also learned that AI is more valuable in a developer workflow when it is constrained by structured repository context and transparent evidence, rather than treated as an ungrounded autocomplete box.

Built With

Share this project:

Updates