Chapter 4 of 7. Ask a model for a developer blog post and paragraph one restates your title back at you. The sentence your reader actually came for is usually sitting at the top of paragraph two.
This chapter teaches the cheapest edit in the whole course. You do not rewrite anything. You find the first sentence containing a fact and you delete everything above it. Then the move generalises: the model's output is raw material, and the draft you publish starts after the output ends. This site learned the second half of that sentence in production, inside one 24-hour window in June.
What throat-clearing looks like
A generated opener follows a recognisable shape. Here is a composite of the paragraph a model returns when you ask for a post about static deploys, fenced off as an example so it stays out of this chapter's own prose:
EXAMPLE (AI-tell opener):
In today's fast-paced world of web development, deploying a static site
can seem daunting. With so many hosting options available, it's important
to choose an approach that fits your needs. In this post, we'll walk
through deploying a Next.js site to shared cPanel hosting — step by step.
Deploying to cPanel means uploading the contents of out/ to public_html/
over FTP. The first thing that breaks is...
Read the two paragraphs against each other. Paragraph one contains no command, no path, no version, no decision. Paragraph two lands four facts inside two sentences. A reader arriving from a search result gets nothing from the opening paragraph except confirmation that they clicked a headline.
The warm-up has recurring parts: a scene-setter about the state of the industry, a difficulty acknowledgement, an importance claim, an itinerary promising what the post will cover. Every one is content-shaped rather than content.
Why does the model open this way? My working read, not an established mechanism: it is not stalling, it is completing the shape of a blog post. Published posts often open with context, so context-shaped sentences are plausible material for position one, and whether they carry information is not part of what plausibility measures. The fix does not depend on that explanation being right. Whatever the cause, the warm-up is identifiable and cuttable.
The first-fact test
Scan the draft for the first sentence a reader could act on or check: a command, a file path, an error message, a number with a unit, a date, or a decision you made and can defend. That sentence is your candidate opening.
- Find the first checkable sentence
Read from the top with one question: could a reader verify this or use this? The first yes marks the real start. In a raw generation it usually arrives in paragraph two. In a bad one, paragraph four.
- Delete everything above it
Delete, not trim. A softened warm-up is still a warm-up. If some deleted sentence held a load-bearing qualifier, you will feel its absence on the reread; restore it below the new opener, never above.
- Repair the new opener's references
The promoted sentence may lean on deleted text. A dangling "this approach" or an unintroduced acronym needs its subject named. Fix the references and stop. Resist rewriting the sentence into a new introduction.
- Run the same test on every H2
Sections throat-clear too. A generated section opener recaps the heading before saying anything new. The first-fact test applies at every heading, not once per article.
This is people-first editing in the most literal sense. Google's helpful-content guidance defines the target: "People-first content means content that's created primarily for people, and not to manipulate search engine rankings." A warm-up paragraph serves nobody on either side of that sentence. Readers skip it, and it was never ranking material either. The same page notes that "some content might be helpful based on the experience it demonstrates". An opening sentence holding a date and an error message demonstrates experience. An industry scene-setter demonstrates access to a language model.
Three articles cleared every gate. The draft still was not done.
Phase 9 of this site's article auto-pipeline shipped on 2026-06-11, across twelve PRs (#188 to #199). The chain: a digest cron surfaces candidate devlog material, Telegram triage approves a topic, a variant picker locks a thesis, a Sonnet 4.6 drafter writes the piece, an AI-tells scrubber checks it, a review email goes out, an approval endpoint fires, and the PR auto-merges. Two button taps from article candidate to deployed MDX.
Within 24 hours, three articles that had cleared every automated gate were all over the style guide's em-dash budget. No report said so. I caught it by reading the live site.
The mechanism of the miss was scope. This site's style guide sets the budget at article scope: at most 3 em-dashes per 1,000 words across the piece. Its scrubber checked paragraph scope: flag any paragraph carrying 3 or more. From the write-up: "A typical article can contain a dozen paragraphs each with two em-dashes and never once trip the per-paragraph flag." Each article also generated a clean .tells.txt sidecar, and the clean sidecar created a false prior. A report saying nothing was wrong sent the reviewing human off to read for content instead of counting.
That reviewing human was me. I had read all three articles in the review email and approved them. The write-up owns it plainly: "A human can't reliably count em-dash density across a long-form article while reading for content." The gate existed precisely because a human read is unreliable at that task. Then the gate measured the wrong scope, and the human trusted the gate.
Why could the drafter not hold the budget itself? Because "the model doesn't track running totals as it drafts; it produces the next sentence from context, not from a density budget." No prompt instruction reliably holds article-scope density over an arbitrary-length piece. That much the write-up establishes. The link back to openers is my inference, not the write-up's claim: I read the throat-clearing opener as the same limitation seen from the other end. The model is not holding your reader's arrival intent while it drafts, any more than it is holding a running em-dash count.
Backlog item B-014 carried the fix, landed in PR #202. The density check moved to article scope with the exact number from the style guide, and the three articles were voice-fixed by hand, one pass each. The structural line from the write-up is the one to keep: "When a gate implements a proxy for the rule rather than the rule itself, the LLM satisfies the gate systematically while violating the rule systematically. Not by intent."
Here is what the incident settled for this course. The pipeline had treated the model's output as the draft. It was raw material. The draft, meaning the thing a named human is willing to publish, started after the output: a deterministic pass at the right scope, then a human read of the rendered page. That is the double meaning in this chapter's title. The article starts in the second paragraph, and the drafting starts after the model stops.
How to edit an AI draft to sound human on a developer blog
The opener cut is step one of a full pass. The rest of the pass works through the same logic at smaller scales: find the sentences that exist to sound like an article, and remove or replace them.
Start with vocabulary. The scrubber in the pipeline above checks a concrete list, and it is a fair starting inventory for a manual pass:
Patterns the pipeline's scrubber checks (shipped 2026-06-11):
- opening hedges: "Indeed," "Notably,"
- closing summaries: "In conclusion,"
- "Let's dive in."
- rule-of-three rhythm
- generic positivity: "powerful" "seamless" "comprehensive"
- sentence-length uniformity
Itinerary sentences get deleted wherever they appear, not only at the top. Summary closes get deleted too. A developer post ends when the last fact lands. Importance claims get replaced, not deleted: swap the assertion that something matters for the event that made it matter to you. The error message, the bill, the outage, the rollback.
The before and after of a full pass on an opener. The BEFORE is a composite generated example; the AFTER is this site's own published record, condensed from the incident above:
BEFORE (composite generated opener, no checkable fact in it):
Automated content pipelines are a powerful way to scale a developer
blog. When set up correctly, they can save hours of manual work.
However, they also introduce quality risks that can be tricky to
catch. Let's explore how to keep AI-generated drafts under control.
AFTER (from this site's published record):
Three articles cleared every automated gate on this site's publishing
pipeline. Within 24 hours of the pipeline shipping, all three were
live and over the style guide's em-dash budget. No report said so.
The AFTER opener is not written to sound specific. It is the documented incident this chapter walks through above, with the write-up linked from this page. That is the point. The specifics in a strong opener are the specifics only you have: your ship date, your PR numbers, your gate's wrong scope. For now the rule is directional. Where the model wrote a claim about the topic, you write a record of the incident.
Read the result on the surface your readers use. The three over-budget articles were caught on the live site, not in the review email holding the same text. Rendered pages read differently from drafts in an inbox, and the published register is the one that has to pass.
Gate the cut, then read the page anyway
Opener throat-clearing is the most gateable tell in this course, because it is lexical. A short pattern list catches most of it at pre-publish time:
EXAMPLE opener patterns worth flagging in a pre-publish check:
"In today's" "In this post" "In this article"
"Let's explore" "Let's dive" "Have you ever"
"it's important to" "can seem daunting" "In conclusion"
The incident above supplies the caveat. A clean report creates a false prior, and a pattern list checks yesterday's vocabulary at whatever scope you remembered to implement. So split the work by what each layer is good at. The deterministic check covers what a reading human fails at: counting, density, scope. The human read covers what the counter cannot see: an opener that trips no pattern and still says nothing.
Run the cut first on every draft, because it is the highest-value thirty seconds in the edit. Then hold the wider lesson. The output is not the draft. The article starts in the second paragraph, and the editing starts after the model stops. What goes where the warm-up used to be is the next chapter's subject: the first-hand specifics no model can supply.
First-fact your last three posts
Apply the first-fact test to your own published archive, then wire the opener patterns into a check so the next draft gets flagged before you do the deleting by hand.
Expected behaviour
- The first checkable sentence identified in each of your three most recent posts
- Everything above that sentence deleted, with dangling references repaired below the new opener
- The same test run at every H2, with recap openers cut
- An opener pattern list added to your pre-publish check, seeded from the phrases you actually found
- One importance claim replaced with the event that made the topic matter to you
PROVE IT Paste one before and after opener pair from your own archive, with the deleted warm-up shown.
Three articles cleared every automated gate and still shipped over the em-dash budget. What was the mechanism of the miss?
Which backlog item carried the fix that moved the density check to article scope?
The chapter says its title has a double meaning. What are the two meanings?
Show answer
The article starts in the second paragraph, at the first sentence a reader can act on or check, with the warm-up above it deleted. And the drafting starts after the model stops: the output is raw material, and the publishable draft only exists after a deterministic pass at the right scope plus a human read of the rendered page.
↺ re-read: “Three articles cleared every gate. The draft still was not done.”