A Rust clone of pylint, byte-for-byte identical, built almost entirely by an AI agent

A linter that copies pylint's bugs on purpose

prylint is a Rust reimplementation of pylint with an unusual selling point: it doesn't try to be better, it tries to be identical. The page is blunt about it — "prylint is not 'inspired by' pylint" but a bug-for-bug port. Where pylint emits a warning, prylint emits the same warning. Where pylint crashes, prylint reports the same crash message. The claim is byte-for-byte identical output, verified across 52 production codebases and roughly 65,000 Python files.

The payoff is speed. The headline range is 15–2300x faster, median around 85x, and the big repos are where it shows:

The other unusual part: it was produced by Fable, an agentic coding system, over months of iteration rather than hand-written by a person. That detail, more than the numbers, is what lit up the thread.

The top comment: "is this project legit?"

The highest-rated reply went straight to the repository.

"Looking at GitHub, all the commits are by Claude, and otherwise, adamraudonis doesn't seem to have any connection to anyone else… this post seems more like a kind of malware SEO. Is this project legit?" — the commenter who checked the commit history

A reader with 10k+ karma zeroed in on the README's own wording as the tell:

"As always, three lines in you realize that the doc you're reading hasn't been written (maybe not even read) by a human. So so tired of this breach of trust." — a long-tenured HN reader

"Ruff already exists" — the redundancy objection

The second knock had nothing to do with how it was built. pylint's checks already ship in Ruff, the fast Rust linter most teams have moved to.

"So basically ruff check --select=PL but worse in every single way, maintained by a system that's not even available anymore? It even uses Ruff's code under the surface." — an HN reader with 11k+ karma

Fable itself, several noted, is no longer accessible — so the tool's author is a system you can't even run today.

The counter: "results are speaking for themselves"

Then the reversal. A developer pushed back on the whole frame — that code is somehow tainted by how it was written.

"Writing software is not a sport that if you 'cheat' using tools then your results are worthless… Unless you can provide a failing test case that the software presented here fails at, then your arguments for 'how' it was made is moot." — a developer who builds with agentic coding

His point lands harder here than for most AI-built projects: a linter has a deterministic oracle. If the output diffs against real pylint, you've found the bug. The fidelity is checkable, not vibes.

The strongest evidence came from someone who'd done the same thing by hand. An engineer described porting the unmaintained djlint HTML/template linter to Rust with LLM help — not one-shot, but byte-for-byte compatible:

"The Python version was heavily regexp-based… For the Rust version, I switched it to properly tokenize the files and then match rules on the AST in a single pass… it took about 4 minutes to run [before]; the Rust version runs on the same code in a fraction of a second." — an engineer who ported djlint to Rust

Another reader recounted handing Fable an unrelated migration — nix+npm to docker+pnpm — on a stack the team didn't understand, and watching it "damn-near one-shot it," then stress-testing for a week and finding little wrong.

Why ports are the easy case for agents

The quietly important takeaway sits between the two camps. Several engineers noted why this class of task suits an agent so well: the existing program is a precise spec, the tests are a free oracle, and the model can iterate against a deterministic ground truth until the diff is empty. That makes "rewrite X in Rust" the rare AI task where the skepticism — who wrote it? — is answerable by a test run, and the redundancy question — why, when Ruff exists? — is the one that actually stings.