Evidence note: This article rests almost entirely on PlayAgit’s own pipeline instrumentation — counts recorded in an internal run ledger across 23 pipeline runs between 2026-08-28 and 2026-08-31. These are self-measurements of one system’s behavior, not independently audited results, and every figure below is attributed to that ledger with its sample size. One outside source, a Stack Overflow dispatch summarizing an O’Reilly discussion, is used only to frame the question; its central claim is flagged where it appears and is not independently corroborated.
The real bottleneck isn’t producing the work — it’s deciding what "correct" means
A recurring argument in commentary on agentic development runs like this: once a system can generate code (or drafts, or plans) cheaply, the expensive part shifts to defining what "correct" looks like and building a dependable way to check it. A Stack Overflow dispatch on "the right amount of spec for agentic development" frames the problem in those terms.
That proposition is intuitive, but it remains open. Sources do not independently confirm it, and it should be read as a hypothesis rather than an established finding [uncorroborated]. What can be examined more concretely is a single pipeline that was built as if the proposition were true — one that spends most of its machinery not on generating candidates but on filtering, scoring, and checking them. The rest of this article walks through what that machinery actually did over one four-day window. It does not prove the thesis; it shows what one verification-heavy system looks like from the inside. (For a closer look at the same pipeline over an overlapping period, see our earlier breakdown of how 22 runs vet, filter, and publish.)
The quality gate: most drafts don’t ship, and that’s the point
The clearest place to see verification treated as the main job is the quality gate — the checkpoint every draft passes through before it can be published.
Across PlayAgit’s own pipeline runs (23 runs, 2026-08-28 to 2026-08-31; self-measured), the gate reviewed 156 drafts and returned three outcomes: 72 published, 57 sent back to revise, and 27 rejected outright (PlayAgit run ledger; n=156 draft verdicts). In other words, fewer than half of the drafts that reached the gate were published on that pass; the remaining 84 were either bounced for revision or killed.
The revise-versus-reject split is the informative part. A gate that only ever said "yes" or "no" would be a filter; a gate that returns 57 drafts for revision against 27 rejections (PlayAgit’s own runs, same 23-run window) is doing something closer to editing — spending effort to define the gap between a draft and a publishable one, not just scoring it pass/fail.
Deciding what to build before building it
Verification doesn’t start at the draft stage. Before anything is written, topics are scored, and most are set aside.
Of 8,089 scored topics in PlayAgit’s own runs (23 runs, 2026-08-28 to 2026-08-31; self-measured), 4,031 were rejected and 2,752 were held before production, leaving 1,306 that advanced (PlayAgit run ledger; n=8,089 scored topics). Those three numbers account for the full set — roughly half rejected, about a third held, and the remainder promoted.
The "held" category is worth dwelling on. A held topic is neither approved nor discarded; it is a deferred decision. That 2,752 topics sat in that state (PlayAgit’s own runs, same window) suggests the pipeline treats "is this worth building?" as a question it is often willing to leave open rather than force — which is itself a form of defining "correct" by refusing to commit prematurely.
Where the candidates come from
Scoring only matters if there’s a wide enough field to score. The pipeline’s discovery stage cast a broad net.
It surfaced 6,940 topic candidates across 4 categories, drawn from 200 distinct source hosts, in PlayAgit’s own runs (23 runs, 2026-08-28 to 2026-08-31; self-measured) (PlayAgit run ledger; n=6,940 candidates). Set against the 1,306 topics that later reached production (PlayAgit’s own runs, same window), discovery produced well over five candidates for every one that advanced — the funnel is wide at the mouth by design.
The 200-host figure (PlayAgit’s own runs, same window) matters for a different reason than volume: sourcing breadth is a precondition for the scoring and gating stages to have anything meaningful to choose between.
Grounding claims in evidence — and being honest about how much got checked
This section carries a load-bearing caveat, so it is stated once and plainly: the counts below measure what the pipeline recorded doing, not whether its checks were correct.
Each topic that advances gets a research dossier — a collection of claims with their supporting evidence. Across 1,060 dossiers holding 3,787 claims in PlayAgit’s own runs (23 runs, 2026-08-28 to 2026-08-31; self-measured), 92 claims were independently cross-checked and 431 were primary-attested (PlayAgit run ledger; n=3,787 claims across 1,060 dossiers).
Those two numbers deserve to be read against the total rather than in isolation. Of 3,787 claims, the 92 that were independently cross-checked are a small fraction — on the order of one claim in forty (PlayAgit’s own runs, same window). The 431 primary-attested claims — traceable to a primary source — are a larger but still minority share, roughly one in nine (PlayAgit’s own runs, same window). Presented honestly, this is the gap between aspiration and instrumentation: a pipeline built around verification still leaves most individual claims resting on attribution rather than independent confirmation. That is not a hidden failure so much as the actual shape of the work — and it is exactly the kind of number a system that takes "checking" seriously should be willing to publish about itself.
What actually shipped
After discovery, scoring, dossier-building, drafting, and the gate, the output for the window was modest relative to the inputs.
PlayAgit’s own runs (23 runs, 2026-08-28 to 2026-08-31; self-measured) published 72 posts — 72 new and 0 updated (PlayAgit run ledger; n=72 publications). That 72 matches the 72 "published" verdicts from the quality gate above (PlayAgit’s own runs, same window), which is the expected internal consistency: the gate’s approvals and the publication count describe the same 72 items from two stages.
The 0 updates figure (PlayAgit’s own runs, same window) is a small but real signal about this particular window: the run was net-new production, not maintenance of existing posts.
How this applies in Vision
The through-line across every stage above is that the generating step is the cheap one. Discovery produced 6,940 candidates; only 1,306 topics advanced; 156 drafts reached the gate; 72 shipped (all figures from PlayAgit’s own runs, 23 runs, 2026-08-28 to 2026-08-31; self-measured). At each narrowing, the system spent its effort deciding what counted as good enough — scoring, holding, revising, rejecting — rather than on producing more.
For a build system like Vision, the practical reading is the same shape the industry commentary above proposed, minus the certainty it can’t yet claim. If producing a candidate is cheap, the leverage moves to the checks: a scoring stage that is willing to hold rather than force a call, a gate that revises rather than only accepting or rejecting, and an evidence layer honest enough to report that most claims are attributed rather than independently confirmed. Whether that arrangement is the answer to agentic development is unproven [uncorroborated]. What the ledger shows is narrower and verifiable: one pipeline organized around that bet, and the exact rates at which it said no. Teams weighing how much control to build into their own tooling — a question explored from a different angle in our look at building with more control — can at least borrow the instrumentation, and publish their own no-rates the same way.