I Automated My Newsroom for Two Days

Last week I did what every founder building with AI tools dreams of doing. I set up a system that ran on its own every thirty minutes, read what Nepal and the US were actually searching for right now, wrote a full news draft in my house style, and filed it without me touching anything. Then, after two days, I switched the whole thing off.

This is what happened in between, and what I learned from it. Not theory. A real experiment with real drafts, real mistakes, and a real off switch.

What I built

The idea was simple. Niguro, my search engine and news portal for Nepal, needs fresh English drafts from Nepali stories. Writing them by hand is slow. So I built an automation that ran every half hour: it read Google’s live Trending page for Nepal and the US, picked an active topic from the last twelve hours, and wrote a short BBC-style article in English, saved as a draft, never published. Draft only, always. No human review, no live post.

The point was volume with guardrails. Let the machine find the stories and write the first draft. I would review the drafts later and publish the good ones.

For about two days, from the last day of September into the first day of October, it ran. A stack of drafts piled up. Nothing went live by accident. The guardrail worked.

Then I looked closely at what the machine had actually produced, and I paused it.

Failure one: stale trends

The first version of the system did not read Google’s live Trending page. It searched the web for descriptions of what was trending, and worked from those. This is like checking the weather by asking a neighbor who checked it yesterday.

I caught it because I know my own country’s news cycle. The topics it picked felt like yesterday’s stories. I told the system the rule directly: read the live Trends page, take only topics that are active in the last twelve hours, never work from search snippets about trends. The fix worked. But the failure taught me the first lesson of this experiment, and the biggest one:

An automation is only as live as its least live input. Every step of a pipeline can be perfect, and if the first step reads stale data, everything downstream is stale. When you audit an automation, start at the source. Ask: what is the freshest thing this system touches? If the answer is a cached summary of the real thing, you do not have an automation. You have a rumor mill with good formatting.

Failure two: the duplicate draft

With the trend source fixed, the system kept writing. Then I found a duplicate: two drafts of the same story. The system’s dedup check had scanned the site’s drafts through the WordPress API’s search endpoint and found nothing, so it wrote the story again. The search endpoint, it turns out, can miss draft posts. The duplicate had to be trashed by hand.

The fix was equally simple: check the actual post list in the admin dashboard, the same screen a human editor would look at, not the API shortcut. But the principle behind it applies to every automation you will ever build:

Dedup against the real system of record, not against a convenient proxy. If a machine is going to add records to a collection, it must read that collection the way an honest editor would read it. Shortcuts in checking produce duplicates in output.

Failure three: volume without a voice

This one was subtler and more important than the first two. The drafts were fine. Clean headlines, proper structure, correct length. But they were not mine. They read like a capable junior reporter who had never visited Nepal. Every draft would have needed real editing before I could publish it: my judgment, my phrasing, my sense of what actually matters in the story.

So I did the math. The system saved me maybe twenty minutes of drafting per article and cost me fifteen minutes of editing, plus the time to review the topic selection, plus the risk of publishing something I had not really read. The automation had moved the work around instead of removing it.

This is the trap of AI content automation. It is easy to measure the wrong thing: drafts produced, hours of writing “saved,” articles per day. The right thing to measure is editing time per publishable article. If the machine’s drafts take almost as long to fix as writing from scratch would take, the automation is theater.

What actually worked

Fairness requires me to say what went right, because two things did.

First, the safety guardrail held perfectly. Every article was saved as a draft. Nothing published itself. When you automate anything that touches the public, this is the one rule that matters most: the machine proposes, a human disposes. I would never build a content automation that publishes without review. The two days proved the guardrail works under pressure.

Second, the cadence worked. Half-hourly runs are a pace no human sustains, and for the narrow job of “find fresh topics and write first drafts,” the machine never got tired. If the drafts had needed only light editing, this system would have been a genuine superpower. The failure was not in the engine. It was in the output quality bar.

Why I paused it instead of fixing it

I could have fixed failures one and two and kept going. Both had clean fixes. But failure three is not a bug. It is a strategy question: what is the point of dozens of drafts I will not publish?

I paused the automation on October 1 to think about this properly. The question I am sitting with is not “how do I make the machine write better.” It is “what job is this machine actually doing for me.” Right now the honest answer is: producing drafts I then have to parent. Until I can answer differently, it stays off.

This is something I keep telling myself about building. Before I built Niguro’s bigger features, I shipped one small thing and watched whether people used it. I have a whole checklist for deciding what deserves to be built at all. How I Decide What to Build Next

The automation skipped that discipline. I built the full pipeline before I had evidence that machine-written drafts were worth editing. Next time, I will start smaller: have the machine find topics only, no writing. If I publish from its topic picks for a month and love the results, then I let it draft.

My checklist for AI automations

Everything above fits on one card, the one I will use before I build the next automation:

1. What is the freshest input this system touches? If it is a summary of the real source, fix that first.
2. Does the machine check against the real system of record before adding anything? If it uses a shortcut, expect duplicates.
3. What is the human’s cost per output, measured honestly? Editing time, review time, risk. If the machine moves work instead of removing it, it is not automation.
4. Does the machine have a hard gate before anything goes public? If no, add one before anything else.
5. Am I automating a judgment I already make well by hand? If I have never done the task manually, I do not understand it well enough to automate it.
6. What evidence would make me keep this running? Define the success metric before launch, not after the first failure.

The newsroom automation failed three of these and passed two. Two days, three lessons, one paused pipeline. I call that a cheap education.

The machine is still there, switched off, waiting. When I figure out the job it should actually do, I will turn it back on. That is the difference between an experiment and a failure. An experiment ends with notes. Mine are these.

If you want the background on why I care about Nepali news being covered properly in English in the first place, here is where it started. Unfurl the Web: Introducing Niguro, Nepal’s Own Search Engine and Internet Portal