Why we are building a context engine for AI coding

The code often leaves a reason unanswered.

A repository can show that a timeout is set to a particular value. It may not explain which downstream service forced that choice, whether the restriction was temporary, or what would need to change before increasing it. A coding assistant can inspect the implementation and still need the reasoning that produced it.

Engineers carry that reasoning through discussions, incidents, review comments, documents, and previous tasks. Before a new change, somebody often assembles it again. The work is useful: it establishes what the change must respect. The repeated reconstruction is the part we want to reduce.

Follow one decision into the next change.

Consider a fictional orders API. An earlier design says that retrying with the same request ID must return the original order. An incident adds a qualification: the server can accept a request even when the client never receives the response. A later task asks for automatic retries.

The task is not fully described by “add a retry loop.” The earlier reasoning changes the implementation boundary, the conflict questions, and the tests. It tells the engineer to distinguish a lost response from a failed creation. That is the sort of understanding a context engine should make easier to recover.

Earlier choice: preserve one accepted creation per request ID.
Known exception: acceptance can succeed before a response is lost.
New task: add retries.
Implication: recover the existing result; do not assume timeout means failure.
Still unknown: how to handle the same ID with a different body.

What has to survive.

Keeping a sentence is not enough if its scope disappears. “Use this temporarily” and “use this” can lead to different decisions. A proposal and an accepted choice can have identical technical content while carrying different authority. An assistant report that a check remains pending must not become a verified outcome.

We want context that preserves the decision, why it was made, when and where it applies, the relevant exceptions, and the evidence behind it. We also need to distinguish those source-supported facts from an interpretation produced by a model. These are design goals to prove through actual behavior, not a claim that every captured work item already preserves everything.

The current task remains authoritative. A recovered decision can be stale or deliberately superseded. The engineer needs enough provenance and uncertainty to challenge it rather than follow it automatically.

Useful retrieval ends in a better-informed action.

A saved history has potential value. A relevant result has more immediate value. But the result becomes useful only when somebody can inspect it, decide whether it applies, and use it in the work.

For preparation, that may mean a plan preserves a production constraint. During review, it may mean the reviewer asks about a known failure mode. For testing, it may mean a regression case checks the actual incident instead of merely exercising the new branch. The same foundation can also support reflection on an approach after the work is done.

This is why we evaluate more than whether a search returned a record. Did the needed constraint reach the caller? Was it understood with the right qualification? What did it change? A high retrieval score cannot answer those questions by itself.

Where this fits beside existing tools.

Project instructions, native memory, code search, tests, and review tools already solve useful parts of this problem. When the background is small, stable, and local to the repository, those mechanisms may be enough. A separate context engine needs to earn its place when work understanding is scattered, changes over time, or must move between tasks.

Shifu is built around selected work from supported sources and retrieval into the next task. It does not make every historical statement correct, replace technical judgment, or establish that a change is safe. The product has to show relevant evidence and useful limits, then fit the workflow engineers already use.

Before trying any context product, choose one real change. List the earlier decision or exception it depends on, where you would find that today, and what the next task would get wrong without it. That small example is a better test of the idea than asking whether a tool “has memory.”