A commit can tell you when a help button appeared. It usually cannot tell you that the game had already passed its automated checks when the person building it said they had no idea how to play.
That happened in one of my sessions with Claude Code.
The project was BUTTERFLY JOB, a browser game built with Three.js and Blender assets. The player changes the past to make a bank heist possible in the present. The session records successful browser and unit checks. Then, at +3h 43m, I stepped in because I could not work out what to do.
The agent added a how-to dialog, a persistent guide, and a help button.
Those changes belong in Git. So does the reason for them. But unless someone deliberately writes that reason down, the next developer sees the UI changes and has to reconstruct the lesson: a tested path through a game does not establish that a new player can discover that path.
I built Coders Talk to keep that part of working with coding agents.
The correction and the response, preserved together in the public Build.
The diff is only part of the explanation
Git preserves the changes we commit. A good commit message, pull request, or decision record can preserve the reasoning too. I still want all of those.
But a lot happens before the final change makes it into a commit.
You ask an agent to implement something. Its first interpretation is plausible, but misses a constraint. You correct it. It tries another approach. A test exposes a bad assumption. You add a detail that should have been in the opening prompt.
By the time the work is ready, the code looks reasonable. The abandoned approach may be gone. The useful correction sits somewhere in a long conversation, between command output and another test run.
Two weeks later, you remember solving something similar. You do not remember the sentence that changed the agent's direction.
Keeping the raw log helps. Finding the relevant turn, understanding what preceded it, and deciding whether it applies to today's task still takes work.
That is the gap I wanted Coders Talk to fill. I wanted to come back to a session and answer: what was the task, where did the approach break down, and what changed after the human stepped in?
A session becomes a Build
In Coders Talk, a Build is a working session condensed into its key moments, with the underlying record available at the level the author chooses to share.
The format has a goal, a timeline, an outcome, and a verdict: what you would do differently next time. The timeline uses five kinds of moments:
| Moment | What it preserves |
|---|---|
| Prompt | The request or constraint that set the direction. |
| Agent did | A meaningful stretch of work: the approach and what it produced. |
| Intervention | What the person corrected, and why. |
| Fail | What broke or turned out to be wrong. |
| Outcome | Where the session actually ended, including an abandoned attempt. |
You do not need every kind in every session. A run without a human correction is still worth keeping. So is a failure.
The part I care about most is the why attached to an intervention. “I stopped the agent” tells another developer very little. “The tests covered the route, but I could not discover the first action” gives them something to check in their own project.
In the BUTTERFLY JOB session, an earlier correction made the asset requirement explicit: every visible 3D object had to be authored in Blender and exported for the browser. The agent then validated that pipeline with a representative asset before continuing.
The same Build preserves both kinds of intervention: a constraint clarified near the start and a usability problem discovered near the end. That is much more useful to me than remembering only that the agent eventually produced a playable game.
How it gets there
With the plugin installed, you can send the session you are working in:
Claude Code: /coders-talk: build
Codex: $coders-talk:build
For a manual send, the plugin shows what it will upload and where the draft will go. It removes bulky session material, redacts detected secrets locally, and sends the prepared session. The server checks it again.
A model proposes the title, moments, and draft verdict. You can edit those suggestions, explain the reason behind a correction, and confirm the summary describes what happened. The page identifies the model's contribution; summarizing a session does not make the summary infallible.
The result starts as a private draft, or goes to your team's space when the session belongs to one of its repositories. Sending it does not publish it. Auto mode is optional and must be enabled separately.
There is context behind the short read: the agent and model, session duration, interventions, and, where captured, token usage, code changes, and commits. That context helps you judge whether another person's experience is relevant to your task. One successful run does not establish a universal recipe.
You do not have to publish your work
If your useful sessions happen in private repositories, you should still be able to keep the lessons.
Coders Talk has three ways to use that record. You can keep it for yourself, use it inside a team, or publish a Build for other people to learn from. Public sharing is optional.
For an individual, the immediate value is finding a previous correction without reading the whole conversation again. For a team, a recurring problem can become a proposed rule that teammates review before it reaches their agents. The team workflow keeps the rule connected to the session that explains it.
When you do publish, you choose the exposure: a summary, selected excerpts, or the full session. A lesson can be useful without exposing the entire conversation.
Private here describes who can access the Build. The prepared session is still uploaded and processed on the server. The plugin withholds environment and key-file contents and redacts detected secrets before upload; you should still review anything you intend to make public. The plugin documentation explains what is sent.
The lesson should reach the next session
A record becomes more useful when it changes what you do next.
A Build can have a Playbook: an approach, pitfalls, and checks drawn from that session. On the page, you can inspect the moments behind the advice. Through Use this Build, you can reuse it as a prompt, a skill, or a repository rule for CLAUDE.md or AGENTS.md. Here is how Playbooks work.
For BUTTERFLY JOB, the Playbook carries forward the need to check whether a first-time player can find the first action. It links that advice back to the intervention that prompted it.
The advice has a source you can inspect, including the moment where automated checks proved insufficient.
Your agent can also search published Builds through the Coders Talk MCP server, looking for similar tasks and recorded failures before starting, or when it gets stuck.
That gives the next session a more specific starting point. Instead of a vague instruction to “test thoroughly,” you can ask for the check a previous session missed. You still have to decide whether it fits your project.
Keep one correction
The easiest place to start is a session where you had to explain something twice.
Find the correction that finally helped. Keep the context around it. Write down what you would put in the first prompt next time.
You can do that in a Markdown file today. I built Coders Talk to make it easier to preserve the session behind that note, find it again, and carry its lesson into another run.
If you want to try it, turn one session into a private Build. You can decide later whether it is worth sharing.
What is one correction you keep giving your coding agent that you wish you had saved the first time?
Top comments (0)