Skip to content
juniordev4life
Go back

How This Blog Writes Itself - And Why I Still Review Every Word

A confession before anything else: an AI drafted the post you are reading. It researched the topic, structured the argument, and wrote these sentences in a voice trained to sound like mine.

If that makes you want to close the tab - wait one paragraph, because here is the more interesting part: before this went live, I read every word in a pull request, exactly the way I review code. I edited what missed my point. I set the publish date. I pressed merge. Nothing on this blog reaches you without passing through me - and the system is designed so that it cannot.

That combination - machine does the production, human owns the judgment - is the entire trick. Since I keep writing about coding with AI, orchestration, and review as the new bottleneck, it is time to show you the machinery behind the curtain. This post is the case study, and I am the case.

The pipeline, end to end

My setup is deliberately built from boring parts - a database, a git repo, a static site:

  1. Ideas live in a database. Every article starts as a row in a Notion table: a title, my angle in two or three sentences (the opinion is mine, always), a type, an audience, target tags, and a publish date. Collecting ideas costs me minutes; some come from LinkedIn discussions, some from my daily work, some from readers.
  2. An agent skill runs the production. When I trigger it, the agent picks the next open idea and works through a written playbook: research the topic and collect real sources, write the draft in my voice, derive the URL slug, run the formatter and the site build, open a pull request against main - and write the research notes, sources, and a LinkedIn draft back into the idea’s database row.
  3. I review like it is code. The PR is where the human happens. I read every paragraph, check every claim against the linked sources, fix what does not sound like me, and sometimes reject an entire draft. The agent never merges. It literally has that rule in its instructions - and no permissions to do otherwise.
  4. Publishing is boring on purpose. On merge, the static site rebuilds. Posts with future dates stay hidden until their day arrives - so I can merge five reviewed articles on a Sunday and they publish themselves across three weeks, one by one, while I do other things.

One idea, one article, one PR. Batchable, reviewable, reversible.

What the machine is genuinely good at

After dozens of articles through this pipeline, the machine’s strengths are clear:

What stays mine - and why the blog survives it

Here is the part that decides whether such a pipeline produces a blog or a content farm:

The industry data suggests this split is where most serious teams are landing: about 72% of high-growth content teams now use AI in their workflow - but only 28% publish fully autonomously. The human in the loop is not a transitional compromise. It is the design.

The guardrails, written down

The safety of this system is not good intentions - it is rules baked into the agent’s playbook, versioned in git like any other code:

And when something slips through anyway? The first drafts ever produced failed the CI formatter; one build ran on the wrong Node version. Each failure became a new line in the playbook, and the mistake never returned. The corrections feed back into the system - which is precisely what a review loop is for.

If you want to build your own

The transferable lessons, in the order I learned them:

  1. Put the human gate where the risk is. For content, that is publication - so the gate is a PR. Find your equivalent and make it structurally unavoidable, not culturally optional.
  2. Write the playbook down. Voice, conventions, red lines - in a versioned file the agent must follow, not in your head. Every failure becomes an edit. The system learns without any model training.
  3. Seed opinions; delegate arguments. Two sentences of genuine angle turn a generic essay into your essay. Skip that step and no amount of review will make it yours.
  4. Keep the output inspectable. Plain markdown in a git diff beats any CMS preview. Review tooling you already trust is worth more than fancy AI features.
  5. Let scheduling absorb the batch. Producing in batches and publishing on a calendar decouples your workflow from your readers’ experience.

The editor-in-chief

Nobody expects the editor-in-chief of a newspaper to write every article. The newsroom reports, drafts, and files stories all day - fast, capable, tireless. And yet nothing prints until it crosses the editor’s desk. The editor decides what the paper stands for, which stories run, which claims need a second source, which sentence would embarrass the masthead. Some days they rewrite a lede; some days they kill a piece entirely. The paper’s soul lives at that desk, not in the typing pool.

That is what this blog has become. The newsroom happens to be a machine now - faster than any staff I could hire, and never once offended when I strike a paragraph. But the desk is still mine. Every word crosses it. Every word will keep crossing it.

Because the moment nothing crosses the editor’s desk, you do not have a newspaper anymore. You have a printer, running unattended in an empty room - and everyone can tell.


Share this post:

Previous Post
What a Penetration Test Taught Us About "Done"
Next Post
AI FOMO - The Quiet Exhaustion of Keeping Up