Conversational Drift

Context

A team interacts with AI assistants through chat. Decisions are made, designs are sketched, debugging insights surface — all inside conversations. The artifacts that should have been produced (a doc, a manifest, a structured note, a test, a comment) are not produced, because the conversation felt like the work and the participants left satisfied. The understanding lives only in the chat history, which is ephemeral, unsearchable across the team, invisible to other tools, and frequently lost when the session ends.

Cost type

Primarily cognitive, deferred. The cost of re-establishing context falls on the next person (or the next session, even of the same person) who works on the same code without access to the conversation that produced it.

What goes wrong

• A debugging session reaches a clear conclusion (“the bug was caused by X; the fix is Y; the underlying issue is Z”). None of that is recorded. The fix lands without a comment, the issue tracker has no entry, the next bug in the same area gets re-investigated from scratch.
• A design discussion happens between a developer and an AI assistant. The decision is sound but lives only in the session. A teammate hits the same question a week later and re-derives a worse answer because they don’t have the prior reasoning.
• An LLM session reads through a complex piece of code and explains it well to the human in front of them. The human doesn’t capture the explanation. Three months later the human reads the code again and asks an LLM to re-explain it. The new explanation is fine but slightly different, introducing inconsistencies if any of it is acted on.
• Architectural decisions accumulate as conversational consensus rather than written record. New team members face a codebase whose rationale is impossible to reconstruct.

Prospective indicators

• A productive AI conversation is wrapping up and no artifact has been touched: no comment, no doc, no commit message that captures the insight, no entry in any tracker.
• “I’ll remember this” is the implicit close of the session.
• A teammate joins the conversation and asks a question that was already answered earlier in the chat — but the earlier answer isn’t visible to them.
• The conversation produces a list of action items that exists nowhere outside the session.

Retrospective indicators

• Re-deriving the same explanation, design, or fix multiple times because nobody captured it the first time.
• Onboarding new team members requires senior team members’ time disproportionately because the codebase’s rationale lives in scattered conversations rather than in artifacts.
• Slack/chat searches for old AI conversations as a primary mode of context recovery.
• Disagreement about prior decisions because the parties remember different conversations.

Prevention

• Treat conversation as exploration, not as the work product. The work product is the artifact that survives the session.
• For any non-trivial AI conversation, ask explicitly: what artifact should this produce? A code comment, a doc, a manifest entry, a test, an ADR, an issue. The artifact is the deliverable; the conversation is scaffolding.
• Use tools that capture artifacts as a side effect of the conversation. msw-lens YAML manifests, Beads “beads,” ADRs, even strategically-placed comments. Post-conversational design (see ../post-conversational-design.md) is partly a discipline for forcing this capture.
• For debugging insights specifically: write the comment that would have helped you reach the answer faster. Drop it in the code where the next reader will find it.

When this isn’t a failure mode

• Throwaway code where context loss costs nothing.
• Genuine exploration that does not produce a stable conclusion. Sometimes the conversation correctly concludes “we don’t know yet.” Capturing a non-conclusion as if it were durable would be misleading.
• Solo work on personal-tool projects where the only future maintainer is you-with-LLM and you’ve accepted the Tooling Contingency trade-off.

Note

This failure mode is the direct counterpart of the Tooling Contingency entry. Both are about what happens when AI’s role in the loop creates a category of work that feels productive but produces no durable artifact. Tooling Contingency is about the codebase becoming illegible without the tool; Conversational Drift is about the understanding around the codebase becoming illegible without the conversation that produced it.

The whole point of post-conversational design (see ../post-conversational-design.md) is making it harder to commit this failure mode by giving humans a structured surface that captures intent as a side effect of expressing it.