This post was drafted by a machine. A person read it, changed things, and merged it before you saw it. Since we spend this series describing how other organisations should apply AI to marketing work, it seemed reasonable to open up the pipeline that produces the series itself. This is part of our Practical AI in Marketing series, and it is the only post in it about us.
The backlog is a JSON file
There is no content calendar in a spreadsheet and no monthly planning meeting. Topics live in a JSON file in the same repository as the site, and each entry carries enough context for an agent to write from it:
{
"slug": "an-ai-blog-pipeline-with-a-human-editor-how-this-post-was-made",
"series": "practical-ai-in-marketing",
"title": "An AI blog pipeline with a human editor: how this post was made",
"notes": "Transparency meta-post. Backlog JSON, weekly research, humanised draft on a review branch, LinkedIn copy alongside, human edits and merges. Human gate is the point. Costs per post vs agency.",
"status": "drafted"
}
The notes field does most of the work. It is written by a person who knows what we actually do, which is why the pipeline can produce a post about our own process without me having to write the process down twice. Anyone at PicNet can add an entry. Adding one takes about two minutes, which matters more than it sounds: the old bottleneck was not writing, it was that good topic ideas evaporated between the conversation where they came up and the next time anyone opened the blog folder.
What runs each week
The weekly job is deliberately boring:
- Pick the next backlog item that is ready.
- Run web searches on the topic, scrape the promising results, and write everything into a research file next to the draft. Sources, notes, dates, full text where we can get it.
- Draft the post against a system prompt holding the house rules: word count, Australian English, byline, what may and may not be claimed, which client names are cleared for public use and which are not.
- Run a humanising pass that strips the stock AI phrasing.
- Draft the LinkedIn copy from the same research, in the same run, so the social post and the article do not drift apart.
- Commit the draft, the research file and the social copy to a review branch and open it for review.
Nothing in that list touches the live site. The last step is a person reading the branch and merging it, or not.
Putting content through git rather than a CMS was the single best decision in the build. Every post has a diff, a branch and a merge, and every claim in it can be traced back to the research file sitting beside it in the same commit. Teams are already reworking their software lifecycle around agent output (Ask HN, August 2026), and the review discipline transfers to a content repository without modification. The editor is doing a code review on prose.
Why the human gate is the point
The clearest statement of the problem I have read comes from someone who built a marketing AI system for a 60-person team: "generation is free now... that sounds like good news, and for about three weeks it was." Their conclusion after the build was that the most valuable layer in the system is the one that refuses to write. Once anyone can produce a competent blog post in ninety seconds, the constraint moves to the part of the process nobody had staffed, which is review and editorial judgement.
Engineering hit the same wall first. Sylvain Kalache's framing, AI writes the code, but humans can't review it all, describes teams generating ten times faster while reviewing at human speed, and cites survey data showing high-adoption teams merging 98% more pull requests while review time rose 91%. Content has the same shape and worse consequences, because a bad merge in a repository fails in staging while a bad merge on a public blog is read by your clients.
So we bounded the volume rather than the generation. The pipeline is capped at what one editor can genuinely read in a week, and the editor's job is not to tidy sentences. It is to answer three questions: is every statistic in here actually in the research file, is every client reference one we are allowed to make, and would I say this out loud to a client. Posts that fail the third question get deleted rather than fixed. That happens more often than the volume-obsessed version of this pipeline would tolerate, which is the point.
The prompt also carries a list of things the model must never write: client names that are not cleared for publication, any claim we cannot source, any statistic without a link. The editor checks the list on every branch. Prompts are guidance, not controls, and treating them as controls is how organisations end up apologising publicly.
Labelling what the machine wrote
Beau Cronin's TAIL scale, published on 18 August 2026, gives a 0 to 5 rating for how much of a piece AI wrote. TAIL 4 is "AI substantially authored, with my comprehension, review, and editing", and Cronin describes it as the last level that is meaningfully human in the loop. That is where this post sits, and where the series sits. It is a more honest label than a generic "AI-assisted" footer, because it tells you exactly which half of the work a person did.
Publishing the mechanics is becoming its own small genre, including technical blogs disclosing their own generation process. We would rather be in that group than pretend the drafts are typed by hand.
One thing the humanising step is not for: beating detectors. AI writing detectors such as Pangram are now deployed everywhere and, as the Washington Post reported on 25 August 2026, they aren't always accurate. Their reporting notes a papal encyclical was flagged as partly AI-generated. A detector score is not a quality signal, and optimising a draft to pass one produces text that is neither honest nor better. We run the humanising pass because unedited model prose is full of sales phrasing and stock triads that no engineer would say in a meeting.
What it costs
Per post, the machine spend is search API calls plus model tokens, and it rounds to nothing against an hour of senior time. The real cost is the editor: roughly an hour per post to read the draft against the research file, cut what cannot be supported, and fix the parts where the model wrote something plausible and wrong.
Compare that with an agency retainer, where you pay for both the writing and the research, and where the person writing about your systems has never seen them. The pipeline flips the ratio. We pay almost nothing for the drafting and spend the money on the judgement, which is the part an agency cannot do for us anyway because it depends on knowing what we have actually built.
Volume is not the win, and it is worth being sceptical of pipelines sold on volume. A twelve-month practitioner review of AI content platforms starts from a B2B SaaS blog with 12 published articles and basically zero traffic, which is a fair reminder that publishing more of nothing produces more nothing.
Honest limitations
The pipeline cannot interview anyone. It cannot visit a client site, sit through a workshop, or notice the thing a client said offhand that turns into a good post. Everything original in this series comes from a person putting it in the backlog notes first, and the quality of a post is capped by the quality of those notes.
It also gets things wrong in a specific way: it will produce a confident sentence built on a source that does not quite say that. That is exactly what the research file and the branch review exist to catch, and it is why the editor's hour is not negotiable.
If you want to build something similar, start with the review step. Decide who reads every piece, how long they get, and what they are allowed to reject. Then automate backwards from there. The generation was never the hard part.
PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.
Originally published at picnet.com.au.
