Zero-Effort Blogging

Most people don’t blog because writing is a separate activity. You finish the work, then you sit down to describe what you did. By then, half the context is gone and the motivation is zero.

What if the blog post wrote itself while you worked?

The setup

You need three things: a screen recorder at 1 FPS, a microphone, and the habit of thinking out loud. Start the recorder, start working, narrate what you’re doing. That’s it. That’s the entire writing process.

When you’re done, a pipeline turns the recording into a post:

  1. Extract audio — ffmpeg -i session.mp4 -vn audio.wav
  2. Transcribe — Whisper runs locally, produces timestamped text. No data leaves your machine.
  3. Extract key frames — ffmpeg -i session.mp4 -vf "fps=1,select='gt(scene,0.3)'" frames/frame_%04d.jpg — scene detection drops duplicate frames. A 40-minute session with a mostly static screen yields 30–80 unique screenshots instead of 2400.
  4. Match frames to transcript — timestamps from Whisper align with frame timestamps. Each screenshot gets its surrounding narration.
  5. Feed to Claude — text + images in, structured blog post out. The LLM cleans up the filler words, organizes the narrative, keeps the screenshots where they matter.

The bottleneck is the LLM’s context window. Claude handles up to 1M tokens — enough for several hours of transcript with screenshots. In practice, a full workday of pomodoro sessions fits without chunking.

Whisper is local

This matters. The audio never leaves your machine. Whisper downloads a model once and runs offline. For noisy audio with filler words and mumbling, the medium model is the minimum — large-v3 if you have the RAM. The transcription quality is the only variable you can’t control after the fact, so don’t skimp on the model.

Pomodoro makes it structured

A raw work session is a stream. A pomodoro session is a unit — 25 minutes of focused work on one problem, with a clear start and end. Record one pomodoro, get one post (or one section of a post).

The timer gives you what every good blog post needs: scope. You don’t narrate your entire day. You narrate one problem, one approach, one outcome. The constraint does the editorial work.

The problem journal

I’ve been thinking about problem journals — a record of problems solved, classified by type, method, and outcome. The idea is that problems outlive every tool built to address them. Solution methods are volatile; problem structures are durable. A log of what you solved and how is both a reflective instrument and an economic signal — the ability to reliably solve a recognized class of problems is a tradeable asset.

This pipeline produces that journal as a side effect. Every recorded pomodoro is a problem-solving episode. The transcript captures what you tried. The screenshots capture what you saw. Claude extracts the structure: what was the problem, what did you try, what worked. Over time, you accumulate a searchable archive of your problem-solving patterns — without ever sitting down to write a journal entry.

The point

The best documentation system is the one you don’t have to operate. Writing is expensive. Narrating is free — you’re already thinking out loud while you work. The only cost is pressing record.