What I Built
Code never truly dies. It just waits to be understood. 👻
Every software project has a history. Features are introduced, functions are rewritten, files are deleted, and sometimes an important piece of logic disappears without anyone noticing.
But what if the code we deleted still had something to tell us?
That question inspired me to build PhantomCommit AI, an open-source, Gemma-powered Git history investigation platform that helps developers explore deleted code, understand historical changes, investigate potential regressions, and discover forgotten functionality.
I built this project individually for the Hacktoberfest 2026 Open-Source AI Challenge - Week 4: Ghost in the Machine.
My Interpretation of the Theme
For me, the "ghost" is the code that no longer exists in the latest version of a repository but still lives in its Git history.
Imagine a developer discovering that an important feature no longer works. The current code might not explain why. The answer could be hidden in a commit from weeks or months ago, where a validation check was removed, a function was replaced, or a file was renamed.
PhantomCommit AI helps investigate those clues.
Instead of treating Git history as a collection of old commits, I wanted to turn it into an interactive investigation workspace where developers could explore the past and use open-weight AI to interpret the evidence.
What Makes PhantomCommit AI Different?
I designed PhantomCommit AI around a simple principle:
Git provides the evidence. AI helps us understand it. Developers make the final decision.
The platform brings together several investigation tools.
1. Code Graveyard - Explore Deleted Code
The Code Graveyard identifies removed files and lines from inspected Git history. Developers can examine where code previously existed, when it changed, and which commit contains the relevant evidence.
Importantly, a removed line does not automatically mean functionality has permanently disappeared. The platform treats it as a clue rather than a conclusion.
2. Ghost Replay - Travel Through Git History
Ghost Replay makes it easier to explore historical changes through commit relationships and read-only code comparisons.
I used React Flow for visualizing commit relationships and Monaco Editor for comparing historical code snapshots.
This helps developers understand how a file changed instead of reading disconnected commit messages.
3. Smart Code Recovery - Investigate Possible Restoration
Sometimes removed code is still useful.
Smart Code Recovery searches historical changes, compares older and current implementations, and can generate a validated restoration patch for review when enough evidence is available.
The system does not automatically apply or merge that patch. Developers must inspect the proposal, check compatibility, and decide whether to use it.
4. Code Impact Graph - Understand Dependencies
A deleted or modified function may affect other components.
The Code Impact Graph uses TypeScript-based static analysis to examine supported JavaScript and TypeScript dependencies within a selected scope.
It can visualize relationships and help identify potential dependent code. This is intentionally a bounded static analysis, not a claim to have discovered every runtime dependency.
5. Security Regression Review - Find Suspicious Changes
PhantomCommit AI also looks for security-related changes that deserve investigation, including possible removal of authentication, authorization, validation, and other protective checks.
The results are presented as review leads with source evidence, not confirmed vulnerabilities.
6. Feature Evolution Timeline - Understand the Past
The Feature Evolution Timeline organizes historical file changes into a visual sequence.
It helps developers inspect how a feature-related area of code has changed, including additions, modifications, deletions, and recorded renames.
7. AI Studio and AI Detective - Investigate With Gemma
I built an AI Studio containing 18 focused investigation tools, along with a conversational AI Detective experience.
Developers can ask questions such as:
- Why was this function removed?
- What might have changed when this validation was deleted?
- Which inspected commits are relevant to this regression?
- What should I test before restoring this code?
- What evidence supports or challenges this explanation?
The AI is instructed to separate observed facts, hypotheses, and missing evidence. Its structured references are checked against retrieved Git information.
The goal is not to make AI sound certain. The goal is to make its conclusions easier to investigate.
Demo
Live application: https://phantomcommitai.onrender.com
PhantomCommit AI is deployed on Render, with a responsive interface designed for desktop and mobile screens.
How to Explore the Application
The intended investigation workflow is:
- Open PhantomCommit AI and sign in.
- Connect GitHub through the application's authorization flow.
- Import a public GitHub repository.
- Select a branch and inspect its real commit history.
- Open Code Graveyard to investigate removed code.
- Use Ghost Replay to compare historical snapshots.
- Open AI Studio or AI Detective and select Gemma.
- Choose an investigation, review the data-sharing consent, and submit a question.
- Inspect the AI response alongside its source references.
- Save the investigation, continue the conversation, or export a Markdown report.
The application does not populate its runtime with fictional repository histories or simulated AI responses. Investigations depend on real GitHub evidence and configured services.
The latest application revision has successfully deployed on Render. Automated checks have passed, although a complete hosted, authenticated GitHub-to-Gemma investigation has not yet been independently verified. I am keeping that distinction clear rather than presenting a simulated AI result as a real demonstration.
AI Studio interface:
Code
GitHub Repository: https://github.com/Y-Udayanga/PhantomCommitAI
The source code is publicly available under the MIT License.
Some important implementation files include:
- Gemma integration
- Ultramarine integration
- Git history analysis engine
- Evidence and reference validation
- Forensic investigation service
- AI Studio tools
- GitHub Actions verification
I wanted developers to be able to inspect how the system works rather than treating its investigation results as a black box.
How I Built It
PhantomCommit AI combines a modern full-stack web application, real GitHub data, deterministic source analysis, and open-weight AI reasoning.
Technology Stack
| Layer | Technology |
|---|---|
| Frontend | Next.js, React, TypeScript |
| Styling | Tailwind CSS |
| AI model | Google Gemma 4 |
| AI SDK | Google GenAI SDK |
| Additional AI provider | Paper Instruments Ultramarine |
| Source history | GitHub REST API |
| Authentication | Supabase Auth |
| Database | Supabase PostgreSQL |
| Visual graphs | React Flow |
| Code comparison | Monaco Editor |
| Charts | Recharts |
| Validation | Zod |
| Hosting | Render |
| Testing | Vitest, Playwright, GitHub Actions |
1. Making Gemma the Center of the Investigation
The main AI integration uses Google's open-weight Gemma models through the official @google/genai SDK.
The implementation prefers gemma-4-26b-a4b-it, with gemma-4-31b-it also supported.
The server can attempt additional Google model fallbacks when configured models are unavailable. The actual model used is recorded with the analysis, so a fallback is not silently represented as a Gemma response.
I chose Gemma because I wanted an open-weight model at the center of the project rather than building the entire investigation around an opaque, proprietary-only model.
Gemma's job is to interpret selected historical evidence, explain possible consequences, and suggest what developers should investigate next.
2. Building an Evidence-First Investigation Pipeline
One of my most important design decisions was to analyze Git data before asking AI to interpret it.
The application retrieves public repository information from GitHub, including commit identifiers, file changes, patches, parent relationships, and historical snapshots.
A deterministic analysis layer identifies deleted lines, change types, renames, and relevant review leads.
The application then selects a limited amount of relevant evidence for the AI request.
The basic flow is:
GitHub repository → Commit evidence → Deterministic analysis → Relevant context → Gemma → Structured findings → Evidence validation → Developer review
This approach keeps the AI focused on inspected code rather than asking it to invent an explanation from a repository name or a vague problem description.
3. Checking AI-Generated References
A major challenge was deciding how to handle convincing AI explanations that might not be supported by the code.
To reduce unsupported references, I implemented structured JSON response validation with Zod.
The application checks generated references against the retrieved commit SHA and file path. When a specific line and quote are provided, they must correspond to the changed-line evidence.
Unsupported references are marked as insufficient evidence.
This is not a mathematical proof that every sentence in an AI explanation is correct. It is a practical provenance check that makes it easier to identify what the available Git history actually supports.
4. Supporting Ultramarine as Another AI Provider
I also integrated Ultramarine by Paper Instruments as an additional AI provider.
The application offers an explicit provider selection, allowing its investigation tools and AI Detective experience to use either the configured Gemma route or Ultramarine.
Ultramarine uses a server-side Chat Completions integration, structured output validation, and the same evidence-verification approach.
The provider is not switched automatically without the user's choice.
This modular implementation also makes it easier to compare providers and explore alternative models in the future.
5. Managing Authentication, Persistence, and Privacy
I used Supabase Authentication and PostgreSQL for user accounts and saved investigation data.
The application is designed to store repository metadata, inspected commits, investigation runs, findings, conversations, and reports under the appropriate authenticated account.
PostgreSQL row-level security policies protect ownership boundaries, and the project includes database tests for cross-user access restrictions.
AI requests require explicit consent before selected repository evidence is sent to the chosen model provider.
The application masks several common secret patterns, limits source excerpts, validates requests, and keeps provider credentials on the server.
These are safeguards, not a promise that all sensitive information can be automatically detected.
6. Deploying on Render
I deployed PhantomCommit AI as a Node.js web service on Render, connected to the GitHub repository's main branch.
Render hosts the Next.js application and server-side API. Supabase provides the database and authentication, while AI inference runs through the selected external provider.
The service automatically deploys new commits from the repository.
I chose this architecture to keep the web application, source analysis, database, and model integration separated into maintainable components.
7. Testing and Engineering Challenges
Building the interface was only one part of the project.
I also worked on several engineering problems:
Handling incomplete Git history: GitHub may omit large patches or limit results. The system exposes incomplete evidence instead of silently assuming the whole history has been inspected.
Preventing unsupported conclusions: A removed security-related line is treated as a possible regression, not proof of an exploitable vulnerability.
Controlling AI context: I limited the number of commits, files, and excerpt characters sent to the model to keep requests focused and bounded.
Protecting user data: Authentication checks, ownership policies, request limits, and server-only API credentials are part of the design.
Avoiding unsafe automatic changes: Recovery patches are generated for inspection and export. The application does not run untrusted repository code or push AI-generated changes.
Testing the implementation: I used Vitest for unit and service tests, PostgreSQL policy tests for authorization behavior, Playwright for browser checks, and GitHub Actions for continuous verification.
The latest GitHub Actions workflow completed successfully on the deployed revision.
What I Learned
The biggest lesson from this project is that AI-powered developer tools should not confuse a plausible explanation with verified evidence.
Git history contains useful information, but it does not always reveal why a developer made a decision.
A deleted function might have been replaced. A suspicious change might be intentional. A likely regression may turn out to have a completely different cause.
I wanted PhantomCommit AI to acknowledge those possibilities instead of hiding them behind a confident answer.
Why Does Open Innovation Matter?
Open innovation is important to PhantomCommit AI because the project is about recovering and understanding knowledge that might otherwise be forgotten.
There is a strong connection between the problem I am solving and the technology I used to solve it.
Open Weights Offer Flexibility
By building around Gemma, I can explore different model configurations and potentially move inference to alternative compatible infrastructure.
The current implementation uses Google's hosted API; it does not claim to run Gemma locally or work offline.
But the availability of open weights creates possibilities for future self-hosting, customization, and evaluation that would be more restricted with a proprietary-only model.
Open Source Makes the Results Inspectable
A developer should be able to understand how a tool reaches its conclusions.
By releasing PhantomCommit AI under the MIT License, I am making its Git analysis logic, AI prompt construction, evidence-validation rules, and testing approach available for inspection and improvement.
Other developers can review the assumptions, identify weaknesses, suggest changes, or build additional investigation tools.
Open Architecture Reduces Dependence on One Provider
I separated Git evidence retrieval from AI interpretation.
The deterministic investigation features do not require the language model to generate the underlying Git facts.
The addition of Ultramarine as a separate provider demonstrates that the AI layer can be extended without rebuilding the entire application.
This is particularly valuable for an open-source tool where developers may have different infrastructure, budgets, privacy requirements, or model preferences.
Open Innovation Helps Preserve Developer Knowledge
Every repository contains technical decisions made by people who may no longer be working on that project.
Their earlier implementations can help explain current behavior, reveal useful design ideas, or highlight changes worth reviewing.
Open-source AI gives us another way to explore that knowledge while keeping the investigative method open for others to improve.
To me, open innovation means that both the code and the tools used to understand it should remain accessible, inspectable, and adaptable.
The Spirit of It 👻
The most interesting part of this challenge was discovering how naturally the theme connected with a real developer problem.
When I think about "Ghost in the Machine," I don't just imagine a mysterious AI or a haunted computer.
I imagine an old function in a commit that nobody remembers writing.
A validation check removed during a refactor.
A feature that once existed but disappeared as the project evolved.
A previous implementation waiting in Git history while the current code struggles with a regression.
Those are the ghosts I wanted PhantomCommit AI to investigate.
The goal is not to bring every piece of deleted code back to life. Some code was removed for a good reason.
The goal is to understand what happened before making the next decision.
The past cannot always tell us what to do, but it can give us better evidence for what to investigate.
And that is the idea behind PhantomCommit AI.
Code never truly dies. It just waits to be understood.
Prize Categories
I am entering PhantomCommit AI in the following partner categories:
Best Use of Gemma
Gemma is the primary open-weight AI model family used to explain historical code changes, investigate potential regressions, review evidence, and recommend further checks.
Best Use of Render
PhantomCommit AI is deployed as a Render web service, hosting the Next.js interface and its server-side investigation API.
Best Use of Ultramarine (Paper Instruments)
Ultramarine is integrated as a selectable investigation provider, using the Paper Instruments API with structured responses and source-evidence validation.
Final Thoughts
I built PhantomCommit AI independently for this challenge because I wanted to create something that was both creative and useful for software developers.
The project combines open-weight AI, Git history analysis, interactive visualization, and practical engineering safeguards.
There are still improvements I want to make, including more advanced semantic code tracking, stronger validation of AI explanations, and wider historical analysis.
But the core idea will remain the same:
Don't let your codebase's history disappear into forgotten commits. Investigate it, understand it, and learn from it.
Thanks for exploring PhantomCommit AI!
🔗 GitHub: https://github.com/Y-Udayanga/PhantomCommitAI
🌐 Live Demo: https://phantomcommitai.onrender.com
I would love to hear your feedback. What is one debugging problem where understanding deleted or historical code would have helped you?
Built individually by Yasindu Udayanga for Hacktoberfest 2026 - Ghost in the Machine.
Top comments (0)