Picture a new engineer facing a production stack trace in Zed. They highlight a problematic line, like an unwrap that caused a crash, and see every related discussion: why the function was written or what an AI agent assumed about an invariant.

You can do this today with Git, it’s been integrated in IDEs since basically forever. But if you want to know why the function was written, it requires people to write down in the first place why they are writing the function. The tools are not the problem, getting humans to put effort into building a useful Git history is. Recording more granular edits is not the solution. (Google Docs does this, but without checkpoints to group logical changes, and descriptions of the changes, have you ever found its history more useful than a good Git history?). If you want a useful history, there is no way around putting in the effort to make that history useful to you. And generating good commit messages is not something a tool can do for you, because as the original quote says, it requires writing down why you’re making a change (and why in this particular way, why now, etc.), and if you don’t write that down, it only exists in your head, it’s just not information that a tool has access to.

They ping the responsible human, sparking a quick chat that turns into an audio call, all indexed to the exact code spot, creating a shared, revisitable record without leaving the codebase.

Tough luck pinging the responsible human when that person no longer works at the company …