If AI writes code, should the session be part of the commit?

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.
• 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.