Chapter 5 of 7. Prerequisite: Chapter 3. You have the gated pipeline: candidates triaged out of the devlog, theses proposed, drafts generated, automated checks run. This chapter isolates the checkpoint that makes any of it publishable in public: the points where a person accepts or rejects, and the one veto that carries a deadline.
The naive version of an LLM writing pipeline is draft-then-publish. It fails in public, and it fails on reputation rather than on facts: developer readers detect model-structured prose fast, and they remember whose name was on it. The pipeline in this course runs a human gate instead. In the manual path that gate is two explicit decision points. In the automated path it collapses into a single time-boxed veto. This chapter defines both, then walks the live run that exposed the wiring gaps on either side of them.
Where the human gate sits in a developer blog LLM drafting pipeline
A human gate is the checkpoint where a person accepts or rejects the work before it ships. The definition sounds trivial. The design carries two hard questions: what artefact the person is judging, and what happens when the person says nothing.
In the six-step gate from Chapter 3, two steps belong to a human by design. Step 2 is clarify and redirect: the owner corrects framing, kills wrong angles, and adds nuance to the proposed theses before any prose exists. Step 4 is edit: a prose-level pass for voice and truth on the finished draft. Every other step is mechanical or delegable.
Step 2's placement does most of the work. The system's own docs state the rationale plainly: "LLMs draft confidently. A finished draft feels defensible even when its thesis is wrong. Thesis-first discipline strips the prose so the argument is what's being evaluated." Show a person 800 fluent words and they judge the fluency. Show them three sentences of thesis and they judge the claim. The gate forces the accept-or-reject decision at the cheapest and most honest point: before the model wraps the argument in prose. Skipping it produces fluent articles against the wrong premise, and no amount of editing at step 4 recovers a bad thesis.
The proposal format is constrained for the same reason. One thesis when the angle is unambiguous, two or three variants when angles genuinely differ, never four or more. The docs call the cap what it is: "decision fatigue, not deliberation." A human gate that presents ten options is a rubber stamp with extra steps.
Why draft-then-publish fails in public
The rejection of unedited model output is documented, loudly, by the communities a developer blog wants to reach. The Hacker News guidelines ban it outright on the site itself: "Don't post generated text or AI-edited text. HN is for conversation between humans." For linked blog posts, a 1,300-point front-page thread titled "It's insulting to read AI-generated blog posts" shows how the same community receives AI-scented writing wherever it lives.
The voice numbers explain why the hostility lands on real authors. The Write that blog! survey by Cynthia Dunlop, with 181 respondents, found that "only 13% of those using LLM writing reported that the generated drafts sound like them", and 59% described the output as "generic AI". A companion report on reader reactions, with 668 respondents, found 78% of developers immediately leave an article they judge to be AI-written and 71% avoid the author permanently. The draft costs minutes. The unedited publish costs the audience.
The output those readers are rejecting has a recognisable shape:
In today's fast-paced development landscape, keeping a devlog is more
important than ever. In this post, we'll explore how to transform your
raw notes into polished, engaging articles. Whether you're a seasoned
engineer or just starting your journey, these strategies will help you
level up your writing game.
Nothing in that paragraph is false. All of it is skippable, and none of it could only have been written by you. Fixing the prose layer is the whole subject of the companion course, AI prose and voice. The process layer is what this chapter fixes: no artefact reaches readers without a person having accepted it, on the record.
The live run that found the gaps around the gate
At 09:00 BST on 11 June, this pipeline's auto-mode fired its first scheduled slot for real. Queue id=34, an article drawn from the devlog, and the auto-publisher opened PR #95 against this site's repo. Then nothing. No merge, no post-merge hook, no deployed article. The post-mortem names it gap one: auto-merge and the hook call both existed in the codebase, and neither was wired into the auto-mode path. No test caught it because the integration tests covered the publisher in isolation and stopped at the PR. Nothing ran the full chain from queue row to deployed article. Pre-flight design cannot catch missing wiring between components that each test clean in isolation. Only a live end-to-end run surfaces it.
Note the direction of that failure. The broken automation degraded into an open PR waiting for a person. Embarrassing, and safe. The earlier "self-driving overnight" claim got rolled back in an explicit correction entry in the devlog, because a pipeline whose PRs sit open until a human taps merge is supervised, whatever the toggle says.
Gap two, the same morning, failed in the dangerous direction. At 12:00 BST the pipeline opened PR #97 for an article that had already shipped on 2026-05-28. Same incident, same citations. No duplicate check existed anywhere in the publish path, so the only thing standing between a verbatim republish and the live site was a person happening to read the PR. The fix could not be more automation of the same kind: it required a new pre-publish fingerprint gate comparing the candidate against the live published corpus rather than internal ledger state, because the earlier ship had happened outside the CLI and internal state alone would never have caught it.
The same week exposed a smaller gap in the human interface itself. The auto-mode command was a blind toggle: checking status meant tapping the same command that flips the pipeline, and at least one accidental double-tap from a status-check message killed it. The fix was a separate read-only status command. An operator's instrument panel must not share buttons with the controls.
One honest number closes the incident: by 13 June, autonomous success across the five most recent scheduled slots stood at 20%. Chapter 7 covers the recovery. The point for this chapter is narrower: both gaps sat on either side of the human gate, one upstream of it and one downstream, and both were invisible until the system ran end-to-end with a person watching.
Why a human gate, not auto-publish?
The call
Nothing reaches the site without a person accepting it. The machine drafts, opens the pull request, and stops.
Rejected
What it costs
The human is now the bottleneck by design. Every shipped piece costs minutes of attention, and a missed review stalls the slot until the recovery rules pick it up.
Revisit when
Confidence does not accumulate into autonomy here. The gate is structural: the run described above opened the PR and did not merge it, and that boundary stays.
A veto with a deadline
In auto-mode the two manual decision points collapse into one mechanism. Before each auto-mode PR opens, the pipeline posts a chat message carrying the title, the slug, the first three prose lines, and a cancel button. Then it blocks for 10 seconds. A tap rolls back the staged files and the PR body, moves the queue row to cancelled, and nothing publishes. Silence means consent, and the publish proceeds.
Each part of that design answers one of the two hard questions from the first section. The artefact under judgment is the opening lines, because the opening carries the thesis and the voice, and a wrong thesis or a dead voice is visible within three lines. The silence policy is written down and time-boxed, because a veto without a deadline is an approval queue wearing a veto's clothes, and an unattended approval queue is where scheduled publishing goes to die.
The failure directions are deliberately asymmetric, and the asymmetry is about errors, not verdicts. When a machine check breaks, it fails open: an unreachable database or a parse error resolves to allow, on the argument that a broken check or a missing illustration should never stall the schedule. When a machine check genuinely hits, it fails closed: a duplicate detection blocks the publish outright. The human veto fails closed in every case: a tap always cancels, with rollback, no matter what state the rest of the run is in. Machine checks are advisory when they break, binding when they hit.
The asymmetry runs one level deeper. The drafting model itself is allowed to refuse: when the drafter judges a candidate a rehash of an already-shipped sibling, it returns a refusal flag, the queue row is cancelled, and the topic is deliberately not requeued. Machines in this pipeline can say no. Only the human can say yes.
The gate protects voice as well as facts
Step 4, the edit pass, is defined as a pass for voice and truth. Half of that job is now delegated to deterministic counters: this site's style guide caps em-dash density at 3 per 1,000 words at article scope, and a regex-based tells scrubber runs before anything publishes. Chapter 4 of the companion course documents why the counters exist and its closing chapter shows how to build them.
The counters also mark the human gate's limit in the other direction. Early in this pipeline's life, three articles cleared every automated check and shipped over the em-dash budget, because the check counted per paragraph while the rule was article-scope. All three carried clean reports at review time, and the human reviewer inherited a false prior from the green check. The catch came from a person reading the rendered live site. The division of labour that fell out of the incident is the durable lesson: counters own everything countable, because a human reading for content cannot simultaneously count surface patterns. The human owns exactly two judgments no counter reaches: does this sound like me, and would I defend this claim in a comment thread under my own name. The 13% voice-match figure above says the model will not supply the first. The thread above says readers will test the second.
Design rules for your own human gate
- Put the decision at the thesis, not the draft
Accept or reject three sentences before the model writes eight hundred words. A rejected thesis costs seconds. A rejected draft costs the sunk-cost argument you will have with yourself about salvaging it.
- Cap the options at two or three
Variants exist to surface genuinely different angles. Past three, the human is pattern-matching rather than deciding, and the gate stops gating.
- Give the veto a deadline and write the silence policy down
Decide explicitly whether silence means consent or refusal, put the timeout in code, and log every fire. An implicit silence policy is still a policy. You just discover it during an incident.
- Fail open on machine errors, fail closed on machine hits and the human veto
A check that blocks on its own parse error will eventually stall the schedule over nothing. A duplicate gate that allows on a genuine hit is not a gate, and a human veto that fails open is not a veto.
- Keep the review unit equal to the editorial unit
On this site every article ships as its own PR on its own dated branch, squash-merged. A bad article gets reverted or cancelled without entangling its siblings, and the duplicate and sibling-cancel gates key cleanly off one slug and one PR.
- Separate status from control
A read-only status surface, distinct from any toggle. The double-tap that kills your pipeline will come from a status check.
- Run the chain live, end to end, before trusting it
Isolated tests proved every component of this pipeline worked and still missed both gaps. One supervised live run through queue row, PR, merge, and deployed page found them in a morning.
The human gate is not the part of the pipeline that resists automation. It is the part that defines what the automation is for. Drafting is cheap, so the model drafts. The byline belongs to a person, and the readers doing the judging can tell whose it is, so a person decides. Everything else in this course, from the triage rubric to the slot scheduler, exists to deliver a small, well-framed decision to a person at the right moment. The next chapter goes underneath it all, into the SQLite state machine that makes every one of those decisions durable.
Design your own human gate
Wire a human checkpoint into your own publishing flow, manual or automated. Place the accept-or-reject decision at the thesis, cap proposals at two or three options, then define your veto: what artefact you see, how long the window lasts, and what silence means. Write the silence policy down before the first run, separate any status surface from any control, and finish with one supervised end-to-end run from candidate to published artefact.
Expected behaviour
- The decision point sits at a short thesis rather than a finished draft, and rejecting one costs seconds
- Your veto has a written deadline and an explicit silence policy, chosen deliberately between consent and refusal
- Checking the state of your pipeline uses a read-only surface that shares no control with any toggle
- One live end-to-end run has been completed with a person watching, and any wiring gap it exposed is recorded
PROVE IT Trigger your veto path on purpose during a run and show the rollback: the artefact does not publish, the work item lands in a cancelled state, and the record shows who vetoed and when.
Why does the pipeline force the accept-or-reject decision at the thesis rather than the finished draft?
How many seconds does auto-mode block for after posting the preview, before each PR opens?
Describe the asymmetry in how the automated path treats failures: what fails open, what fails closed, and where the human veto sits.
Show answer
When a machine check breaks, it fails open: an unreachable database or a parse error resolves to allow, so a broken check never stalls the schedule. When a check genuinely hits, such as a confirmed duplicate, it fails closed and blocks the publish. The human veto fails closed in every case: a tap always cancels with rollback whatever state the run is in, because machine checks are advisory when broken and binding when they hit.
↺ re-read: “A veto with a deadline”