The first failure I had to eliminate in the blog pipeline was not a bad paragraph. It was a bad evidence set. The system was finding a few nearby chunks, mistaking density for coverage, and then drafting as if that narrow slice represented the whole repository. That produces text that sounds confident right up until you compare it with the code. The fix was to stop treating topic selection like a writing problem and start treating it like a retrieval coverage problem.
That distinction matters. If the upstream evidence is thin, no amount of prompt polish saves the result. The draft will still overfit the first cluster of files that happened to match the query. I wanted the pipeline to be disciplined about breadth before it was creative about prose. So the gate moved earlier: query fan-out, file-path-aware dedupe, breadth validation, pinned excerpts, and only then the writing pass.
The gate lives before the writing step
In my pipeline, the important work happens before generation starts. The dispatcher is where the topic search fans out through multiple lanes: curated highlights, a fixed RAG query pool, and recent commit-derived queries. That is deliberate. A single semantic search tends to collapse into the same dense corners of the codebase, which is exactly where a system becomes persuasive and shallow at the same time.
