The bug that doesn't look like a bug
AI-generated code has a specific, boring failure mode: it calls something that doesn't exist. pd.read_exel() instead of pd.read_excel(). A method on a payments library that got renamed two versions ago. An import from a package that got restructured last year. The code reads perfectly plausible, because the model has seen a thousand real examples of code shaped exactly like it — and it fails the moment it actually runs, not before, because nothing about the syntax is wrong. Only the reference is. It's pointing at something that isn't there.
FixProve checks that reference against what's actually installed on your machine, before any of it merges. No AI model involved in the check itself — just a straightforward comparison between what the code claims exists and what's really there.
How it actually works
Here's the plain version: FixProve reads your code the way a compiler does, then builds a map of everything your project's real, installed dependencies actually provide — not what a training set half-remembers them providing from some snapshot months ago. Every import, every method call, every attribute your code touches gets checked against that map. If something doesn't resolve, that's a finding: the file, the line, the exact piece of code that doesn't exist.
Run it twice on the same code and you get the same answer twice. That's the whole design philosophy in one sentence. A linter that sometimes catches a fake import and sometimes doesn't (depending, apparently, on how the model was feeling that day) isn't really a safety check. It's a suggestion with a badge on it. This is meant to be a gate, not a suggestion.
It covers Python and TypeScript/JavaScript, installs as a normal command-line tool (pip install fixprove or npm install -g fixprove), and can run automatically as a check on every pull request. Only the findings — file, line, the broken reference — ever leave your machine. Your actual source code doesn't.
What I can actually back up
217 tests pass in continuous integration, checked against a small labelled set of real examples with measured precision and recall. I want to be upfront that this test set is small — a handful of known-bad files and a handful of clean ones, for both Python and TypeScript — so treat the numbers as proof the mechanism works correctly, not as a benchmark of how it performs across the wild variety of real-world code out there.
The releases themselves are provably what they claim to be: both the npm and PyPI packages are built and signed automatically through GitHub's identity system, not published by hand from someone's laptop with a token sitting in a config file somewhere.
I also keep a running list of every real bug found in this project and fixed — seventeen of them across the first ten working sessions, each one logged with what broke and how it got caught. I'd rather show you that list than a highlight reel. A tool whose whole job is catching mistakes should be honest about its own.
What it isn't yet
There's a version of this that runs automatically on someone else's pull request — built, tested, and not yet open to the public. I'm not going to claim adoption I don't have. What you can install and run today is the command-line tool. The automated version is the next milestone, not a shipped one, and I'd rather say that plainly than let the distinction blur.
Try it
pip install fixprove or npm install -g fixprove, then fixprove check /path/to/your/project. Free, and it takes about a minute. Details at fixprove.dev.