The Git Reporter: How a morning automation became a team of AI reporters managing a newspaper
It started as a Clawd automation project.
The first idea was almost naive: what if an agent could wake up every morning, look at what changed in code I was interested in: agents and understand why it mattered, write a small article, and post the result back to me?
Not a dashboard. Not a changelog. A tiny article made from source code. I wanted to read something I cared about rather than scrolling click-bait social media and news
I've been usin Claude Code and Codex everyday for months. They have become so good at understanding the code that it sparked this idea.
Why not use them to monitor interesting and high velocity projects and tell me what's going on, and why not doing trying to make it really good and entertaining?
So I tried to give the agent a job: follow the code, find the meaning, write the story.
Clawdbot was a thing, let's try.
The first working version was a scheduled Clawd/OpenClaw job.
Every morning, it had to:
- read what it published yesterday;
- avoid repeating the same topic;
- scan relevant repositories and trends;
- use
git,gh, andgsio(a CLI tool I wrote) to ground the story in evidence; - draft an HTML article;
- save notes and sources;
- publish the page locally;
- verify the URL;
- post a short trail log back to Discord.
That workflow mattered more than the publication space. Discord was easy, and at that stage, it was just the place where the article landed. The real product was the loop: source code in, entertaining explanation out.
The first successful daily run I found in the traces was on March 5, 2026. It published an article, created a research folder, saved its notes, updated state, and posted a local link.
It also failed at something immediately: one of the expected tools, gsio based on GitSummary, was hard to keep working reliably.
I like that detail because it tells the truth about how these projects really start. The system was useful before it was clean. It published anyway, and it wrote down the missing part.
Through March, the baseline automation kept producing daily articles.
At some point, I added a second lane called agent-daily.
That lane was an A/B test. The first lane could follow a strong daily change in one or two repositories. The second lane had to look for broader patterns across multiple projects.
This changed the editorial center of gravity.
The best articles were no longer "this commit changed this file." They were more like: "three different agent runtimes are solving the same invisible problem in different ways, and that tells us something about where the field is going."
That was the moment The Git Reporter started to feel like a newspaper to me.
Not because it had a nice layout.
Because it had a beat.
But it was a pain to make it work reliably.
Then the Automation Started Breaking
The failure story is not separate from the project. It is part of the project.
The original automation was ambitious, but it depended on a lot of fragile things:
During ~1 month, I've had so many different issues with Clawd, becoming OpenClaw and breaking quite often. Generating artifacts from the commits everyday broke because commit size, context window overflow, cost management, commit artifacts quality.
The baseline job recorded 70 runs. Twenty-five finished successfully. Forty-five ended in error.
The successful period ran from March 5 through April 1, but even that period was not perfectly smooth. There were auth problems in mid-March. One article was written while delivery failed. Another run was aborted even though its summary still pointed to a published article.
Then April arrived, and the failures became the story.
From April 2 through April 7, the daily jobs repeatedly failed with network fetch errors. Starting April 8, the failures shifted to OpenClaw OAuth refresh errors. By May 12, both scheduled jobs had accumulated 41 consecutive failures.
That sounds bad, and operationally it was.
But it also clarified the architecture.
The automation had proved that the editorial loop was valuable. It had not proved that the whole newspaper should be directly coupled to a scheduled agent, private credentials, local machine state, and Discord posting.
Then Codex became a reliable and polished OpenClaw-like multi-purpose agent, and I switched to it.
The Automation Found the Product. The Failures Found the Architecture.
When I revived the project in May, I did not try to simply reconnect the old automations with Codex.
I built a private production workspace instead.
That workspace keeps the messy parts where they belong:
- recovered source material;
- process notes;
- candidate scans;
- repo caches;
- feedback;
- internal evidence;
- build scripts;
- validation tools.
The public output is a separate thing.
Articles can leave. Public evidence can leave. The generated static site can leave. But raw process traces, local paths, private context, and automation internals stay inside.
This was the big design shift.
The Git Reporter became less like "a bot that posts articles" and more like "a newsroom pipeline with a static public edition."
What It Looks Like Now
The current version has a clearer shape:
- a private workspace where reporting and drafting happen;
- daily article source files;
- evidence pages;
- a generated archive;
- a static site export;
- public repositories for sanitized content and hosting;
- a custom domain at thegitreporter.com.
The homepage is generated from the latest edition. Articles have receipts. The archive is grouped by date. The public site is static and boring in the best possible way.
The boring part is important.
After watching the original automation fail on credentials, network access, delivery, and local state, I want the public surface to be simple. Static files. Public evidence. No dependency on the morning job being healthy at the exact moment someone reads the article.
What I Learned
The project taught me something about AI agents that I keep seeing in other contexts too.
The exciting part is not the agent doing a task once.
The hard part is making the work repeatable, inspectable, recoverable, and safe to publish.
The old Clawd automation was exciting because it showed that an agent could behave like a junior reporter with a real beat. It could wake up, investigate, write, and leave a trail.
But the current version is more mature because it accepts that investigation and publication are different responsibilities.
Private investigation can be messy.
Public publishing needs a boundary.
I still want the morning loop back. I want the agent to scan repositories, find candidate stories, prepare evidence, and draft the daily edition.
And I really enjoy reading it every day.
Still a ton of work to make it better, but worth launching it today.