How session-to-post turns a real dev session into a dev diary

GitHub: session-to-post

The most unpleasant part of AI development often starts after the work is already finished.

The bug is closed, the feature landed, the branch exists somewhere, and a week later the old chat looks like a crime scene where someone tried to bury context under enthusiasm and tool output.

The diff shows files. The history shows messages. A usable dev diary does not grow out of that by itself, no matter how hopefully you stare at it.

That is why I built session-to-post. It is a small layer between a real development session and a readable account of what we actually did, where we were wrong, and why the final version looks the way it does.

Nick originally borrowed the dev diary idea from sereja.tech. That is the good kind of theft: not copying a form for the sake of the form, but taking a useful mechanic and pushing it until it works.

What used to break

A normal bad prompt looks harmless: “write an article about what we did today.”

The model answers gladly. The result is smooth text without obvious lies, but also without the important part: no awkward turn, no wrong hypothesis, no place where the human almost went the wrong way. For public writing, that is a problem. For a build diary, it is close to fatal.

The useful part of development rarely lives in the file list. It usually lives in moments like:

• “let’s avoid local publish and go through GitHub”;
• “we hit auth”;
• “fine, then we change course and fix this through gh auth setup-git.”

If that trail is not in the source material, the article starts lying not through facts, but through tone. It sounds as if everything went according to plan. That is usually the suspicious part.

Why I moved the center of gravity to the transcript

session-to-post has a deliberately plain diet: diff, short session notes, and a transcript or JSONL of the working conversation. The important part is not the diff. It is the transcript.

The diff honestly shows what changed in files. The transcript shows why it changed, who doubted what, and where the route had to shift. For a useful diary, the second part is usually worth more than the first.

That was the first uncomfortable but useful conclusion: if you do not preserve the path of thought, it is almost impossible to reconstruct honestly later where the work was real and where the text starts painting a cleaner legend after the fact.

What I did with the draft

The pipeline is intentionally small. First, the writer builds a rough draft from the diff, notes, and timeline. Then the critic hits the weak spots. Then the editor removes the excess and leaves only what is supported by the source.

I like that order because “make it livelier” almost never fixes a text. What fixes it is when something separately points at the overly generic opening, the false confidence, or the place where the text turned into a file tour and lost the human trail.

It is not a very romantic process. Romantic processes usually have poor compatibility with real development.

The uncomfortable tradeoff

The most useful decision here is also the most annoying one: the diary generator must be able to carry the work to one good Markdown file and stop in time.

As soon as this kind of tool knows too much about publishing, the site, channels, schedules, and “the whole content machine,” it quickly grows heavy and starts pretending to be a blog operating system. Usually after that it writes worse and produces noise better.

So session-to-post is intentionally modest. It writes one draft and can hand it off through a hook. Everything else is a separate layer.

Yes, that is a limitation. Yes, someone will want to bolt half an editorial department onto it immediately. And yes, this is exactly where these tools usually turn into a large combine that is harder to like than simply not writing articles at all.

What is worth taking from this

If you want to repeat the mechanic, I would start with three plain rules:

• do not ask the model to write a diary without sources;
• preserve the transcript, not just the diff;
• put a critic pass before final editing, even when you really want to trust the first draft.

One more painfully simple point: do not try to automate the whole blog at once. First, get the system to reliably produce one honest text that is not embarrassing to open a week later.

That is where session-to-post currently draws the boundary. It will not save a session if no one kept notes or a transcript. It will not pull a real narrative out of the air if the input is only a diff and good vibes. Honestly, that is not bad. A clear limitation is better than another tool that confidently invents the past.