I Automated My Blog Until It Became Boring

I Automated My Blog Until It Became Boring

I Automated My Blog Until It Became Boring

I built a system that could research, draft, format, illustrate, and upload multiple articles with very little manual work. It succeeded at production and failed at publishing: the output was consistent, factual, and increasingly difficult to care about.

Table of Contents

The system did exactly what I asked

My publishing stack was not a toy prompt that produced a paragraph and waited for me to copy it. It was an operating pipeline.

One scheduled workflow gathered current sources, selected topics, produced English articles, generated supporting images, converted the drafts to HTML, and sent them to a self-hosted Ghost publication through the Admin API. A second workflow prepared practical Korean articles for a separate platform. A third produced posts for a WordPress community site. Local Markdown files acted as the source archive, while a private dashboard helped me review pending work.

The tools were chosen for practical reasons:

  • Ghost gave me a clean publishing interface, memberships, newsletters, and an Admin API.
  • PikaPods let me run Ghost and WordPress without maintaining an Ubuntu server by hand.
  • Cloudflare handled DNS and later connected a private local dashboard to a stable hostname.
  • Claude Code handled much of the original file-based workflow.
  • Codex became a second operator when the original workflow was unavailable.
  • Resend handled low-volume transactional email for the Ghost installation.

None of those choices was the mistake. The mistake was the success metric I gave the system: publish a fixed number of articles on schedule.

When output count is the target, the machine naturally optimizes for topics that are easy to source and easy to structure. Product announcements, benchmark tables, corporate statements, and research papers are perfect inputs. They contain names, dates, numbers, and quotes. They also produce the same article shape over and over: announcement, explanation, comparison, implications, checklist.

The pipeline became reliable enough to conceal the weakness of the product.

Automated content factory producing a uniform queue of blog drafts

## How useful automation became content inventory

At first, consistency felt like quality. Every article had verified sources. Every image had a defined purpose. Every draft used the same metadata and publishing rules. Broken links and malformed Markdown became less common.

But readers do not reward a content pipeline for being well organized.

They reward an article for helping them do something, understand something, or feel something. My system could summarize why a new AI model mattered, but it could not automatically create the missing first-hand contribution. It had not installed the model on my machine, measured my actual hardware, lost an afternoon to a configuration error, or changed a business decision because of the result.

That distinction matters in search as well as in writing. Google’s people-first guidance asks whether content demonstrates first-hand expertise, adds original information beyond other sources, and avoids being mass-produced across many topics. Its newer guidance for AI search makes the same point more directly: a first-hand review offers a unique perspective, while a summary often repeats what is already available.

I had built a technically sophisticated way to manufacture commodity information.

The failure was not that AI wrote sentences. AI can be excellent at outlining, checking consistency, comparing documentation, and editing. The failure was publishing before a human experience existed.

What the automation produced well What the article still lacked
Verified dates and product facts A reason I personally cared
Consistent headings and metadata A real conflict or decision
Fast comparison tables Measurements from my own use
Clean draft publishing A distinctive voice
High output volume A memorable outcome

The signals that made me stop

The first signal was emotional: I did not want to read my own drafts.

That is a brutal but useful test. If the person who commissioned, researched, and owns the publication feels no curiosity after the headline, an unfamiliar reader has even less reason to continue.

The second signal was structural. Different topics produced nearly identical articles. A model launch, an enterprise agent service, and a biotechnology paper all became a “what happened / benchmark / tradeoff / decision framework” package. The facts changed. The reading experience did not.

The third signal was commercial. The content had weak purchase intent. A reader curious about a headline is not necessarily trying to choose hosting, configure a private service, buy an automation tool, or download a template. Traffic without a useful next action is difficult to turn into affiliate or product revenue.

The fourth signal was the absence of proof. I could show generated illustrations, but not the terminal command I ran, the screen I configured, the bill I paid, or the mistake I fixed. Those are exactly the artifacts that make a technical article believable.

Publishing output rising while editorial distinctiveness and owner interest decline

I am deliberately not inventing a dramatic traffic number for this article. The honest conclusion is simpler: the volume was not producing enough meaningful reader value to justify continuing the same strategy.

The workflow I am replacing it with

The new unit of production is not an article. It is an experience.

I first build, migrate, test, repair, or measure something in my own operation. During the work I keep a small evidence folder: redacted screenshots, commands safe to publish, costs, alternatives considered, and the decision I made. Only then does the material become a post.

The publishing workflow now looks like this:

  1. Start with a real operational problem. A private dashboard needed a stable address without another deployment.
  2. Record the decision. I compared a Worker, a Quick Tunnel, a Named Tunnel, and private-network alternatives.
  3. Keep evidence. I saved the non-sensitive configuration shape, failure modes, and before-and-after workflow.
  4. Use AI as an editor and researcher. It checks official documentation, organizes notes, and challenges unsupported claims.
  5. Leave ownership with the operator. I decide what happened, what was surprising, and what I would recommend.
  6. Publish fewer pieces. One useful build log is more valuable than several interchangeable summaries.

This does not mean abandoning automation. It means moving automation behind the experience instead of placing it in front.

Tools and alternatives mentioned

  • PikaPods — the managed open-source app host I currently use. This is an official, non-affiliate link.
  • Cloudflare Tunnel — the local connectivity layer I currently use. This is an official, non-affiliate link.
  • Ghost — the publishing platform I currently use.
  • Claude Code and Codex — the two agentic work environments involved in my workflow.

Frequently Asked Questions

Did AI-generated content cause the problem?

Not by itself. The deeper problem was publishing summaries without first-hand value. AI made that weak strategy easier to scale.

Will I stop using Claude or Codex for writing?

No. I will use them for research support, editing, file operations, validation, and draft preparation. They will not invent the experience that the article claims to describe.

Is publishing less often bad for SEO?

Google explicitly says it has no preferred word count and warns against producing large amounts of content across many topics merely to attract search traffic. A clear purpose and original value matter more than filling a daily quota.

What will replace daily AI news?

Build logs, practical guides, tool comparisons based on actual use, and transparent operating experiments.

Key Takeaways

  • My automation succeeded at volume but optimized for the wrong outcome.
  • Verified information is necessary, but it is not the same as original value.
  • A first-hand artifact—measurement, screenshot, failure, or decision—should exist before drafting.
  • AI is more useful behind a human experience than in place of one.
  • The new strategy is fewer articles with stronger evidence and clearer commercial relevance.

How this was written

This article is based on my operation of multiple AI-assisted publishing workflows and my decision to stop treating article count as the primary output. AI helped organize the draft and verify product documentation.

References