A dev diary went out with the wrong title. Not garbled, not truncated -- just old. The preview pane showed the right headline. Hit publish, and the live post reverted to a boilerplate line: "What we published XX-XX-2026." Same content, wrong hat.
That's the kind of bug that makes you distrust your own eyes. Preview and prod disagreeing isn't a rendering glitch -- it's two code paths reading two different truths.
The symptom
We'd seen title weirdness before. We already wrote about titles echoing the topic phrase back at the reader instead of describing the post -- a duplication loop where the model just restated what it was asked to write about. That one got a qa.title_coherence rail and a PR (#2766) that shipped in July.
This was different. The title wasn't wrong because a model wrote a bad one. It was wrong because something downstream threw the good one away and grabbed a stand-in instead.
We ran the systematic-debugging skill on it, the way we do for anything where the failure is a "sometimes, but not always" pattern. First move: trace the field, not the symptom. Where does the published title actually come from, and where does the preview title come from? If they're different lookups, one of them is lying.
Tracing the echo
The trail led to extract_title_from_content. It pulls the title by matching the first markdown heading in the draft body. For most post types that's fine -- the model puts a real headline at the top and you grab it.
For dev diaries, the first heading is always the same line: # What we shipped on {date}. It's a template artifact, not a headline. It's always there, and it's always truthy.
That's the whole bug. The publish path resolves the title with an or chain -- try the extracted heading, fall back to the stored title if the extraction comes back empty. But the extracted heading is never empty for a dev diary. It's a generic boilerplate line that wins every single time, permanently shadowing the real, hand-picked title sitting right there in merged.get("title").
Preview never runs that extraction step -- it reads the stored title directly. So preview shows truth, publish shows the echo. The bug wasn't in the title generator. It was in the precedence logic deciding which title counted as "the" title.
We call this one the echoing title bug because that's exactly the mechanic: a generic, always-present string echoing back over the specific one every time, drowning it out through sheer reliability rather than correctness.
Not an isolated case
Once we had that mental model -- a wrong-but-present value beating a right-but-conditional one -- we found the same shape twice more in the same subsystem.
One was title pollution. A style-rubric line the writer model generates as internal reasoning -- something like "Avoids the 'Version/Phase' style: no mention of PRs, commits, or phase numbers" -- was landing in the pipeline_versions.title column instead of the actual headline. The published post title was correct, because publish reads a different, clean field. But media generation for the podcast intro reads the polluted column. So the audio would open with the model narrating its own editorial reasoning instead of introducing the episode. Same root shape: a wrong value sitting in a field that a downstream consumer trusts blindly.
The other was a podcast intro that mangled a title mid-sentence, ending on a dangling word like "Testing." That one traced to derive_seo_title, which truncates at a word boundary at 60 characters -- a sane rule for meta descriptions, a bad rule for something read out loud as a full sentence. The real episode title was "Can the 'Critic' AI Really Catch Its Own Mistakes? Testing," and the truncation function had no idea "Testing" was doing real work at the end of that title rather than being a trailing fragment worth cutting.
We also traced a related failure where a reviser's own commentary bled into a published draft -- we wrote that one up separately -- same family of bug: a pipeline stage's internal scratch output leaking into a field a later stage treats as final.
Three different files, three different symptoms, one lesson: any time your code has a fallback chain, the fallback needs to actually be worse-but-empty, not worse-but-present. If the "fallback" is always populated, it isn't a fallback. It's the default, and your real value is dead code.
Echoes are everywhere, if you look
This isn't a Glad Labs-specific pathology. "Echo" bugs -- where the wrong copy of a string wins because it's more reliably present than the right one -- show up across the industry constantly. There's a long-running Bricks Builder thread about an echo: function that populates a link's href correctly but silently fails on the title attribute -- the value looks fine in one place and is simply absent in another, same class of divergence between two code paths that should agree and don't.
Even game studios aren't immune. Blizzard's Diablo 4 forums have a player report about the "Echoing Elites" achievement tracking more kills than the stated threshold -- a counted value drifting from the displayed one. Different domain, same species of bug: the number you see and the number the system actually uses aren't the same number, and nobody noticed until a player did the math.
The pattern is always the same shape: two representations of "the truth" exist somewhere in the pipeline, one gets shown to a human for sanity-checking, and the other one is what actually ships.
The fix
For the dev diary case, the fix was narrow: stop matching the first heading blindly. Check whether the extracted heading matches the known dev-diary template pattern, and if it does, treat it as boilerplate, not a title -- fall through to the stored title unconditionally for that post type.
For the broader class, we added a TitleAndProse test suite specifically aimed at catching leaks before they reach a published or narrated field: tests that strip reasoning preamble before a mid-line title marker, tests that pick the last title marker when reasoning mentions the concept earlier in the text, and tests that make sure an overlong title after the marker falls back to a heuristic instead of just truncating mid-word. We paired that with prompt-leak detection and a residual-leak warning, so if a rubric line or reasoning fragment slips into a title field again, something screams before it hits prod instead of after.
37 tests passed. The dev diary now shows the same title in preview and after publish, every time.
Why this one's worth remembering
The topic-echo bug and the title-echo bug look similar from the outside -- both produce a wrong title -- but they're different failures with different fixes. Topic echo is a generation problem: the model restates the prompt. Title echo is a plumbing problem: the pipeline picks the wrong of two existing values. Fixing one doesn't fix the other, and conflating them means you patch the visible symptom while the actual bug -- a fallback chain that never falls back -- keeps running quietly in every other post type you haven't checked yet.
If your publish pipeline has more than one field that could plausibly be "the title," audit which one wins and why. Chances are it's not the one you'd pick if you were watching.
Top comments (0)