When a team ships code fast, context accumulates faster than any single person can track. Not code — context. The decisions that were made and why. The patterns that became conventions. The gotchas that burned the team once and got documented nowhere.
Coding agents make this worse. They write code at the speed of a prompt, but they inherit none of the context a human engineer builds up over months in a codebase. They do not know that a certain guard must always run before tenant resolution. They do not know that a particular method was retired two sprints ago. They do not know that the billing module has a subtle invariant around how invoice previews work.
They can read the code. They cannot read the history.
The gap is context, not capability
The obvious answer is better prompts. Paste the relevant files. Write a more detailed system prompt. Describe the architecture. But these are patches, not solutions. They require someone to already know what context is relevant — and that is exactly what is missing when things go wrong.
The less obvious answer is repo context that lives with the codebase. Not in a wiki that gets stale the day after it is written. Not in a one-time AI documentation sweep. In a layer that stays current because it is rooted in how the team actually changes code — commit by commit, PR by PR.
What we are building
Driftless maintains living repo memory. When a PR changes how a module works, Driftless updates the context for that area. When a decision gets made in code review, Driftless captures it. When a pattern gets established across files, Driftless anchors it.
The goal is simple: before a human or agent touches a file, they should have the context they need. Not a summary of the file — the context behind it. The rules, the gotchas, the decisions, the owners, the risks.
Context that is as current as the last merged PR.