How I Built an AI Agent That Writes My Blog From My GitHub

I should write about the things I build. I know I should. I tell clients to do it. And still, most of my best work never made it to the blog, because writing a post from scratch two weeks after the fact is a kind of friction nobody makes time for.

So I built the thing I keep telling clients to build, for my own blog. This is that story.

The problem: good material, zero momentum

I ship code almost every day. Seepient, openfusion, TuskerBrain — each merge carries a real story: what changed, what nearly broke, what I'd do differently. But those stories live in commit messages and diffs, not in anything a reader would want to sit through. By the time I'd sit down to write, the specifics were gone and the blank page was staring at me. The blog became the least reliable thing I produced, which is a bad look for a consultancy that sells automation.

The design: a pipeline with one human gate

I wanted the plumbing fully automated and the judgment fully human. The machine detects the work, gathers the facts, drafts the article, and stages it for review. I decide whether the draft is right, give it context the machine could never have, and flip a switch when I'm happy.

Every stage is grounded: the draft is written only from material pulled from the repo, never invented specifics. The authoring guide for the site is fed to the writer as a hard input, so every draft arrives on voice: first person, concrete, no internal implementation details leaking into a post.

What it actually gives me

This is the part I didn't fully appreciate until I'd used it for a while. The pipeline doesn't just save time. It changes the relationship between building and writing.

The biggest thing: I never face a blank page. The draft is already there when I open the review Doc. It might need work — the angle could be off, a section might need cutting — but I'm editing, not creating from nothing. That's a fundamentally different mental task, and it's the difference between "I'll write that post this weekend" and actually doing it.

I also don't have to remember what I shipped. The pipeline pulls the commits and diffs on its own, so the facts are already embedded in the draft before I see it. No digging through git log, no trying to reconstruct why I made a decision three weeks ago. The context survives because it's captured at the source, while it's fresh.

The review loop itself is something I genuinely enjoy now. I get a message on my phone: new draft ready. I open the Doc on whatever device I'm on, read it, leave feedback in a spreadsheet cell if something's off. The machine revises and comes back. It feels less like managing a tool and more like working with someone who handles the heavy lifting and brings me the parts where my judgment matters.

And the publishing side is invisible to me. I flip one cell from Draft to Approved, and within minutes the article is pushed, deployed, and the live URL lands back in my WhatsApp. I don't touch git, I don't think about the deploy, I don't format anything. The whole "I should publish that" energy barrier is gone.

The one-cell approval gate

The review interface is deliberately boring. Every article gets a Google Doc for reading and editing, and a row in a tracker sheet. One column — Status — is my entire control surface:

• Draft. The machine's first pass, waiting for me.
• Revise. I set this and write feedback in the next column: the angle is wrong, add this context, cut that section. The machine revises and comes back with a fresh doc.
• Approved. One flip, and the article is pushed to the site repo, deployed, and the live URL lands in my WhatsApp.

No dashboards, no approval apps, no meetings. A single cell decides what the world sees, and everything around it happens without me.

Where it nearly broke

Three things broke on the way, and all three were the point:

• The first draft failed the house style. It was full of internal file names and code identifiers — technically true, unreadably inside-baseball. That's what the authoring guide is for: it turned "write like me" from a vibe into a checkable rule set the writer must follow.
• Duplicate topics. The pipeline almost drafted an article about work that already had a post. A dedup check against existing posts stopped it. Publishing the same story twice would have been worse than not publishing at all.
• The gate needed a third state. Plain approve/reject was too blunt — most first drafts need direction, not a yes/no. The Revise state with a feedback column is what made the loop actually usable.

What I'd do differently

The trigger is a poll, not a webhook — fine at my scale, but if I want publish-the-instant-you-approve, an event-driven trigger is the upgrade. Also: the review doc and the published post can drift apart if edits don't get exported back. I'd make the doc the single source of truth from day one.

The result

A merge lands, and a reviewable draft exists within minutes. I read it in a Google Doc, edit if I want, flip one cell, and it's live. The blog now runs on the same loop as the code: ship, review, publish. And for the first time, the thing I tell clients to do — document your work, consistently, without it being a chore — is the thing I actually do.

The same shape — detect, draft, gate, ship — is what most automation engagements need. If that sounds like your workflow, book a call and we'll map where the gate belongs in it.