I wrote a 70x faster SQL parser while barely looking at the code

PostHog needed a faster SQL parser. Not a nicer one, not a more maintainable one — just faster, because every query a customer runs through their product analytics or session replay tools has to pass through this thing first before it gets transpiled into ClickHouse SQL. The old parser was built with ANTLR, a solid and widely trusted parser-generator that turns a grammar file into working code. It's flexible and battle-tested, but that flexibility comes from a generic graph-walking interpreter, and a generic interpreter is never going to beat a hand-rolled recursive-descent parser built for one specific job.

So the author tried something that would've sounded reckless two years ago: have Claude Code write a new parser by hand, in Rust, with almost no human-written code. Two parallel approaches were tested — one optimized purely for speed with a Pratt-style expression loop, the other designed to mirror ANTLR's own behavior as closely as possible to maximize the odds of actually working. Both ended up performing similarly well, which nobody could have predicted going in.

The real engineering wasn't the parser itself, it was proving the parser was correct. The team used the existing C++ parser as an oracle and ran property-based testing with Hypothesis, generating oddball SQL queries specifically designed to break agreement between old and new. They even had to build a second parser — for ANTLR's own .g4 grammar files — just to feed Hypothesis realistic inputs. Claude kept patching bugs with narrow, brittle fixes, like adding one token of lookahead when two were actually needed, until the author started forcing it to reload the grammar file and reference C++ source before every fix. That one prompting tweak apparently saved days.

Eventually the setup ran nonstop in the background: fuzzing engines constantly generating failing cases, Claude picking them up whenever it was idle, coverage-guided generation steering tests toward unexercised grammar paths. After testing against roughly 50,000 real production queries with zero mismatches, they ran the new parser in shadow mode against live traffic. Millions of parses later, still zero divergences. They flipped 0.1% of production traffic to the new parser within a couple of hours of starting the shadow test, which is a wild level of confidence for something entirely AI-written.

The payoff: 16,000 lines of hand-rolled parser code, 5,000 lines of tooling, and an average 454x speedup on real production queries, with a 70x figure from local benchmarking. The final architecture is a predictive recursive-descent parser with a Pratt core and selectively widened lookahead — the kind of design a human expert might spend months getting right. Claude Opus 4.7 wrote it in May 2026, and the author, despite not writing the code by hand, insists this wasn't 'vibe coding' at all. The rigor came from the testing harness, not the prompting.