You have a blog that moves too slowly, and a language model that writes an article in two minutes. The temptation is to plug one into the other. I have built what I call an AI content machine, and what I take from it fits in a few words: the model is the easy part. The work happens before it writes, and in what human review keeps afterwards.
This blog is written with that machine, and I would rather say so straight away, since you would probably wonder. Here I describe how the chain is organised, what it blocks, where I put the review, how a correction becomes a rule, and what Google says on the subject in its documentation.
01What I mean by a content machine
It is a sequence of steps, and each one leaves a written trace: a calendar of topics, a brief, the drafting, an automated check, publication, the English version, then a delivery summary. Only one of those boxes is handed to the model. The rest looks like project management: deciding what gets published, for whom, with what evidence, and checking that it is really what is live.
The principle holding it together is simple: the tool carries what can be verified, the writing keeps what needs judgement. Counting words, spotting a figure without a source or a dead link is a job for a program. Choosing the angle, judging whether an example stands up, is mine.
The same engine runs on several sites with the same steps. At Moonworkers, my own payroll software company, the machine publishes two articles a day. The steps do not change from one site to the next, the rules do: they live in a configuration file specific to each site.
02What Google actually says about content written with AI
I often hear two opposite ideas: "Google detects and penalises AI" and "Google doesn't care". Its documentation is more precise than either. In its guidance on AI-generated content, Google writes that AI can be useful for researching a topic and for adding structure to original content. It adds that generating many pages without adding value for users may breach its policy on scaled content abuse.
That policy sits in its spam policies: scaled content abuse means many pages produced mainly to manipulate rankings rather than to help people. The tool is not the issue. The intent and the result are.
Two other points on the same page changed the way I review. Google reminds readers that models do not retrieve facts, they predict a likely sequence of words, so facts need checking before publication. It specifies that this check also covers titles, meta descriptions, structured data and image alt text. Those are precisely the fields people forget to review, and my check reads all of them.
Finally, its page on helpful, reliable content asks three questions: who wrote it, how, and why. It advises explaining the use of automation when a reader might wonder how the text was produced. Hence the sentence in my introduction.
03Everything happens before the model writes
Ask a model to "write an article about recruitment" and you get an average, plausible text with nothing in it the reader could not find elsewhere. That is not the model's fault: it was given nothing else.
A brief that refuses to move on
Before drafting, every topic has a brief file, and a command validates it. While something is missing, it answers "BRIEF REFUSED" with the list of gaps. On this blog, the minimum is:
- a described reader and a written promise, not the template's sample text;
- an angle of at least 60 characters, drawn from what I have actually done;
- three secondary keywords and four real questions, each with where it came from;
- four sources that have been read, two of them institutional, each with the claim it supports;
- three internal links to pages that really exist.
The angle is what makes the difference. It can only rely on a closed list of facts already published. If the topic calls for experience that is not on the list, the article is put "on hold" with a note for me instead of being written. An invented anecdote is worse than an article without one.
Keeping the model to what it is given
My drafting prompt is not a long free-form text. The model receives, in order, the references to read (the voice, the usable facts, the structure, the rules), then the validated brief, then examples of sentences that ring true and false. It is close to what Hannah Moran and Christian Ryan of Anthropic recommend in their Prompting 101 workshop: task and role first, the provided content, detailed instructions, examples, then a final reminder. That reminder is there to prevent hallucinations: do not invent a detail missing from the data, and point back to the source data for every factual claim.
Anthropic's documentation on reducing hallucinations points the same way: allow the model to say it does not know, restrict it to the documents provided, have it back each claim with a quote. The same page warns that these techniques reduce errors without removing them. That is why the check that follows exists.
04Where to put the human review
Reviewing "at the end" is not enough. I put in three checkpoints, because each one catches different errors.
Before drafting: approve the brief
This is the shortest review and the one that saves the most time. Does the topic deserve an article? Does the angle rest on a real fact? Are the sources serious and read? A weak brief produces an article that needs rewriting. Better to stop it here.
After drafting: the gate, then my judgement
A command reads the article against its brief and returns a red, amber or green verdict. A single red blocks it: an em dash character, "In conclusion", an external link missing from the source register, a forbidden name, a dead link. Amber flags what may be legitimate, a figure without a source in the same paragraph or a word to watch, and the article only goes out with a written justification for each point. Then I review the voice: does it sound like me, or like any generated text?
After going live: look at it as a visitor
The article goes live with a "to review" status, and I switch it to "Reviewed" once I have read it on the site. The check happens on the public page, not in the CMS form: a site can look fine to the logged-in team and be broken for visitors, because of a cache. So I check as a visitor would: the page responds, the image shows with its alt text, the links lead somewhere. It is the same logic as acceptance testing before go-live.
05Turning every correction into a written rule
A correction made by hand serves once. Written down as a rule, it serves every article that follows.
On one engagement, a proofreader reviewed the articles and sent back her comments. Rather than correcting text by text, I turned her feedback into written rules in the pipeline. A comment made once should never need making again, and her attention could go to what no rule can see.
These rules live in the configuration, not in the prompt. A rule mentioned in a prompt gets forgotten; a rule in the config blocks. Mine holds two lists of phrases: a red one, for the stock calls to action and consultant jargon that give away generated text, and an amber one, for inflated adjectives, which turns red beyond two occurrences. Other rules remain a matter of judgement: does an example stand up, is a piece of advice honest? To write a rule down, I use this format:
``` Rule: what is expected, in one sentence. Why: the correction that gave rise to it. Check: automated or review. ```
The "why" line matters. Six months later, it is what lets you decide whether the rule still earns its place. And when the rules change, deliberately bad test articles must still come out red: otherwise the check has been weakened without anyone noticing.
06What the machine does not do well
It does not know what you have lived through. Without facts supplied, it writes what everyone writes, and that is exactly the kind of page Google describes as adding no value.
It does not remove human work, it moves it. The time saved on drafting goes into preparing briefs, reading sources and reviewing. If nobody has that time, I advise against building a machine: better two carefully written articles a month than forty nobody has reviewed.
It pushes you to force things. Running automatically, the pressure to finish pushes towards inventing a source or justifying an amber you could not defend. My rule: an article that cannot pass honestly is abandoned, with a note, and the topic goes back to "to do". I would rather drop a weak topic than publish it because the machine can.
07Where to start
The bottleneck in content production is not always the writing. Sometimes it is publishing, done by hand. In that case, I automate publishing before producing more. To start on Monday:
- List ten topics, and for each one what you have lived through on it. Those with nothing in the second column can wait.
- Write the standard brief for an article, and the command that refuses it when it is incomplete.
- Decide what the automated check blocks and what you keep for review.
- After the first three corrections, write the first three rules.
- Automate publishing and monitoring, for example with SEO reporting that goes out on its own, and only then increase the pace.
It is one of the things I set up in my automation and content services. If you want to build your own, we can talk about it.