The problem

I kept noticing the same gap while building with AI and exploring GitHub repositories.

It is easier than ever to generate, clone, deploy, and share a project. But when someone asks, “How does this actually work?” it is still hard to explain the full system: the frontend, backend, APIs, middleware, data layer, UI components, functions, imports, and the files connecting them.

Reading a README or asking a general chatbot often gives a summary, not a source-backed understanding.

What I built

CodeStory.tools turns an unfamiliar repository into a structured learning experience.

A user can paste a public GitHub repository URL, and CodeStory creates an evidence-first map of the project:

  • Architecture areas: frontend, APIs, middleware, backend services, data, and supporting code
  • UI inspector: visible elements, components, handlers, props, imports, classes, and nearby source
  • Endpoint and data-contract maps from observable route declarations and schemas
  • Function explorer, feature traces, and change-impact views
  • Guided learning routes that help users prove understanding instead of only reading summaries
  • CodeLab, a smaller safe reconstruction exercise that never executes the original repository

Safety and honesty

CodeStory reads source files but does not run untrusted project scripts, install dependencies, run Docker, use secrets, or contact project services.

It also separates what source code can prove from what is only inferred. Static references are not presented as runtime metrics, and README files, diagrams, and screenshots are treated as context—not automatic proof.

How I built it

I used Codex with GPT-5.6 as a development partner to turn the product idea into testable features, iterate on the analysis flow, investigate edge cases, fix deployment issues, and refine the learning experience.

The core experience works without an API key through deterministic static analysis. Users can optionally choose Gemini or local Ollama for deeper natural-language explanations.

Challenges

The hardest part was avoiding a product that sounds confident but guesses.

I focused on grounding each explanation in scanned source evidence, handling different repository types such as web apps, APIs, CLI tools, notebooks, libraries, and documentation repositories, and making uncertainty visible when the code cannot prove a connection.

My goal is simple: help someone go from opening an unfamiliar repository to confidently explaining how it works.

Built With

Share this project:

Updates