If AI writes code, should the session be part of the commit?
As AI-assisted coding becomes common, developers are split over whether the full chat session or prompts that produced a code change should be stored alongside Git commits. Supporters argue that preserving sessions (or at least structured summaries) could capture intent, aid debugging, enable audits, and help train both future engineers and models. Critics counter that raw transcripts are mostly noisy, non-deterministic, hard to curate, and risky for privacy, and that well-written specs, commit messages, and design documents remain a more practical way to record “why” a change was made.
Whether AI sessions belong with commits at all
- Strong disagreement. Some see sessions as the new “source” for AI-written code; others say they’re noisy intermediates like keystrokes, Google searches, or compiler output.
- Many argue: if you need the session to understand the change, you’re already failing at code clarity, tests, comments, and commit messages.
- Non‑determinism and model churn undermines “reproducibility” based on prompts alone.
Arguments for capturing sessions / intent
- Sessions encode user intent, constraints, and rejected alternatives that often never make it into code or tickets.
- Useful for:
- Debugging “why is it like this?” months later.
- Audits, compliance, and incident/postmortem analysis.
- Teaching juniors and evaluating “prompt competence.”
- Future AI agents that can mine past sessions for context or hotspots.
- Some see broad session archiving as valuable training data for future/open models.
Arguments against storing raw logs
- Sessions are long, messy, and full of dead ends, hallucinations, and side conversations.
- High noise‑to‑signal ratio; reviewers don’t want to sift through “vibe coding” transcripts.
- Risk of leaking PII/secrets if chats contain user data or sensitive context.
- Feels like surveillance or micro‑management of developer thought processes.
- In many workflows, there is no single coherent “session” per commit; work spans many branches and tools.
What to store instead (and where)
- Common middle ground: capture summaries and intent, not full logs:
- Rich commit messages, PR descriptions, ADRs, design docs,
plan.md/project.md/ specs. - Possibly store a session ID or external link, not the transcript itself.
- Rich commit messages, PR descriptions, ADRs, design docs,
- Git notes are popular for attaching transcripts or summaries without polluting history, but rebases, squash merges, and lack of forge support are concerns.
- Some prefer private or separate repos/databases for sessions; others want everything near the code for longevity and portability.
Emerging practices and tools
- Several tools (e.g., git‑memento, Entire, Spec Kit, various “plan/spec/devlog” systems) attach AI context, plans, or run logs to commits or PRs.
- Many advocate spec‑ or plan‑driven development: iterate on Markdown specs/plans/tests, then generate code; check in the spec rather than the chat.
- “Change intent records,” ADRs, and concise post‑task reflections are proposed as the durable artifact.
Broader cultural concerns
- Thread surfaces anxiety about “vibe coding” flooding codebases and HN with low‑effort AI‑generated projects.
- Some want explicit disclosure of AI use in commit messages or Show HN titles; others worry about training their own replacement by formalizing AGENTS/CLAUDE docs.
- No consensus: the only clear agreement is that documenting why changes exist is increasingly important; whether that’s via raw sessions, summaries, or better commit discipline remains unresolved.