A 16,000-line Rust parser written by Claude that the author never read
PostHog's Robbie Coomber replaced a C++ ANTLR SQL parser with 16,000 lines of Rust he says he never wrote by hand. The trick: the old parser became an oracle, and a fuzzer fed Claude failing cases until the two agreed on millions of queries.
The old parser interpreted an ANTLR grammar at runtime; the Rust rewrite is a recursive-descent parser with a Pratt expression core. It ran 70x faster on a laptop and 454x faster in production, with zero divergences across millions of shadow-mode queries.
The thread calls it the anti-vibe-coding playbook: an engineer who builds the same oracle setups says you can generate corpuses large enough to trust code you never read. A skeptic asks the question nobody answered: why not compile the grammar instead of fuzzing a code generator into agreement?
A rewrite where the human never touched the code
PostHog transpiles user SQL into ClickHouse SQL while enforcing access controls. The old engine was a C++ parser built on ANTLR, which walks a grammar-derived tree at runtime and pays for that generality. Robbie Coomber's rewrite is 16,000 lines of hand-rolled Rust plus 5,000 lines of tooling, and his framing is blunt: "I didn't write any of the code by hand."
The method is a closed loop. The existing parser is the oracle: any SQL where old and new disagree is a bug to fix. A custom generator built from the ANTLR grammar produces property-based test cases, a fuzzer runs constantly in the background writing failures to a file, and production logs supply real queries. Claude consumes the failures and rewrites the parser to match. It resisted: it "made a lot of mistakes, kept doubting whether such a rewrite was even possible," and one of the most effective nudges was telling it to "think really hard about edge cases" in a background agent. The payoff was 70x on a laptop, 454x in production, and zero divergences after roughly 50K queries in tests and millions in shadow mode.
Is this the model for AI engineering, or a smart compiler we refused to write?
The thread treats this as a template rather than a stunt. An engineer who builds the same kind of setup for energy-grid software said the oracle is what makes it trustworthy.
"I've had very good success in similar setups where you have some sort of 'oracle' and can generate enormous corpuses of test data, such that you really, really trust the LLM code must work for the inputs you expect." — an engineer who previously built databases at Neo4j
A commenter who had earlier predicted coding would become rigorous vibe-coding pointed to this as the proof.
"Deep technical expertise is still needed, but it shifts from working with the code directly to crafting bespoke comprehensive validation mechanisms around the code… once vibes are rigorously enforced are they 'vibes' anymore?" — a commenter who predicted this shift in an earlier thread
The sharpest dissent reframes the entire exercise as a category error. The maintainer of sql.js asked why an existing fast parser wasn't used at all, and another developer pushed the question further.
"You have a grammar file in a formal language, and want to generate a faster parser in another formal language. What's wrong with… a sufficiently smart compiler from the source to target languages?" — a developer who likened it to replacing GCC with a fuzzer
That is the unresolved tension under the applause: the loop fuzzed a stochastic generator into agreement with a known grammar, a problem compilers solve deterministically. The result shipped and the numbers are real, which leaves a more uncomfortable implication than the headline speed-up: the cheapest path to a correct parser is now to never specify it, only to test it.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Hoffman calls SpaceX 'the IAC of AI', buying its way into relevance
Reid Hoffman says SpaceX isn't an AI company despite an AI-central IPO, and reads its Cursor purchase days after going public as proof of absence, not strength.