DEADBYTE — An AI Archaeologist for Abandoned Software

A developer built DEADBYTE, a local-first AI archaeologist that investigates abandoned and legacy software projects without executing their code. The tool scans a repository, collects traceable evidence from source, comments, dependencies, logs and config files, then uses a local Ollama model (qwen3.5:9b) to interpret that evidence and write a Markdown case report, with a --no-ai mode available. Evidence collection is deliberately kept separate from AI interpretation so the model interprets findings rather than inventing file locations.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine https://dev.to/challenges/hacktoberfest-week4-2026-10-26 What happens when software is abandoned? Repositories become inactive. Dependencies disappear. APIs become obsolete. Documentation gets outdated. Eventually, the people who understood the system move on, leaving behind fragments of what once worked. I built DEADBYTE , a local-first AI archaeologist that investigates abandoned and legacy software projects. The idea behind the project was to interpret Ghost in the Machine quite literally: software may be dead, but its source code, comments, dependencies, error logs, and configuration files still contain traces of its past. DEADBYTE examines those traces and attempts to reconstruct the story. It can: The goal isn't to pretend that AI can know why a project was abandoned. Instead, DEADBYTE tries to distinguish what the evidence actually shows from what might merely be a hypothesis. Think of it as digital archaeology, with a little horror mixed in. Watch the demo video to see DEADBYTE investigate a sample legacy project, collect evidence, generate AI-assisted findings, and produce a structured investigation report. The complete source code is available on GitHub: Every program leaves behind a ghost. DEADBYTE is a local-first AI archaeologist for abandoned and legacy software. It scans a project without executing it, collects traceable evidence, asks a local Ollama model to interpret the evidence, and writes a Markdown case report. --no-ai qwen3.5:9b if available in your catalog ollama pull qwen3.5:9b python -m venv .venv .\.venv\Scripts\Activate.ps1 python -m pip install -e ". dev " deadbyte doctor deadbyte investigate .\examples\haunted project --model qwen3.5:9b Without AI: deadbyte investigate .\examples\haunted project --no-ai Reports are saved under deadbyte cases/<case-id / . DEADBYTE does not execute project code, build scripts, or installers. It skips common generated directories, binary files, symlinks, and obvious secret files. AI mode sends selected evidence to the configured Ollama endpoint … I wanted to build something around open-weight AI that would do more than simply send prompts to a hosted API. The core stack: The architecture follows a fairly straightforward pipeline: One important design decision was to keep evidence collection separate from AI interpretation. The scanner and extractors determine where evidence comes from. The model interprets that evidence rather than inventing file locations. Another important decision was not to execute the investigated project's code, build scripts, or installers. DEADBYTE is an investigative tool, not a sandbox. Open innovation made this project possible in a way that aligns with its purpose. I could build around an open-weight model, run inference locally through Ollama, and experiment with the analysis pipeline without depending on a proprietary hosted AI API. This gives the project several advantages: It also means developers can investigate software while keeping the inference workflow on their own machine, provided they configure Ollama locally. For a project about preserving the history of abandoned software, building on open technologies felt particularly appropriate. The most interesting part of DEADBYTE isn't simply finding deprecated dependencies or outdated APIs. It's the idea that a repository can tell a story even when nobody is maintaining it anymore. Imagine opening an old project and finding: These are fragments of a system's history. DEADBYTE attempts to bring those fragments together into an investigation. And when it finishes, it leaves you with a final transmission. Not a real message from a ghost, of course. Just a reminder that abandoned software isn't necessarily empty software. Somewhere in the code, something still remembers.