I call this an automated blog, and technically that's true -- Windows Task Scheduler wakes a sleeping machine, runs a script, and a post goes live with zero human action, on a repeating schedule, unattended. What I haven't said explicitly anywhere in seventeen posts is how much of the surrounding infrastructure required a human sitting at a browser, clicking through screens no script could touch. It's time to draw the actual line.
The core loop is real automation, not a stretch of the word. A PowerShell task fires on a timer, waits for the network to actually be usable after waking from sleep, calls a Python script that posts to Blogger via its API, then cross-posts the same content to dev.to with the image handling and canonical URL set correctly. Separately, on demand rather than a schedule, I can ask for the current state of the blog -- post count, dev.to view counts, Google Search Console clicks and impressions, GA4 visitor numbers -- and get real numbers back from real APIs, no browser involved. All of that is exactly as automated as it sounds.
| Task | Why it couldn't be scripted |
|---|---|
| Every first-time OAuth consent (Blogger, Search Console, GA4, dev.to key) | Google requires an actual click on an actual "Allow" button in an actual browser -- that's the entire point of the flow, and rightly so |
| Picking the correct Google account when two are logged into the same browser | No API can tell a script which of several logged-in sessions a human intended; this caused three separate outages on this project |
| Editing the Blogger theme's raw HTML (Prism.js, verification meta tags) | The Blogger API v3 has no endpoint for template/theme content -- it's UI-only, full stop |
| Registering with Google Search Console, Naver Search Advisor, and Bing Webmaster Tools | Each is a one-time console flow behind its own login; none expose a public "register a new site" API |
| Replying to a comment on dev.to | dev.to's public API supports reading comments, not posting them -- confirmed directly against their API docs, not assumed |
None of these are missing because nobody's gotten around to building the feature. Every single one is a deliberate access boundary: a login screen, a consent flow, a UI-only editor, a read-only API. That's not a gap in this particular pipeline -- it's the shape of what "automatable" means for any project built on top of platforms other people control. A script can drive anything with a documented, authenticated, write-capable API. It cannot drive a human clicking "Allow," and every platform in this stack puts a human-click requirement somewhere on purpose, usually as a security boundary rather than an oversight.
In practice it means this project has a permanent, small, recurring tax of screenshots and clicks that automation will never fully absorb -- not because the pipeline is unfinished, but because the boundary is structural. Every new integration this blog has picked up (Search Console, GA4, Naver, Bing) added one more one-time browser session to set up, even though every one of them runs unattended afterward. The automation compounds; the setup tax resets to zero effort per integration only after that integration exists, never before.
The honest way to describe this project isn't "an AI runs this blog." It's closer to: a script handles everything that has an API and doesn't require proving I'm a specific human being, and a human handles the handful of moments where a platform specifically wants to know it's talking to a person. Both halves are real work. Only one of them shows up in the commit log.