The first time I reviewed an AI-generated draft as a pull request, I caught myself doing something strange: I was reading every sentence in order, top to bottom, like a copy editor. That's the wrong mode. When I review code in a PR, I don't read line 1 to line 400. I look at the diff shape first, then the structural decisions, then the risky bits, then the details. Prose reviewed in a PR deserves the same discipline, and most teams don't have it yet.
This post is a checklist, but not in the listicle sense. It's the order of operations I now follow when a Branchpost draft lands in my review queue, and the failure modes each pass is meant to catch.
Read the frontmatter first, like a function signature
The frontmatter is the contract. Title, summary, tags, category. Before you read a word of body, ask: does this title make a specific claim, and does the summary deliver on it? If the title is "How we cut build time" and the summary says "some thoughts on performance," the draft is already broken and you don't need to read the body to know.
This is the equivalent of reading a function signature before the implementation. If the signature is wrong, the implementation can't save it.
Common frontmatter failures I reject without reading further:
- Title is a category, not a claim ("Thoughts on AI workflows")
- Summary repeats the title in different words
- Tags don't match the actual content shape (a "performance" tag on a product positioning post)
Read the headings as a diff
Next, I read only the ## headings, in order. Nothing else. This is the structural pass.
The question: do these headings, read alone, tell a coherent story? Can I predict roughly what each section will say, and does the sequence build? Or is it five interchangeable buckets that could be shuffled without consequence?
This catches the "structure ghost" pattern I wrote about in notes against AI slop. The model is very good at producing locally coherent paragraphs and very bad at producing a globally coherent argument. The heading-only read exposes that immediately.
If the headings don't tell a story on their own, I leave a top-level PR comment and stop. No point reviewing prose under a broken outline.
Read the first and last paragraph of each section
Now the third pass. For each section, read the opening sentence and the closing sentence. Skip the middle.
You're looking for two things: does the section start by naming what it's about, and does it end by handing off to the next section or landing a point? If a section opens with "It's worth noting that there are many considerations..." you've found a hedge avalanche and the whole section is probably padding.
This pass is fast. On a 1200-word draft it takes about ninety seconds. It catches more than you'd expect.
Now read the body, but only for claims
The slow pass. Read the full body, but with one filter: every assertion is a claim that needs evidence or a qualifier. Highlight any sentence that says X "is" Y without saying who measured it, when, or under what conditions.
In a code PR, this is the equivalent of reading the actual logic, not just the structure. Examples of claims I always push back on:
- "This is the most efficient approach." (Compared to what?)
- "Developers prefer X." (Which developers? How many?)
- "This pattern scales." (To what load? With what tradeoffs?)
In Branchpost, the publication context includes a claims_to_avoid list, which catches a lot of this upstream. But the model still sneaks in soft versions of forbidden claims, and the review pass is where you catch them. More on why that input matters in the post on publication context.
Check the code, if there is any
If the draft includes code blocks, run them. Or at least read them with the assumption that they're wrong until proven otherwise.
AI-generated code in blog posts has a specific failure mode: it looks idiomatic and compiles in your head, but it uses an API that doesn't exist, or it uses one that was deprecated two versions ago. The fix is mechanical: copy the snippet into a scratch file and check it against the actual library version you're recommending. If you wouldn't merge untested code, don't merge untested code-in-a-blog-post either.
Leave line comments, not regenerate requests
This is the behavioral shift that matters most. When the draft is a PR, you have two tools you didn't have in a chat window: line comments and suggested changes. Use them.
A line comment that says "this paragraph contradicts the one above it, see line 34" produces a better next revision than "regenerate this section." The model, or the human revising after the model, gets a specific anchor. Vague feedback produces vague rewrites. This is true for junior engineers and it's true for LLMs.
If you find yourself wanting to type "make this better," stop and ask what specifically is wrong. If you can't say, the draft might be fine and you might be reacting to a stylistic preference. Note it as a preference, not a defect.
When to reject the whole PR
Sometimes a draft is unfixable at the line level. Signals:
- The thesis is wrong or absent
- The structure can't be salvaged by reordering
- The post is a rephrased version of something you already published
- The post doesn't sound like your publication, even after edits
In code review, you'd close the PR and ask for a redesign. Do the same with prose. The sunk cost of an almost-right draft is the most expensive thing in an AI content pipeline, because it eats reviewer attention that would have been better spent on a fresh attempt.
The takeaway
Reviewing an AI draft is not proofreading. It's the same multi-pass review you already do for code: signature, structure, logic, details, and then a yes or no. The PR surface gives you the tools. The discipline is on you.
Branchpost watches your repo and opens PRs with blog drafts. You review them like code. branchpost.dev