His instructions scream 'DO NOT PARSE ANYTHING MANUALLY.' Claude tries anyway
The fix isn't a better prompt. The author wraps the model in Ragel-generated parsers and lets it script its own guardrails in JavaScript, so the next time Claude reaches for manual parsing, deterministic tooling has already done the job.
The post's thesis: LLMs are "brilliant but clumsy," so wrap that non-determinism in formal tooling. Ragel spits out a 10,000-line correct parser instantly; Claude, told in all caps never to parse by hand, does it anyway, and once committed a build/ directory twice.
The sharpest reply says he misnamed the problem: an LLM's trouble was never determinism. Its input is natural language, which was never formally defined, "words have meaning," and no parser generator can replace the layer that guesses what you meant.
Sandwiching a "brilliant but clumsy" model between deterministic layers
The post, from the developer building the Beagle SCM version-control tool on top of Claude, starts from a frustration anyone who has paired with an LLM will recognize: the model is brilliant and clumsy at the same time. The prescription is architectural, not motivational: "Sandwich that brilliant but inconsistent non-determinism between powerful deterministic tools and equally formal processes."
The running example is parsing. Ragel can emit a 10,000-line, formally correct parser "in an instant, deterministically"; Claude, handed a job it should delegate, keeps reaching for manual string-wrangling even though the instructions shout, in all caps, "DO NOT PARSE ANYTHING MANUALLY, EVER." It tries anyway. The clumsiness shows up in dumber ways too, like the time the model committed a build/ directory twice. Beagle's fix is to let Claude script its own routines in JavaScript around the heavy C lifting, then watch for repetition: if the model repeats some sequence of actions too often, that sequence gets automated away.
"Why are we handing deterministic processes to probabilistic systems?"
The loudest agreement arrived with a sharper edge than the post itself.
"why the fuck are we handing deterministic processes to probabilistic systems when it should be the other way around … LLMS should be abstracted out of a process as soon as practicable … Otherwise you've built the world's most fragile process at the mercy of token cost, vendor hostility, geopolitics, and model deprecation." — an ops engineer who'd had LLMs forced on him at a previous job
An idea from the 1980s, waiting on a cheaper laborer
John Nagle set the approach in a longer arc: formal proof of correctness is decades old, and the bottleneck was always human patience.
"Formal methods, as in proof of correctness, have been around for decades … The seL4 verification effort reportedly used over a decade of people time. The idea is that if you have a formal specification of what you want to happen, you can get a LLM to do the struggling with the proof system to get it right. It's a good task for an LLM, because there's feedback from the prover." — John Nagle
His caveat became the thread's refrain: "I'd like to see more non-trivial examples of this. People keep republishing verifications of greatest common divisor or stack algorithms, which was done decades ago."
The part the essay skips: does it actually work?
The most-repeated criticism wasn't philosophical. It was that the piece is all setup and no demo.
"This is a very interesting introduction to a blog post, but … I'm somehow missing the actual blog post. How does this stuff work in practice? What are some concrete examples?" — a reader who went hunting for the how-to
"There's a Cambrian explosion of promising-sounding AI tools, all of which seem to work reasonably well for their authors, but it's unclear which ones to try … what we're missing are in-depth product reviews?" — a retired software engineer
Others supplied the missing examples from their own repos. An Elixir developer wired a test to fail the instant anyone imports Logger, printing a short lecture on emitting OpenTelemetry events instead. Another refactors C# by making the model write a Roslyn transformation rather than edit the code directly, so a wrong result breaks loudly instead of hiding as a subtle bug.
Or maybe the diagnosis is wrong
The sharpest dissent argued the whole framing is mislabeled.
"that has nothing to do with non-determinism the author is talking about. Model's input is in natural language which isn't formally defined … You can make model outputs deterministic, but this won't solve your problem because it's not about determinism … Words have meaning." — a commenter who separated deterministic output from the actual problem
And a veteran shrugged at the novelty of it all:
"20 line bash scripts replacing entire enterprise software stacks was a meme even in the 90s." — an engineer at NCR
That is the quiet tension under a thread that mostly nods along. The move, wrap the model and automate its repeated mistakes, is hardening into consensus, endorsed by an ops lifer, by John Nagle, and by the Roslyn and Elixir tinkerers alike. Yet the one thing nobody produced, the author included, is a non-trivial case where it carried real weight past a toy parser or a greatest-common-divisor proof. The technique is being canonized faster than it is being demonstrated.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
A blogger calls AI note-takers a creepy third person. HN says that's a secretary
Told an AI would transcribe their physiotherapy session, the author said they minded. The physio nodded and wrote notes by hand, and the post's stance is that if that felt awkward, the awkwardness wasn't theirs to carry.