I asked my AI agent to document its own debugging — and accidentally built a blog

I already had an agent that ships HTML to a public URL. So instead of writing the recap of how I built it, I told the agent to write the recap. Then I told it to publish itself. The result is a blogging workflow that costs me one Telegram message per post.

I have a habit of solving the same problems multiple times. Not because I forget — because I never write anything down. By the time I sit down to document a debugging session, I’ve already moved on to the next thing, and the lesson disappears. The friction between “I learned something” and “the lesson is searchable” was always too high for me to clear.

This week I closed that gap. Not by being more disciplined — I’m not — but by lowering the friction to roughly zero.

What I already had

A previous post — the one right before this one in the gallery, if you’re reading this in order — covered how I wired up an AI agent (Hermes, running on a Hostinger VPS) to ship HTML previews on demand. The architecture, in three lines:

• Send a Telegram message → agent writes /opt/data/projects/<name>/index.html
• A persistent Python http.server + Cloudflare Tunnel makes that file live at https://demo.contextforce.com/<name>/
• Agent replies with the URL. I open it on my phone.

That setup took a weekend, lots of dead ends, and a satisfying amount of debugging. The kind of work I always mean to write up and never do.

The realization

While I was wrapping up that work, my agent suggested writing a recap article. I said yes. It produced a Medium-ready post in about 30 seconds. Decent draft, captured the lessons, hit the structure I would have used.

And then I noticed something obvious that I’d been too tired to see: I’d already built the publishing infrastructure. The same pipeline that shipped landing-page HTML could ship blog-post HTML. I didn’t need a CMS. I didn’t need Medium’s editor. I just needed to feed the article into the existing pipe.

So I added a tiny convention on top of what I already had:

/opt/data/projects/blog/
├── index.html              # auto-generated post listing
└── posts/
    ├── from-telegram-to-demo-contextforce.html
    └── i-asked-my-agent-to-document-itself.html  # this post

One folder, one rule: drop styled HTML into posts/ and a tiny script regenerates the index. The blog landing page at https://demo.contextforce.com/blog/ auto-discovers each new post by reading its <title>, lede, and date directly from the rendered file.

The principle: if you’ve already built infrastructure for thing A, look hard for thing B that fits the same shape. Reuse beats greenfield, especially for personal tooling.

The workflow, end-to-end

Here’s the actual loop now. From “I just learned something interesting” to “it’s published” is one Telegram message:

1. I finish a debugging session or a build with my agent over Telegram (or CLI). The conversation contains the full story — what broke, what I tried, what worked, why.
2. I send: “recap what we just did as a blog post in the same style as the existing posts.”
3. The agent reads the relevant context (it has the conversation history), drafts a post following the established voice and visual style, and writes it to /opt/data/projects/blog/posts/<slug>.html as a single file with inline CSS.
4. The agent runs python3 /opt/data/scripts/rebuild_blog_index.py, which scans the posts/ folder and regenerates the blog landing page.
5. The agent replies with the URL of the new post. I read it on my phone, decide if it’s good, and either accept it or tell the agent what to fix.

Total time, from “let’s recap” to “draft published at a real URL”: under a minute.

Why this works for me specifically

Three reasons. None of them are about the AI being magically good at writing.

The agent is already in the room

Most blogging-friction-reduction tools assume you start from a blank page in a separate app. Notion, Bear, iA Writer — pick your poison. The act of switching contexts to “now I’m writing” is itself friction. It’s why most of my debugging notes never become posts.

My agent isn’t in a separate app. It’s the same conversation where the debugging happened. It already has the entire transcript. There’s no context switch to start writing — the writing is just another reply.

The publishing pipe was already plumbed

Building a blog from scratch — even a minimal one — is a project. Picking a static-site generator, choosing a hosting platform, setting up DNS, configuring deploys, designing a theme — that’s a weekend before you’ve written a single word. I already had all of that for landing-page previews. Adding “blog” was just one more folder and a 100-line index-rebuilder script.

The first draft is good enough to react to

Writing-from-scratch is hard. Editing a draft is easy. The agent’s first draft isn’t perfect, but it’s structured, it captures the right beats, and it gives me something concrete to push back on. “Cut the second section, the lessons list at the end is too generic, expand the part about reading the session log” — that’s how I edit. I’m bad at originating prose; I’m fine at sharpening it.

The honest version: the agent’s draft probably gets to 80% of where I’d land if I wrote it myself. The 20% is the part I actually enjoy editing. So I get the slog removed and keep the part that feels like writing.

What this is not

It’s not a content farm. The whole flow only triggers when I explicitly ask for a recap, on something I actually built or debugged. The agent isn’t autonomously generating posts; it’s writing up things that already happened.

It’s not a Medium replacement either, exactly. The HTML files are the canonical version, and from there I can copy into Medium, dev.to, my own RSS feed — wherever. The blog at demo.contextforce.com/blog/ is the source of truth, but the posts can syndicate anywhere.

And it’s not a substitute for editing. Every post still gets a pass from me before I share it widely. The agent gets the structure and the facts; I tighten the voice, kill the cliché lines, push back when the framing is off.

What I learned, even from this

Even this small step taught me a few things worth keeping:

1. Repurpose your infrastructure aggressively. If you’ve solved “how to host one kind of HTML reliably,” you’ve also solved “how to host any kind of HTML.” Look for the next thing that fits the same shape.
2. The agent isn’t writing for you — it’s lowering activation energy. The bottleneck for me was never “could I write the post” — it was “could I be bothered to start.” Eliminating the blank page was the actual win.
3. Conventions beat configuration. One folder, one filename pattern, one auto-rebuild script. No CMS, no front matter parser, no tag taxonomy. The whole thing fits in your head.
4. Iterate on style by example. The agent matches the visual aesthetic of the previous posts because they’re sitting right there in the same folder, ready to be read as references. I don’t need a theme — I have a reference post.

What’s next

A few obvious upgrades I haven’t built yet:

• RSS feed. Trivial to generate alongside the index. People with feed readers shouldn’t need to bookmark.
• Auto-cross-post to Medium / dev.to / Substack. Each platform has an API; the same HTML→Markdown pass that lets me publish there could be a single tool call after each new post.
• Topic tags + filtering. Right now the index is just chronological. Once there are 20+ posts that’ll matter.
• “Suggest a recap when interesting things happen.” The agent could nudge me “this debugging session looks like it had a clean lesson — want me to draft a post?” rather than always waiting for me to ask. Higher leverage but also more dangerous; I don’t want it to start writing about every five-minute task.

None of those are necessary right now. The current setup converts “I learned something” into “it’s published” with one Telegram message, which is the whole point.

---

If you’ve built personal AI tooling and feel like the lessons are slipping through your fingers — try this. The blog isn’t the goal. The forcing function is. Once your debugging sessions reliably produce posts, you’ll find yourself debugging more deliberately, because you know the writeup is coming. That alone is worth the hour it takes to set up.