DEV Community: VidhiDixit2000

Turns out I'm the one making the ghosts💀

VidhiDixit2000 — Sat, 31 Oct 2026 22:43:09 +0000

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

On 8 August I committed a file called seed.sql. On 25 October I filled it in.

For 78 days it was zero bytes. Nothing ever told me🙃. The file existed. The import ran. The app worked. Only the data was missing — and an empty file doesn't raise an error. It just sits there being nothing, very quietly, for two and a half months.

I found out while deploying, a few days ago. So I built something to go looking for whatever else was in there.

What I Built?

Ghosts in the Machine reads a public repository's git history and finds failures that never produced an error — the ones nobody noticed, because there was nothing to notice.

Point it at a repo. It walks the commits, finds what broke silently, and an open-weight model groups it, ranks it, and writes up what happened.

   a public repo
        │
        ▼
 ┌─────────────────┐
 │  walk history   │   every commit, every diff
 └────────┬────────┘
          ▼
 ┌─────────────────┐
 │  rules          │   no AI. zero-byte blobs,
 │  (deterministic)│   credential-shaped lines
 └────────┬────────┘
          ▼
 ┌─────────────────┐
 │  oddness        │   no AI. size collapses, resurrected
 │  (deterministic)│   paths, diffs that don't match
 └────────┬────────┘   their own message
          ▼  findings, with commit hashes
 ┌─────────────────┐
 │  Gemma          │   did this break? which of these
 │  (open weights) │   matter? how do I explain it?
 └────────┬────────┘
          ▼
 ┌─────────────────────────────────────┐
 │  what the model made of it          │
 ├─────────────────────────────────────┤
 │  what git actually recorded         │  ← both shown, so you can
 └─────────────────────────────────────┘    check one against the other

When I ran it on my own repositories:

seed.sql — committed empty, filled 78 days later
requirements.txt — committed empty in the initial commit, filled 79 days later
readme.md — committed empty, by a commit whose message was "Add README"
A database password in three places in one commit, one of them commented out
A manifest.json, empty, which I later deleted without ever noticing it held nothing

Every one of those is mine. None of them ever failed.

How I read the theme??

The organisers suggested a haunted terminal and an offline oral history tool. I went elsewhere. I kept coming back to what a ghost actually is: something present, that nobody can see, that everyone has stopped looking for.

That describes a file committed empty exactly. It's in the tree. It's in every clone. It's in the history permanently. And because it never errors, nobody is looking.

The repository is the haunted house🏚️. The commits are the record of who lived there🧌🧟‍♀️. I just read the record.

Who this is for

The case I kept thinking about isn't mine. It's inheriting a repo.

You join a team, or pick up something abandoned, and you want to know: what's wrong with this that nobody is going to tell me?😟 The README is aspirational. The code is current. The history holds the real answers, and nobody reads 500 commits to find them.

Nobody hands over a project with a list of everything quietly broken in it. Partly because it would be awkward. Mostly because they don't know either. That's the whole point — these failures produced no error, so the person who made them is as unaware as the person inheriting them.

The same goes for open-sourcing something, or handing a repo to a client. What's in the history that shouldn't be? Secrets survive deletion, and people usually find that out afterwards.

Demo▶️

→ ghostsinthemachine.tech · also at ghosts-in-the-machine.onrender.com

Two exhibits load on arrival, from my own repositories. Paste in any public repo and it will read that one instead.

It's a free instance, so the first request after a quiet spell takes a moment to wake up👐🏻. Small and medium repos come back in under a minute. Large ones take longer, because cloning dominates🥲.

Code

→ github.com/VidhiDixit2000/ghosts-in-the-machine

How I Built It?

Two layers, deliberately separated.

The deterministic layer walks the history and emits findings. No🙅🏻‍♀️ AI. It checks whether a blob is zero bytes when the file extension implies content🔎, and whether added lines look like credentials🔎. Facts, with commit hashes attached.

The model layer answers a different question: which of these matter, which are the same story, and how do I explain them to a person? That's Gemma, via OpenRouter — open weights, hosted inference, so the demo runs without a GPU.

The split isn't tidiness. Each layer does what the other is bad at.

A regular expression can't tell you an empty file mattered. It has no idea whether 78 days is a long time. Ask a model to scan a whole history instead and it invents findings, misses real ones, and burns tokens doing it.

Here's the split earning its keep. One repo produced three separate findings: a connection string in database.py, a DATABASE_URL in docker-compose.yml, and a POSTGRES_PASSWORD in the same file.
Three true findings. One story — the same password, three places, one commit. The rules found them. Only the model saw they were one ghost.

On the page, both are shown. What the model made of it sits above what git actually recorded, so you read the narration and then check it against the hashes underneath.

That mattered more than I expected.

The model was confidently wrong, and I could prove it😏

While I was tuning⛏️ the narration prompt, Gemma 3 12B wrote this about the credentials:

These values... were removed from the working tree before the commit.
However, they remain present in the repository's history.

That's impossible!! Git history contains what was committed. If something was removed before a commit, that commit never recorded it — it wouldn't be in the history at all. The sentence contradicts itself🙃.

This was google/gemma-3-12b-it at temperature 0.3.

What actually happened: committed 30 July, removed 25 October. Nearly three months apart. The findings said so correctly. The model garbled them on the way to prose.

I only noticed because the evidence was sitting right underneath. If the narration had replaced the findings instead of sitting beside them, I'd have shipped a well-written falsehood about my own repository.

Moving to Gemma 3 27B and lowering the temperature🎨🌡️ fixed that particular error. But the architecture caught it, not the model choice.

If you're building on a model: test across versions and temperatures. A wrong answer at 0.3 looks completely reasonable until you check it against something that can't be wrong😂.

The mistake I made, and what I did about it👇🏻

I started by writing rules for failures I'd personally hit. Empty files, because of seed.sql. Leaked credentials, because of a .dockerignore I forgot and a password I thought I'd deleted by commenting it out.

Then I saw what I'd built: a tool that finds failures someone has already met. For a project about failures nobody noticed, that's close to self-defeating. A rule per failure type, forever♾️, and only ever the ones already on the list.

The way out isn't more rules. There are infinitely many. It's changing what the rules are for.

Git's vocabulary is tiny🤏🏻. A file appeared, vanished, changed, or moved. Its bytes grew or shrank. That's nearly all of it. So however many ways software can break, a failure has to express itself in that vocabulary to be visible at all — and it lands in one of a few shapes:

something got smaller when it shouldn't have
something vanished and came back
two paths that should have been one
a diff that doesn't match what its message claims
a change that undid an earlier change

Truncated JSON and a gutted requirements.txt are different failures with the same shape. A case-only rename and a resurrected file are different failures with the same shape.

So I added a second deterministic layer that names nothing. Six measurements: size collapse, a file too small for its extension, a resurrected path, two paths differing only in case, a large diff under a short message, a change that's almost all deletion. Each scores how unusual a commit is. The dozen oddest go to the model in one call, and the model says what — if anything — went wrong.

Like a metal detector. It doesn't know what a coin is. It knows there's metal here. Someone else digs.

The signal set is bounded by what git can record. What the model can name isn't.

Here it is working. On andela/buggy-python,
three commits long, the oddness layer flagged a .json file deleted inside a 14,000-line commit. Neither rule would have caught it — not empty, not a credential. It surfaced because it was strange.

And then the model explained it as an attempt to hide evidence.

Both halves of that sentence are the point.

It also found something in my own repository that I'd never have written a rule for🫢. My README describes GitHub Actions. No commit in the history implements them. The measurements only noticed that a large change arrived under a short commit message — they have no concept of documentation drift. The model read the change and named it🥹.

The narration varies between runs. A later run described the same two commits as a formatting change instead. The findings underneath don't move.

To be honest about it: those six measurements are still rules. The difference is how much each one buys.

My first rule — the one that looks for empty files — finds empty files. That is all it will ever find. But "this file lost most of its contents" isn't tied to any failure. It catches a truncated JSON, a gutted requirements.txt, a half-saved migration, a bad merge. One measurement, many failures, including ones I've never seen.

The rules didn't go away. They stopped growing every time software finds a new way to break quietly.

Why Open Innovation Matters

This tool reads your repository. Every commit, every diff, every line that ever held a credential. If it's going to do that, you should be able to read it back: what it looks for, what it sends to a model, what it redacts before sending. The code is public for the same reason the evidence sits beside the narration. A tool making claims about your history should be checkable.

Open weights meant I could reason about failure. When Gemma produced that impossible sentence, I could see which model, which version, what temperature, what prompt. I changed two of them and watched the failure go away. That's a debugging loop. Behind an opaque API it would have been a shrug.

What It Doesn't Do 🙅🏻‍♀️

Two named rules, six measurements. Most well-maintained repositories come back empty, correctly. The page says so rather than pretending otherwise.
It doesn't read a whole repository. Commit depth is capped, and the page tells you when a history was truncated.
Large repos are slow. Cloning dominates, not scanning.
The model reads intent into odd commits, until you stop it. On a repo called buggy-python, with a commit message reading "write buggy code", it described a deleted JSON file as an attempt to hide evidence. The measurement was right that something unusual happened. Everything after that was the model writing a story. Telling it not to speculate removed the story. Telling it not to invent sequence did not — until I stopped banning the words I didn't want and prescribed the ones I did.
The narration isn't stable. Same repo, same prompt, same temperature: one run called a deletion "possibly intentional experimentation", the next called it "a deliberate attempt to hide evidence". No code changed in between.
It still summarises badly. I could stop it inventing things. I couldn't stop it garbling them. In one run it wrote that a file was "added and deleted in the same commit" — and then, in the very next sentence, said the file had existed in an earlier commit. Both can't be true. The findings it was given said the right thing: added in one commit, deleted in a later one. The model had the facts and mangled them while squeezing them into two short paragraphs.
Secret detection is shallow next to dedicated tools. The quiet-failure half is where the gap is.

Every one of those is visible on the page, because the evidence sits under the narration. That isn't a coincidence. It's why the page is built that way.

The Spirit of It💪🏻🔥

I'm the kind of person who commits functionality in pieces. Somewhere in all that pushing, something ends up in a file that shouldn't be there. There are mistakes in every repo I've shipped that I'd only see if I stepped away, came back, looked properly, and went wait, what?

So I built something to look. It spent most of its time looking at mine.

The one that got me wasn't the empty files. It was the password. I'd found it weeks earlier — a connection string in database.py — and I commented it out, felt responsible, moved on. My own tool later showed me that same line, in a commit from July, with the # still on the front. The comment character meant nothing. Git had kept it the whole time, and so had every clone anyone had ever made.

Then the same password twice more, in a file I hadn't thought about. Three copies of one mistake, and I'd only ever found one.

Somewhere in there it stopped feeling like I was finding ghosts and started feeling like I'd been making them🙃😂.

The 78-day empty file is the one I tell people about, but it isn't really a mistake. Nobody did anything wrong. A file was committed before it had content, and there was no moment at which anything would have said so. It sat there, in every clone, for two and a half months, being nothing.

That's what I find unsettling about git. Your repository remembers everything you did and tells you none of it unless you go and ask. Every project I've shipped has things in it I don't know about yet.

Which means the next person to open one of my repos wouldn't know either. That part I hadn't thought about until I was looking at the output.

Building a ghost detector and finding five of your own is a strange way to spend a couple of days. I commit differently now😂.

Prize Categories🏅

Best Use of Gemma — Gemma 3 27B (open weights), served through OpenRouter, does all the judging, grouping and narration. The project does not work without it.
Best Use of Render — Render is the runtime: the web app and every inference call run from a single auto-deploying service.
Best Use of ElevenLabs — ElevenLabs generates the spoken introduction and the ambient room tone on the page.
Best Use of a .tech Domain — live at ghostsinthemachine.tech
Best Use of GitHub Copilot — a GitHub Actions workflow runs the tool against its own repository on every push, so the project is continuously scanned by itself. Recent runs.

The rest is Python, FastAPI and GitPython: history walking, the rules, the oddness measurements and the web app.

I followed Keploy's quickstart as a first-time user. Here's where it broke.

VidhiDixit2000 — Tue, 27 Oct 2026 06:23:27 +0000

A couple of months ago I came across a product called Keploy on LinkedIn. I went to their site to read about it, and the pitch stopped me: it writes your integration tests for you by watching your app run.
I went like --

And it did that by Not generating them from your code. Watching actual traffic. You run your app, use it normally, and Keploy records what came in and what went out. Later it replays those requests against your app and checks it still responds the same way.

I wanted to see whether that held up,

so I ran one of their Go quickstarts end to end on Windows through WSL. This is what it was like.

How it works

Integration tests usually mean keeping a database alive, writing mocks by hand, and updating those mocks every time a schema changes. It's a lot of upkeep for tests that mostly verify things you already know work.

Keploy's approach is to record once and replay forever. It supports several languages — I used one of their Go quickstarts because that's what I wanted to try.

When you start a recording, Keploy moves your app to another port and takes the original one for itself, so every request passes through it. At the same time, an eBPF probe watches the syscalls your app makes to the database.

RECORD
  your curl  ->  Keploy (:8082)  ->  app (:35555)  ->  Postgres
                      |                                   |
                  test case                             mock

REPLAY
  Keploy  ->  replays recorded request  ->  app  -X-  Postgres
                                             |
                                     answered from mocks

So one recording run captures two things: the HTTP exchange becomes a test case, and the database exchange becomes a mock.

On replay, your app starts and runs for real — your router matches the path, your handler executes, your code does its work. Only the database calls are faked, answered from the recording. Postgres never gets touched.

Because the probe sits outside your code rather than inside it, you don't import a library or change a line of your app. That's also why Keploy needs sudo, and why it only runs on Linux — hence WSL on Windows.

What I built

Their quickstart docs offer several Go samples. I picked Echo + Postgres — a URL shortener.

The setup is: install the CLI, start Postgres in Docker, build the app, and run it under keploy record. Then you just use the API. I made two curl calls — a POST creating a short URL, and a GET following it. Both became test cases, written to keploy/test-set-1/, with the Postgres exchanges saved alongside them as mocks.

A few small things didn't match as I went. The docs site, its screenshots, and the binary I installed were on three different versions. The README pointed at a line number that had moved — and the quickstart pointed at a different wrong one. A flag the docs use had been removed. The quickstart skips a login step that everything after it depends on, so the first failure is a 401 timeout that never mentions authentication. None of these are dramatic on their own, but following instructions literally means hitting each one and stopping to work out why.

Then I hit a real one.

What I'd fixed first, and what actually broke

I ran the test command straight from the docs. Keploy started my app, and then the run died.

The errors talked about the app being unreachable and the database connection failing. So I went looking at Postgres, at ports, at the binary — all of it fine.

The real cause was a folder I'd never opened. The sample repo ships with a test-set-0 already committed, recorded by someone else a long time ago. My own recording had created test-set-1. Without naming a test set, Keploy picked up both and started with theirs.

Its mocks were in an older format that the current version can't read — eighteen failed to unmarshal errors. With no mocks loaded, nothing answered my app's startup database ping, so the app exited. And with the app gone, the whole run collapsed. My two tests were never reached, let alone run.

--test-sets test-set-1

One flag, and it skips theirs entirely.

Then a smaller oddity: with that flag everything passed, but the summary still reported "across 2 test-set(s)" and threw a red error about a missing report for test-set-0 — a set that never ran. The filter controls which tests execute, but not what gets counted.

What convinced me

COMPLETE TESTRUN SUMMARY.
      Total tests: 2
      Total test passed: 2
      Total test failed: 0
      Total time taken: "10.09 s"

And higher up in the log:

{"testsRan": 2, "mocksConsumed": 4}

Four mocks consumed. My app pinged the database, created its table, and ran both queries — and Postgres answered none of it. Every one of those calls came from the recording.

That's the whole idea in a single line. Real code running, real database work happening, no database.

Where it fits

Keploy is most useful when you already have a working service and want regression coverage without maintaining a pile of database mocks by hand. The recorded traffic gives you a practical starting point — but it doesn't replace deliberately testing paths you haven't exercised. If you never send a request through a particular part of your app, Keploy can't record a test for it.

I wrote up the full walkthrough here — every version mismatch and workaround, in the order you'll hit them. If you're going down the same path, it should save you some time.

My app could read the database. pgAdmin couldn't. Both were pointing at "localhost:5432"

VidhiDixit2000 — Thu, 27 Aug 2026 08:04:06 +0000

I was running a FastAPI app in Docker with a PostgreSQL container next to it. The app worked. It wrote rows, it read them back, everything behaved.

The database itself, fastapi-db, was one I'd created inside the dockerised PostgreSQL — the container defined in my compose file. My app had created the products table in it and was happily writing rows.

Then I opened pgAdmin to look at that data directly, connected to localhost:5432, and found nothing. No fastapi-db. No products table. Just postgres, template0, template1 — the default databases of an empty install.

So my application was clearly talking to a database. pgAdmin was clearly talking to a database. They weren't the same database.

What I assumed first

My first thought was that pgAdmin wasn't refreshing, or that Docker wasn't persisting anything. Both wrong, and both cost me time.

The thing that actually settled it was running this in pgAdmin's query tool:

SELECT version();

It came back with:

PostgreSQL 18.4 on x86_64-windows

Windows. Not the Linux build that would be running inside a container. pgAdmin was connected to a PostgreSQL I'd installed on Windows months earlier and forgotten about — one that was running as a background service the whole time.

To confirm who owned the port:

netstat -ano | findstr :5432

That returns the PID holding the port, and it belonged to the Windows PostgreSQL service. It had claimed localhost:5432 at boot, long before Docker was involved.

The part I'd misunderstood

Here's what I hadn't grasped: my app and pgAdmin were reaching the database over two completely different routes.

Inside Docker Compose, containers reach each other by service name on the Docker network:

fastapi-container  ───►  postgres-db:5432

That never touches the host machine's ports at all. It's container-to-container, resolved by Docker's internal DNS. Which is why my app worked perfectly and gave me no hint anything was wrong.

pgAdmin runs on Windows, outside Docker. It can only reach the container through a published port — the host-side mapping in the compose file:

localhost:5432  ───►  (published port)  ───► container:5432

And localhost:5432 on my machine was already spoken for.

So one path was working fine and the other was quietly landing somewhere else entirely. Same port number in both places, two unrelated destinations.

The fix

Change the host side of the mapping so it doesn't collide:

ports:
  - "5433:5432"

The two numbers do different jobs, and this is the bit worth internalising. The left one is the port on your machine. The right one is the port inside the container. Postgres inside the container is still listening on 5432 and doesn't need to change — only the door on the outside moves.

Then a new pgAdmin connection to localhost:5433, and fastapi-db appeared immediately — the database I'd created inside the container, with the products table and the same rows my app had been writing all along.

My FastAPI config didn't change at all. It was still using postgres-db:5432, because it was never going through the host in the first place.

A smaller thing that had also confused me

pgAdmin's sidebar shows a tree called Servers, and I had two entries under it. I assumed that meant two PostgreSQL server processes.

It doesn't. In pgAdmin, a "Server" is a saved connection profile — a stored host and port. Two entries means "I know how to reach two PostgreSQL servers," the same way two contacts in your phone don't mean two phones.

That's why one of mine showed a red X. The server wasn't gone; pgAdmin just wasn't currently connected to it.

What I'd tell past me

If a containerised app can see its database and your GUI client can't, don't start by suspecting your app. Ask which database each one is actually reaching. Two commands answer it:

SELECT version();

netstat -ano | findstr :5432

The first tells you what you're connected to. The second tells you who owns the port.

And the general lesson, which took me longer than it should have: inside Docker and outside Docker are two different networks. Containers reach each other by service name and never touch your host's ports. Everything else — your GUI client, your browser, curl — can only get in through a published port, and that port is competing with every other thing installed on your machine.

Same number, different world.

The import that worked for months and broke on my first deploy

VidhiDixit2000 — Wed, 26 Aug 2026 19:40:00 +0000

Could not resolve "../styles/Randomfacts.css" from "src/pages/Randomfacts.tsx"
Error: Command "npm run build" exited with 1

This was my first deploy to Vercel, and my first thought was that I'd broken something in that commit.

I opened Randomfacts.tsx and found it importing Randomfacts.css — capital R. Then I checked the actual file sitting in src/styles/, and its name was randomfacts.css, lowercase.

So the import was wrong. Fine. But that raised a much more confusing question:

Why had npm run build never thrown this error on my machine?

The actual cause

Windows filesystems are case-insensitive. Ask for Randomfacts.css when the file is called randomfacts.css and Windows hands it over without comment. Both spellings resolve to the same file, so the mismatched import worked locally for months.

Vercel builds on Linux, which compares filenames byte for byte. There, R and r are genuinely different names — and the one my import asked for didn't exist.

Same code, same import, two different answers. The operating system answered, not the bundler.

The fix

I matched the import to the real filename. Then a Windows wrinkle worth knowing: a case-only rename won't be recorded by git, so if you rename the file instead of the import, it takes two steps.

git mv src/styles/randomfacts.css src/styles/temp.css
git mv src/styles/temp.css src/styles/Randomfacts.css

How to catch these before the build does

Use git ls-files rather than ls. It shows the name git actually recorded, which is what the build server checks out — your local filesystem will happily lie to you here.

git ls-files src/styles/

Compare that output against your imports. Any casing mismatch is a build failure waiting for your next deploy.

What I took from it

There's a whole class of bugs that only exist when your deploy environment differs from your development one. Case sensitivity is the most common. Path separators and missing environment variables are close behind. None of them are visible while you're only running things locally, and none have anything to do with your logic being wrong.

I'd been building this project on and off for months — adding functionality in bursts, brushing up on different concepts along the way — and only hit this on the first deploy. It would have taken ten seconds to spot if I'd deployed at the start.

That's the real lesson for me. Deploy early, even when the project isn't finished. Not for the URL, but because the deploy environment finds a category of bug that your machine structurally cannot.