work / bug detection
Catching code that lies about itself.
Regex catches the shallow mistakes — undeclared variables, unused imports. AST traversal catches the ones with structure, where the code quietly contradicts itself. It runs inside the editor rather than in CI, because a warning is only useful while the mistake is still on screen and the reason for it is still in your head.
20+ bug classes · 89% on the repos I tested · regex + AST · VS Code extension
prototype · python / javascript
the idea
Most bugs are cheapest to fix in the ten seconds after you type them. A variable you never declared, an import you never use, a branch that can never run — these are all visible in the source the moment they exist. The tool's whole premise is to close that gap: analyze the code statically, at the moment it's written, in the editor where it's written, instead of waiting for a test run or a review to surface it.
So it became a real-time VS Code extension rather than a script you remember to run. You type, it reads, and if something is wrong it says so right there — a live syntax alert with a fix recommendation attached, not just a red squiggle you have to decode.
how it works
Two layers of analysis, because neither is enough alone. Regex passes are fast and catch the shallow, textual mistakes cheaply. AST traversal does the structural work — walking the parsed tree to find the bugs that only exist as relationships between nodes: a name referenced but never bound, an import that no path of the tree ever touches, logic that contradicts itself. Between the two layers the tool covers 20+ distinct categories of bugs and security vulnerabilities across Python and JavaScript.
On the test repositories I evaluated it against, it caught undeclared variables, unused imports, and logic flaws with 89% accuracy. That number deserves its qualifier: it's a test-repo figure, measured on code I chose to measure against, not a claim about arbitrary codebases in the wild. It's the honest size of the number, and it's still the number I'm happiest with — static analysis that's wrong too often gets muted, and a muted linter is furniture.
the other 11%
A number like 89% is only interesting if you say what the remaining 11% is made of, so: it is not one pile. It is two, and they cost completely different amounts.
Misses are the cheap failure. The tool stays quiet, you are no worse off than with no tool, and the bug gets caught by whatever would have caught it before. False positives are the expensive one, and not because of the seconds they waste. A linter that cries wolf gets muted, and a muted linter is worse than an absent one — it occupies the slot a working check would have had, and everyone believes the code is being watched. So the tuning is deliberately asymmetric: when the two layers disagree and I have to pick, I would rather ship a miss than a false alarm.
The place the layers disagree most is scope and reachability. Regex sees text, so it cannot tell a function call from the same characters inside a string literal, a comment, or a docstring — three of the most common false-positive sources in any pattern-matching linter. The AST pass knows the difference because the parser already threw the text away and kept the structure. Conversely, regex catches malformed code the parser simply refuses to accept: if it will not parse, there is no tree to walk, and the structural layer has nothing to say about the file most in need of help. Each layer covers the other's blind spot, which is the actual reason for running both rather than picking the "better" one.
The honest ceiling is older than this tool: statically deciding whether an arbitrary branch can ever run is undecidable in the general case. So "unreachable code" detection is a set of sound heuristics, not a proof, and anything claiming otherwise is selling something. Knowing which of your checks are decidable and which are heuristics is the difference between a tool you can trust and one you have to babysit.
why it's on this site
This whole site is built on not letting things misreport their own state — statuses stay honest, dead projects say dead. A tool whose only job is to catch source code claiming to be something it isn't (declared, used, reachable) is the same instinct pointed at software. I'll say that once and leave it there.