I’ve been running this blog for a couple of years now. Not religiously — more in the way a hobbyist picks up a project, puts it down, picks it up again. The writing isn’t the hard part. Finding the time to sit down, choose a topic, remember what I wanted to say about it, then actually publish the thing — that’s where posts used to die quietly in my drafts folder.

So I did what any developer would do when faced with a friction problem: I automated the friction away.

Here’s how the pipeline works, end to end.

The Pieces

The stack is deliberately simple. Nothing exotic, nothing that requires ongoing maintenance beyond keeping a few tokens fresh:

  • Notion — where I keep my topic backlog and writing guidelines
  • Claude Code — the AI assistant that does the actual drafting
  • Hugo — static site generator that turns markdown into a site
  • GitHub — version control and the trigger point for deployment
  • Netlify — watches the GitHub repo and redeploys on every push

Each one does exactly what it’s good at. The novelty is just how they’re wired together.

The Notion Setup

I keep a simple database in Notion called “Blog Post Topics.” Each row has a title, a category, some notes on what angle I want to take, and a status field: Available or Used.

There’s also a separate page called “Blog Draft Guidelines” — basically a style guide I wrote for myself. It describes the audience, the tone I want, the rough structure posts should follow, things I want to avoid. It started as notes I’d refer back to when I lost my voice mid-draft. Now the AI reads it instead.

How Claude Code Plugs In

Claude Code runs locally on my machine as a CLI tool. I’ve configured it with a set of slash commands specific to this blog — /blog-context, /blog-post, /blog-publish. These aren’t magic; they’re just structured prompts that tell Claude what to read and what to produce.

When I run /blog-post, it:

  1. Reads the site config and existing post front matter to understand the blog’s structure and current tags
  2. Reads the style guide from Notion via an MCP (Model Context Protocol) server
  3. Queries the topic database, picks an Available topic, and marks it Used so I don’t get repeats
  4. Writes a draft markdown file with the correct Hugo front matter, in the right directory, with image placeholders where visuals would help
  5. Runs hugo to confirm the build succeeds

The whole thing takes about a minute. I end up with a draft = true file sitting in my repo, ready to review.

What I’ve found is that the draft is rarely publish-ready straight out of the gate — but it’s a genuinely useful starting point. It captures the angle from my notes, respects the tone I’ve described in the style guide, and hits roughly the right length. My editing pass is usually about making it sound more like me and less like a structured summary of my own instructions.

Hugo and the Build Check

Hugo is the site generator. Posts are markdown files; Hugo turns them into static HTML. The draft flag in the front matter means a post won’t appear on the live site until I explicitly flip it to false.

The CLI build check at the end of /blog-post is a small quality gate. If I’ve accidentally broken something in the front matter or used a tag in an unexpected way, hugo will tell me before I’ve committed anything. It’s caught a few subtle issues that would have been annoying to debug after the fact.

GitHub to Netlify

Once I’m happy with a draft, I run /blog-publish. That command commits the file with the right commit message format ([BLOG POST] <title>) and pushes to the main branch on GitHub.

Netlify is watching that repo. The moment a push lands on main, it kicks off a build — pulls the repo, runs hugo, deploys the output. Usually live within a minute or two.

The GitHub repo also doubles as an offsite backup of every post I’ve ever written. Given I’m generating content with an AI and could theoretically lose local files, that’s not nothing.

What I’d Change

The setup works well enough that I keep using it, which is the real test. A few things I’d do differently if I were starting fresh:

The category structure in my content/posts/ directory is inconsistently cased (Productivity vs product vs VSCode). It’s a cosmetic issue but it bugs me. I’d enforce lowercase from the start.

I’d also invest more time in the style guide earlier. The quality of the drafts is directly proportional to how specific the guidelines are. Vague instructions produce vague drafts. The more I’ve tightened the guidance — concrete examples of tone, explicit things to avoid — the less editing each post needs.

The Honest Version

This isn’t a tutorial about AI replacing writing. The blog still needs a person to have experiences worth writing about, to review what’s generated, and to care enough to publish it. What the automation does is remove the coordination overhead — the “where did I put that topic idea”, the “do I have time to set this all up tonight”, the “I’ll do it next weekend” that turned into never.

The friction was real. So was the solution.

If you’re running a Hugo site and you’ve got a backlog of topics you never get to, it’s worth an afternoon to wire something similar up. The individual tools are all well-documented. The interesting part is just deciding what order they should talk to each other in.