Loading today’s stories
Build1 distinct publisher3 min readPublished
Structured output guarantees the shape of each element and never the count, so a batch call that quietly returns one item still parses clean. Reconciling ids and asserting on content is what catches it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
An empty MCP tool list is a successful response, and the bug is on the server side1 distinct publisher
build
Count invalid JSON as a failed classification, and model choice becomes a reliability problem1 distinct publisher
build
Moving role_code to the end of Gemini's required array fixed four of nine extractions1 distinct publisher
build
Valid JSON, Wrong Bucket: Why A Model Answer Is A Proposal, Not A Result1 distinct publisher
A schema is a grammar over the response. The validator receives exactly one input: the bytes that came back. Your batch size lives in the other half of the exchange, and the grammar never sees the request [2]. So there is no keyword that means "as many elements as I sent you". An array of one is an array. That's the validator answering a different question than the one you actually asked.
The arithmetic on that specific miss is unkind. One object returned for three inputs is two items gone, a two-thirds loss on that call, with a successful parse [17]. Nothing downstream notices, because the next pass selects a fresh top slice of new work rather than sweeping for stragglers [4]. There is a bonus once ids are in the loop: a batch that times out as a whole can be retried item by item, instead of every item dying with one pathological input [5].
The content half is where the dev.to writeup earns its keep. Each item comes back with a translations object, one key per target language, each holding a title and a summary [6]. A small model mixes the slots [7]. Counting characters by script and comparing against the script implied by the key catches that [8], and the author is explicit that this is the easy half.
The hard half is the failure that shipped. The model sometimes completed a translation correctly and then kept going, appending a second translation into the same field, so a correct headline arrives with a foreign clause welded to its tail [9]. By share, the correct text wins comfortably, and the dominance check passed it every time [10]. The author's conclusion is the load-bearing bit of engineering here: share tests assume the two things being weighed are commensurable, and correct output versus corrupt output is not that. Two characters of a script with no business appearing is the whole failure at any size, so the rule became presence, rejected at a count of one [11].
That rule only survives contact with real text because of a carve-out. Latin characters stay legal in every language, since product names, acronyms and companies are legitimate anywhere, and banning them would reject more good translations than it saves [12]. The discipline the author draws from that is worth stealing: zero tolerance is affordable only where you can name the reason no legitimate case exists, and otherwise you have built a stricter bug [13]. If two of your target languages share a script, presence gives you nothing, and you are back to a language identifier with a probability attached.
The keyword field is the same lesson from the other direction. A schema minimum of three entries is a semantic requirement wearing a validation costume, and the model satisfies it by padding with terms like "study", "research" and "science", which are worse than an empty list because they cannot be distinguished from real index terms [14]. The minimum came out; the count moved to the prompt, and the schema went back to guaranteeing that the field exists and holds strings [15].
Treat this as one practitioner's incident log rather than a measurement. The writeup describes the offending model only as "a small model" [16] and reports no rates, so the mechanism is what generalizes here; any specific threshold is particular to this model. For the script rules to transfer to your pipeline, you would need per-language allowlists you can defend one script at a time. For the id reconciliation to matter, you need a work selector that will never revisit the item you dropped [4]. That second condition is more common than it sounds.
Ranked by verification strength, evidence, and original report placement.
Constraining model output with a JSON schema guarantees a shape; content correctness remains the caller's responsibility.
The pipeline sends several items per call and the schema requires an array of objects with required fields; the model sometimes returned one object for three inputs, which is schema-valid because an array of one is an array, and the schema constrains only what an element looks like since it never saw the request.
The author's fix is to reconcile the response against the request by id: send ids in, require ids back, diff the sets, and re-ask individually for whatever went missing.
A dropped item does not come back around on the next pass, because the next pass selects a fresh top slice of new work.
The same id reconciliation gives a failure mode for the whole batch: if the entire call times out, the items can be retried one at a time instead of all being lost to one pathological input.
Each item comes back with a translations object holding one key per target language, each with a title and a summary.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
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.
Verifiable mechanism, unverifiable incidents
Two very different grades of evidence sit in the same post. That a one-element array satisfies an array schema, and that element constraints carry no count, is something any reader can confirm against the specification without trusting the author at all. The rest — the appended translation, the padded keywords, the batch that reached users — is one engineer's recollection with no logs, no schema excerpts, no code and no named model behind it. Nothing contradicts it; nothing outside the post confirms it either.
One pipeline, one author
The only deployment on the record is the author's own: a summarization and translation service that pushed corrupted headlines to real readers and then had its validation rules rewritten. That is genuine production use rather than a demo, which is why this is not scored at zero — but it is a single unnamed system, and nobody else in our coverage reports adopting the id-reconciliation or presence-based script checks described here.
Undersold
The post promises less than it delivers. It reads as a personal bug list, complete with a shrug about regex-scraping JSON, yet the central observation — that a validator's silence is not evidence about content, and that every added constraint gets met by the cheapest available route — applies to any team that has swapped hand-parsing for structured output and treated the parse as a quality gate. No vendor is talked up, no technique is called a framework, and the author volunteers where his own first fix failed. Slightly negative rather than strongly so, because the generality is left for the reader to notice.
Nothing on sale
There is no product in the frame, no vendor praised or blamed, and no benchmark to win — the model that misbehaved is left anonymous, which forfeits the easy engagement a named-vendor callout would have bought. What remains is the ordinary pull of self-published developer writing: the story is shaped as lessons learned, and the author is the only witness to how badly things went and how well the fixes worked.
Believable, unconfirmed
Confidence tracks the split in the evidence. We would stake a lot on the schema reasoning and the fix that follows from it, because those stand on their own. We would stake much less on the specific behaviours: one author, one anonymous small model, no frequencies, and no second account of language slots being swapped or keyword minimums being padded. Treat the engineering advice as sound and the incident detail as a plausible single report.