Build1 distinct publisher3 min readUpdated
A production walkthrough puts extraction on Haiku and cross-source checking on Sonnet. The tier boundary is what bounds bad data, and the article's own cache-hit guard cannot fire.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two different things are being called validation here, and only one of them costs a model call. The API-layer kind is a shape guarantee: `messages.parse()` with a Pydantic output format hands back a validated object instead of a string you hope survives `json.loads()` [6]. That removes the code-fence class of bug for free. It says nothing about whether the number inside the object is true.
The truth-shaped kind lives at L2, which reconciles a record against other sources and checks it for consistency [3]. That placement is the design. The layer that catches a cheap model's confident error needs more headroom than the cheap model, so the validation boundary sets a floor under mid-tier spend: you can route volume down to Haiku precisely because something above it is paid to disagree. Make L2 the same model as L1 and you have not economised on validation, you have deleted it, and the symptom is a run that gets cheaper while the brief gets worse [5].
L3 is not a backstop. It reasons across whatever L1 and L2 handed up and writes the recommendations [4]. Anything false that clears L2 reaches the most expensive model in the stack and leaves it phrased as advice, which is the propagation the author opens with: one agent's hallucination becomes the next agent's input [1].
The cost side is worth checking against the code rather than the prose. Ninety percent off the shared prefix [15] holds only while the prefix keeps matching, and the stated failure mode is a volatile value such as a timestamp or unsorted JSON breaking it [11]. The guard offered is `assert response.usage.cache_read_input_tokens >= 0` [11]. A token count is never negative, so that line passes on every call, including the zero-hit calls it exists to catch [16]. The comment describes the check; the code does not implement it. What you want is that count logged per call with an alert when it drops to zero on a prefix that should be warm, because the same context repeats across hundreds of L1 and L2 calls in a single run [10] and a silent miss surfaces only on the invoice.
On provenance: this is one operator describing his own stack, which he says runs his company [12], with no error rates or per-run costs given. The model identifiers are constants in his file [13], so treat the version strings as local and the tier boundaries as the portable part. The retry setting is his choice too rather than a default, since the SDK already backs off on connection errors, 429s and 5xx, and he raises `max_retries` to 5 so a transient blip does not kill a long run [8].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author states that most multi-agent demos fail on real data because one agent's hallucination becomes the next agent's input, and costs balloon because every step runs the most expensive model.
L1 is extraction and routing: pulling structured fields from raw source data, classifying records, deciding what goes where; high volume, shallow reasoning, assigned to Haiku.
L2 is processing and validation: reconciling data across sources, checking it for consistency and enriching it; described as real work but not deep multi-step reasoning, assigned to Sonnet.
L3 is synthesis: reasoning across everything L1 and L2 produced to write the brief with recommendations, using the best model with extended reasoning turned on, assigned to Opus.
The author writes that defaulting every layer to Opus is the most common way to burn money for no quality gain, and defaulting everything to Haiku is how you get a fast, cheap, confidently-wrong report.
Asking a model for JSON in a prompt and then calling json.loads() on the result is described as the fastest way to make a pipeline flaky; client.messages.parse() with a Pydantic output_format returns .parsed_output as a validated typed object rather than a dict you have to trust.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Runnable code, no measurements
The mechanism claims are concrete and inspectable — tier assignments, model identifier strings, messages.parse() with a Pydantic output_format, cache_control ephemeral placement, max_retries=5 — but every reliability and cost assertion rests on one self-published author with no error rates, cache-hit rates, per-run costs, or corroborating source. One shipped verification step is demonstrably inert, which lowers the credibility of the 'holds up in production' framing.
One self-reported deployment
Supplied material shows exactly one deployment: the author's own company-operating pipeline, disclosed without metrics, plus the specific Claude tier identifiers it uses. There is no third-party usage, customer, download, or benchmark evidence in the cluster, so adoption registers as a single anecdote rather than a pattern.
Reasoning outruns the receipts
The title and framing promise patterns that 'hold up in production' and a system that runs a real company, but nothing measurable substantiates that: no error rates, no cache-hit data, no costs. The gap is moderate rather than severe because the design argument is internally coherent and the code is specific and reviewable. The inert cache assertion is the sharpest marker of overstatement — the article claims a verification habit it does not actually implement.
Practitioner credibility building
The piece is self-published developer content whose authority rests on the author asserting he runs a production system operating his own company — a reputational and audience-building incentive that also explains the confident production framing without disclosure of numbers. Nothing in the supplied material shows vendor sponsorship, paid placement, or a product being sold, so the incentive is mild and disclosure-adjacent rather than a conflict.
Design reasoning solid, outcomes unverified
Confidence is moderate: the descriptive claims about what the article says and what its code does are directly verifiable at high confidence, including the logically inert assertion. Confidence is limited on everything external — SDK retry semantics, cache pricing ratios, model identifier validity, and whether the tiering actually produces the claimed reliability — because a single practitioner source carries all of it.
build
A goal that writes itself into SOUL.md: agent memory is now an attack surface1 distinct publisher
security
A paragraph beat the agent "mind virus": reading the Anthropic-EPFL preprint as a defensive win1 distinct publisher
invest
Three Claude agents, one task, and a malware turf war: the multi-agent bill arrives1 distinct publisher
build
Claude's system prompt grew ninefold in two years. Version yours like code.1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026