Building my own replacement, one permission prompt at a time

I spent the weekend enjoying the fall weather, watching college footbal and  building something that is, depending on how you squint at it, either a nice bit of automation or me quietly training my own successor. It’s a weekly agent that reads tech news in my usual lanes, picks one thing worth writing about, and leaves a draft in this very WordPress install for me to edit or bin. If you’ve seen a post show up here with “blog-news-agent” as the author from now on, that’s it, not a new hire.

The idea started simple: point an agent at some RSS feeds, let it summarize, done by lunch…and to use the local AI on my lab machine (where possible). It did not stay simple, and the part I actually want to write about is how it got built, not just what it does.

The process, not just the code

I did this through Claude Code using [superpowers], a plugin that replaces “just start coding” with an actual process: brainstorm the idea into a design, write a spec, turn the spec into a plan with real tasks, then execute the plan with a fresh reviewer checking every single task before it counts as done. Overkill for a toy script. Exactly the right amount of ceremony for something that touches my real website unattended, on a schedule, with no one watching. This is so cool and my wife got tired of me geeking out about all this.
— HIGHLY recommend testing/using superpowers. —

The brainstorming phase is where the design actually took shape: my blog’s posts are personal build-journey writing, not news roundups, so a bot that summarizes headlines would read instantly wrong here. The agreed design instead has the pipeline scout news, pick one topic, try it hands-on where that’s safe to do locally, and write the post as a first-person account, same shape as everything else on this site. Whether it hits that bar is a different question. More on that in a minute.

The plan broke the thing into fourteen tasks. Eleven were code: eight small Python scripts, a markdown file that tells Claude how to run the whole pipeline step by step, and the glue to wire it to Windows Task Scheduler. Each task got implemented by a subagent, then reviewed by a second subagent that hadn’t written the code and had no reason to be nice about it. That review loop caught a real bug in my own plan before any code existed, which is the kind of thing that makes the extra process worth it. Then a final whole-branch review, on the most capable model I had access to, went looking for problems no single-task review could see. It found three, and all three were the interesting kind: not bugs in any one file, but bugs in how the pieces fit together.

The part where production disagreed with me

Here’s where it got honest. The scout script crashed the instant the real driver tried to run it, because `python scripts/x.py` and `python -m scripts.x` resolve imports differently and I’d only tested the second one. The weekly trigger script was truncating its own instructions to about a fifth of their real length, because Windows PowerShell mangles a long multi-line string passed as a command argument, and nobody notices that in a two-line test. And a history file that worked perfectly fine in testing crashed for real, because the folder it was supposed to live in only gets created on a fresh machine the first time something actually writes to it.

None of those showed up until I ran the thing for real, against real feeds, through a real Windows Task Scheduler invocation. Then the actual WordPress publish step failed twice more, for reasons that had nothing to do with my code: the hosting site and Apache’s PHP handler quietly drops the Authorization header unless you tell it not to, so Application Password auth just silently stopped existing. Once I fixed Apache, it turned out the “application password” I’d saved for this a day earlier wasn’t a real one at all, just a plausible-looking string I’d copied from the wrong place.

Every one of those got caught by actually running the thing, not by reading the code more carefully. I’m filing that under “things I already knew about my own production systems and apparently needed to relearn.”

What’s running now

It scouts AWS, Terraform, Kubernetes, and AI-agent-tooling news once a week, drafts something, and leaves it here as a draft under its own author name. It doesn’t touch real cloud infrastructure and it can’t push anything live, by design, no matter what it decides to write. The first real post it managed to publish was, fittingly, about an agent-safety article it tried to test by spinning up a local Kubernetes cluster, got denied by its own permission allowlist, and wrote about getting denied instead. I didn’t plan that bit. It just happened to be the most honest thing it could say.

I’ll be reading everything it drafts before it goes anywhere near “published.” But if the byline says blog-news-agent, you’ll know what that means now. 🙂

Happy building,

D