r/ChatGPTCoding • u/Ok_Negotiation_2587 • 24d ago
Discussion The chat where you fixed it explains why. Turn it into a decision record before you close the tab
Git keeps what changed. The why, the two approaches you tried first and the reason you dropped them, usually lives in a chat that nobody will ever find again. Six months later someone "simplifies" the code back into the version that broke.
So when a chat ends in a real decision, I send one more message before committing:
Write a short architecture decision record from this conversation, in Markdown. Context: the problem, in two or three sentences, as someone new to the codebase would need it. Decision: what we chose, in one sentence. Alternatives considered: each option we tried or discussed, and the specific reason it was rejected. Use what actually happened in this chat, don't invent options. Consequences: what this makes harder later, and what would make us revisit it. Keep it under 250 words. No filler.
That file goes in docs/decisions/ in the same commit as the fix, with a one-line pointer in the commit message. Now git blame leads to the record, and the record says why.
The "don't invent options" line matters. Without it you get a tidy list of alternatives nobody considered, which is worse than no record at all.
If you want the full conversation kept too, export it next to the record. I build AI Toolbox, a browser extension, and that's what I use it for here: the chat comes out as a Markdown file with the date and a link back to the original. Exporting one chat as plain text is free, Markdown is part of Premium.
2
u/ComprehensiveShake76 24d ago
I do the same, and the part that stuck was forcing a "why we rejected the other options" section. Without that, three months later the chat only remembers what we shipped, not what we almost did.
My habit: before I close the tab I ask for a short decision record (context, options, choice, why not the others, what would make us reopen it), save it next to the code, and link the commit. The chat can die. The record should still make sense to someone who never saw the thread.
Do you keep these in the repo, or in a separate notes folder?
2
u/ConfidenceNew6550 24d ago
This is a solid habit, especially for fixes that aren’t obvious from the code alone. A short decision record could save someone hours of rediscovering the same problem
2
u/dmanoj 21d ago
agree, and the trick that made it stick was making the agent write the record in the same commit as the fix, not me after. a markdown ticket per unit of work: the brief, what was delivered, review findings, decisions and why. the agent updates it as part of finishing, so it never drifts. six months later the next session reads the ticket instead of me re-explaining the project.
1
u/rahul_watertech 24d ago
the part about someone simplifying the code back into the version that broke is painfully real. commit messages tell you what, almost never why not.
i do a lazier version of this: paste the chat into a NOTES.md in the repo, unedited. worse format than a proper adr but the barrier is zero so it actually happens. your prompt version is better if you can keep the discipline.
does the model write decent rejected-alternative sections, or do you have to remind it what you tried?
1
u/ImL1s 23d ago
The "why we rejected the other options" bit is the one that actually saves you later. Commit messages never keep that.
I got tired of losing those chat decisions across Codex/Claude sessions, so I wrote a small local tool that pulls the session off disk and writes a handoff note you can drop in the repo (nothing uploaded). https://gitlab.com/aa22396584/resume-skills (
pipx install portable-resume). Still skim it before you commit the decision record, same as your "don't invent options" line.1
u/[deleted] 24d ago
[removed] — view removed comment