GitLore

Travel through your codebase’s history to uncover the decisions, incidents, and people behind every line.

Comment

Inspiration

Most developer tools explain what a codebase does today. They rarely explain why it became that way.

Important context is scattered across commits, pull requests, issues, incident reports, architecture notes, and the memories of individual engineers. Over time, teams lose that institutional knowledge. A strange service boundary or duplicated function may appear accidental—even when it was once a reasonable response to an outage, deadline, migration, or security concern.

GitLore was inspired by a simple question:

What if you could travel through a codebase’s history and reconstruct the story behind its architecture?

What it does

GitLore is a Codebase Time Machine that turns repository history into an evidence-backed narrative.

A developer can ask a question such as:

Why is authentication split across three services?

GitLore presents the answer as an investigation containing:

  • A chronological architecture timeline
  • The commits, pull requests, issues, and incidents behind each change
  • A visual map of affected services and dependencies
  • Key findings and unresolved migration risks
  • Confidence scores grounded in the available evidence
  • Direct links from conclusions to their supporting sources

The Build Week prototype follows the evolution of a fictional production repository. Its central investigation reveals that authentication was not intentionally designed as three services. The boundaries emerged through a sequence of operational incidents and incremental migrations.

The final reveal uncovers a forgotten mobile token-refresh route that still depends on the legacy session store. The migration is 96% complete—not 100%.

How I built it

I built GitLore with Codex and GPT-5.6, using Codex as the primary development partner for product ideation, interface design, implementation, debugging, production validation, and deployment.

The application is built with:

  • React and TypeScript
  • Next.js-compatible application architecture
  • Vinext and Vite
  • HTML and responsive CSS
  • Cloudflare-compatible server output
  • OpenAI Sites for hosting and deployment
  • GPT Image for the GitLore social and submission artwork

The interface was designed around software archaeology rather than a conventional chatbot. The experience combines an investigation prompt, historical chapters, primary-source evidence, an architecture map, and confidence indicators into one cohesive workspace.

The current prototype uses realistic seeded repository evidence to demonstrate the complete product experience. A production version would connect to GitHub or another source-control platform, retrieve repository history and collaboration records, and use GPT-5.6 to synthesize traceable answers without losing the connection to primary sources.

Challenges

Making the AI feel essential

The project needed to be more than a chat interface placed on top of Git history. I focused the experience on a task that genuinely benefits from advanced reasoning: connecting architectural changes to incidents, discussions, dependencies, and incomplete migrations across time.

Presenting complex history clearly

Repository history can become overwhelming quickly. I organized the answer into four layers:

  1. The concise explanation
  2. The chronological story
  3. The architecture view
  4. The supporting evidence

This lets someone understand the conclusion immediately while still being able to inspect how it was reached.

Preserving trust

A confident explanation is dangerous if nobody can verify it. GitLore keeps evidence and confidence visible throughout the investigation. Its product principle is:

Evidence, not guesswork.

Building a compelling demonstration

A live repository integration would introduce authentication, permissions, and unpredictable data during a short demo. I created a focused narrative dataset that demonstrates the intended workflow reliably, including a meaningful final discovery rather than a collection of disconnected interface elements.

What I learned

I learned that repository history becomes substantially more useful when treated as a causal story rather than a search index.

Commits explain what changed, but the real reason often lives elsewhere: an incident report, a pull-request comment, a rollout constraint, or a temporary compatibility decision. Reconstructing architectural intent requires connecting those artifacts while distinguishing evidence from inference.

I also learned how effectively Codex can support an entire product cycle. It helped move GitLore from an early concept to a polished, responsive, production-deployed prototype while maintaining a consistent product narrative.

What’s next

The next version of GitLore would add:

  • GitHub repository and organization connections
  • Live commit, pull-request, issue, and discussion ingestion
  • Architecture extraction from source code
  • Evidence-linked GPT-5.6 investigations
  • Repository-wide migration completeness checks
  • Comparison of architecture across releases
  • Team annotations and corrections
  • Shareable investigation reports
  • Automatic detection of stale architecture documentation
  • Privacy controls for sensitive repositories

The long-term vision is for GitLore to become a living institutional memory for software teams—helping new engineers understand inherited systems and helping experienced teams make future decisions with the full context of the past.

Built With

Share this project:

Updates