Stop Editing Fluffy AI Drafts. Start With a Source Pack.
An AI agent left 81 lines of raw merge-conflict code on a live page. Four days later, the site lost about 95% of its Google traffic, per zonted.com. That's the cleanest argument I've seen against the "we'll fix it in editing" approach to AI content.
Most small teams use AI backward. They generate a draft first. Then they try to fact-check, soften claims, add links, and clean up the confident nonsense after the fact. That feels fast. It usually isn't.
The better move is simpler: lock the evidence before the draft exists.
How do I make AI-written content publishable faster?
Build a source pack first.
Per Gregory Shevchenko's post on gregshevchenko.com, a source pack is the "evidence boundary" for an article. It holds the approved sources, claim inventory, rejected evidence, source-to-section mapping, FAQ and schema plan, and post-publish checks.
That sounds heavier than a normal brief. For a tiny team, it's actually lighter where it matters.
A normal AI workflow creates work late:
- draft the article
- find weak claims
- hunt for sources
- delete unsupported sections
- rewrite the intro because the whole argument changed
- review again before publishing
A source-pack workflow moves that work upfront:
- define the target query
- list approved sources
- note the claims you can defend
- record weak or rejected evidence
- add product proof, examples, and quotes
- generate from that packet
Now the model has rails. It can still write badly. But it can't wander as far.
The usual AI failure is not bad grammar. It's unsupported confidence.
Small SaaS teams pay for unsupported confidence twice: once to publish it, once to clean it up.
The draft sounds polished. The sentences are clean. The page looks done. Then you read closely and realize half the piece is built on mush.
No source for the number. No proof for the product claim. No counterpoint. No way to tell whether a strong statement came from your experience, a primary source, or the model making stuff up.
That's exactly why a source pack helps. As Shevchenko puts it, it defines what the page is allowed to say and what it isn't.
That matters more now because Google seems increasingly willing to judge sites at the pattern level, not just the page level. Formative Digital cites Knowledge Hub Media and Peec AI 2025 data showing domains that published 200+ thin AI posts in three months lost 28% organic traffic on average, including strong pages. Their point is brutal and useful: readable isn't enough when the whole site starts to look mass-produced.
And when something clearly breaks, the damage can spread fast. On zonted.com, the merge-conflict incident led to a deeper cleanup that found 1,244 broken links, 237 broken images, and 32 latent bugs. Once Google looked closer, it found more than one mistake.
Small teams should take the hint. Don't rely on the last review pass to catch everything an AI system can get wrong.
A source pack is simple enough for one founder to run
You do not need a newsroom workflow for this.
For one article, your source pack can fit on one page:
- Target query: what exact question is this page answering?
- Approved sources: official docs, your own product data, customer proof, expert references.
- Claim inventory: the 5-10 points the article must make.
- Rejected evidence: weak stats, shady blogs, old numbers, anything you don't want repeated.
- Section map: which source supports which section.
- FAQ and schema intent: what follow-up questions should the page answer?
- Post-publish checks: what needs verification before and after the page goes live?
That's it.
The useful constraint is that every important claim should point back to one of three things:
- a source
- a product proof point
- a clearly labeled opinion
If it points to none of those, it probably shouldn't ship.
This also makes refreshes and updates much less painful
Most content updates are miserable because nobody knows where the article's claims came from.
So when a stat changes, a feature ships, or a competitor moves, you have to re-audit the whole page line by line. That kills velocity.
With a source pack, the update path is obvious. Swap the outdated stat. Add the new product proof. Regenerate the affected section. Re-run the checks.
You're not revisiting every sentence like a crime scene.
That matters if you're a solo founder trying to build a content habit that survives contact with actual work.
The real win here is not prettier copy. It's a repeatable system for publishing pages you can defend, cite, and refresh without starting over.
If your current process starts with "let's see what the model gives us," flip it. Start with the evidence packet. Then draft from that. You'll spend less time editing fluff and less time worrying about whether you just published something you can't stand behind.