Revenant：我打造了一款開源 AI 工具，讓失效程式碼重獲新生

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

Not every dead project deserves to stay dead.

Somewhere on GitHub, there is probably a project that someone spent months building, only for it to be abandoned. Its dependencies are outdated, its documentation is incomplete, and the developer who originally wrote it has moved on.

The code is still there. The ideas are still there. But the software no longer works.

That thought inspired me to build Revenant, an AI-powered investigation tool designed to help developers understand abandoned codebases, diagnose what went wrong, and attempt to bring them back to life.

The idea came from a simple question:

What if we could treat a broken software project like a crime scene, and use AI to investigate what killed it?

For this week's Ghost in the Machine theme, I wanted to build something that went beyond a spooky interface. Instead of creating another Halloween chatbot or ghost story generator, I wanted to address a real problem that developers encounter.

Revenant turns debugging old software into a digital forensic investigation.

How Revenant Works

The experience follows the story of a digital resurrection.

1. Open a Case 🔍

Start by importing an old or broken JavaScript/Node.js project. Revenant examines its structure, dependencies, and important files to understand what the software was originally supposed to do.

2. Digital Autopsy 💀

Instead of immediately suggesting random fixes, Revenant investigates the evidence.

It examines available documentation, dependency configurations, and error logs to identify potential causes of failure.

The important distinction is between something the evidence confirms and something the AI merely suspects.

3. The Repair Lab 🧪

Once a likely problem is identified, Revenant proposes a targeted repair.

Rather than rewriting an entire codebase, the goal is to make one focused change that addresses the identified failure.

The developer can inspect the proposed modification before deciding whether to accept it.

4. The Resurrection Chamber ⚡

This is where the most important question gets answered.

Did the fix actually work?

The intended verification process compares the project's behavior before and after an approved repair, using controlled checks rather than relying on the AI's confidence.

5. The Final Verdict

Every investigation ends with an evidence-based conclusion:

• Resurrected: The previously failing check now passes.
• Partially Repaired: Some issues were resolved, but others remain.
• Failed: The attempted repair did not resolve the verified problem.
• Unverified: There is insufficient evidence to confirm success.

Because an AI saying "I fixed it" is not the same as a project actually working.

And that distinction is what makes Revenant more than a Halloween experiment.

Demo

https://youtu.be/Az6MAQqEZL4

The best way to understand Revenant is to follow an investigation from beginning to end.

A successful demonstration is not simply a screen that says Resurrected. It is a failing check, a reviewable change, and a passing check afterward.

Code

GitHub Repository: https://github.com/ramtelPJ/Revenant

Revenant is built around a focused development problem: investigating and repairing small, previously working JavaScript/Node.js projects.

The repository includes the application source code, with the investigation and repair experience organized around an evidence-first workflow.

[ADD VERIFIED REPOSITORY DETAILS: installation commands, supported environments, example projects, and dependencies.]

If you want to explore the project yourself, the best place to begin is with one of the included sample cases.

How I Built It

I approached Revenant with one main constraint:

The AI should act like an investigator, not an all-powerful mechanic.

A traditional AI coding assistant can often generate a plausible solution when given an error message. But plausibility is not proof.

For Revenant, I wanted an investigation process in which the source code, error logs, human approval, and verification results each had a separate role.

1. Local AI as the Investigator

Revenant is designed around locally operated, open-weight AI rather than requiring a proprietary cloud model for its core reasoning.

AI model: qwen2.5-coder:3b

Local inference runtime: Ollama

Application stack: Next.js, React, TypeScript, Tailwind CSS, SQLite and Drizzle, Zod and Vitest, Node.js 26, Docker.

The local model's job is to interpret repository context, explain unfamiliar code, connect failures to supporting evidence, and propose a possible repair.

This is where open-source AI becomes central to the project.

Without code understanding and reasoning, Revenant would be little more than a dependency scanner with a Halloween theme.

2. Giving the AI Evidence Instead of Just a Prompt

One of my main design decisions was to make the investigation source-aware.

A useful diagnosis should answer more than "What might be wrong?"

It should also explain:

• Which file suggests the problem?
• What dependency or configuration is involved?
• What does the available error output tell us?
• Is the diagnosis confirmed, or is it still a hypothesis?

This matters when working with abandoned projects because their original maintainers may not be available to explain unusual implementation decisions.

The aim is to help a developer understand the problem rather than blindly accept a generated patch.

3. Keeping the Developer in Control

Another important design principle was that the AI should not silently modify the original code.

The repair workflow is designed to keep the proposed change reviewable, request explicit approval, and preserve the original project separately.

This is especially important when dealing with unfamiliar repositories.

An AI can generate a fix that looks reasonable while introducing another problem. Human review remains part of the process.

4. Verification Is Different From Generation

This is the technical idea I care about most.

Imagine an older project fails because one of its dependencies is incompatible with the current runtime.

An AI may correctly identify the issue and propose changing a dependency version.

But that proposal alone does not establish that the project works.

Revenant's verification design separates these two questions:

What does the AI think will fix the project?

What can we demonstrate actually changed?

The intended workflow compares approved before-and-after checks inside an isolated, resource-limited environment.

If verification fails or cannot be performed, the application should report that limitation instead of inventing a successful resurrection.

5. Building for a Small, Honest MVP

One lesson from this project was the importance of limiting scope.

Instead of attempting to repair every programming language or modernize entire repositories, I focused the design on small JavaScript/Node.js projects and narrow, inspectable fixes.

That constraint makes the problem more approachable and the results easier to evaluate.

Revenant is not intended to replace experienced maintainers, perform unrestricted execution of unfamiliar code, or guarantee that an old application is production-ready.

It is intended to give developers a more useful starting point for bringing forgotten software back into working condition.

Why Does Open Innovation Matter?

This was not a project where I wanted to call a hosted AI API and label the result open source.

The open model is part of the reason Revenant exists.

There are three reasons that matter to me.

1. Code Should Not Have to Leave Your Machine

Source code can contain sensitive information, proprietary logic, internal configuration, and implementation details that developers do not want to send to third-party AI services.

With locally hosted inference, the investigation can take place on the user's own computer.

That changes the relationship between the developer and the AI.

The developer is no longer required to send every codebase to a remote model simply to understand why something stopped working.

2. An Abandoned Project Shouldn't Depend on Another Service Surviving

There is something ironic about using a permanently hosted, proprietary service to revive software that was abandoned because its ecosystem changed.

What happens if that AI service becomes unavailable, changes its pricing, or removes the model you depend on?

Local open-weight AI offers a different approach.

Once the necessary application dependencies and model weights are installed, the core investigation can be designed to work without internet access.

Remote repository downloads may still require a connection, but already available projects can be investigated locally.

For a tool dedicated to preserving and reviving old software, that independence matters.

3. Developers Should Be Able to Inspect and Improve the Investigator

With open models and tools, developers have more freedom to change the inference runtime, experiment with alternative models, adjust prompts, and evaluate how the system reaches its recommendations.

That flexibility is valuable because different projects have different requirements.

A small project might be manageable with a compact local model, while more complex repositories could benefit from stronger reasoning capabilities.

A closed API may provide stronger results in some situations, particularly on large or complicated codebases. But it also introduces an external dependency.

For Revenant, local control, inspectability, and the possibility of offline operation are fundamental design choices, not just deployment preferences.

The Spirit of It

Halloween is usually about ghosts, haunted places, and things returning from the dead.

But working on Revenant made me think about a different kind of ghost.

Abandoned software is full of unfinished stories.

Behind every forgotten repository is someone who once had an idea.

Maybe it was a student's first serious project. Maybe it was a useful tool that never found enough contributors. Maybe it was an experiment that worked beautifully until its dependencies became obsolete.

Eventually, the updates stopped.

The issues went unanswered.

The application stopped running.

But the code remained.

I like the idea that an old repository does not necessarily have to be the end of that story.

With the right tools, someone can return to it, understand what its original developer was trying to accomplish, and perhaps give it another chance.

That is what inspired Revenant.

I did not want to build an AI that pretends to perform magic.

I wanted to explore whether AI could help us understand the software we have left behind, while being honest about what it can and cannot repair.

And if the outcome is only a better explanation of why a project failed, that still has value.

Because sometimes the first step toward bringing something back to life is understanding why it died.

Some projects deserve a second commit. 👻

Built for Hacktoberfest 2026, Week 4: Ghost in the Machine.