My coding agent keeps forgetting decisions and rebuilding the wrong thing

Remembering a sentence is not the same as knowing what governs the app

An agent may have many notes and still encounter contradictory instructions: an old proposal in a chat, a new constraint in a document, a misleading comment, and code that implements a third interpretation. More context can make that conflict larger. Identify the source that governs the disputed behavior and explain whether the other material is historical, provisional, or obsolete. Do not expect the agent to infer authority from which paragraph sounds most confident.

Keep three kinds of working material separate

Use the repository's existing instruction mechanism rather than inventing another elaborate framework. A compact durable note can point to the relevant product decisions and current build evidence. It does not need to repeat every line of the package.

• Product direction: who the app serves, what it promises, and which consequential decisions are confirmed.
• Implementation truth: what currently exists, what has been verified, what is provisional, and the active build sequence.
• Task contract: the next complete outcome, preservation duties, proof required, and rare stop conditions.

Example: proposed guidance must not become official by accident

Suppose a product lets AI suggest a new plan, but only the user can activate it. An agent asked to improve the chat might directly save the suggestion as the current plan because that seems locally convenient. The defect is not solved by saying remember the project. The implementation instruction must identify the actual approval rule and the records or commands that enforce it. Verification then needs to show that creating or rejecting a proposal leaves the active plan unchanged.

Keep decisions changeable, but change them deliberately

A source of truth is not a prohibition on learning. When new evidence changes a product decision, update the governing direction and affected implementation plan explicitly. Record why the change happened and which earlier assumption it replaces. Otherwise the code silently becomes the new specification while the documents keep describing the old product. Intent-Fidelity Development describes this deliberate link between intent, decisions, architecture, and implementation; it can be practiced without Driftbreak.

Read the Intent-Fidelity Development methodology

Make the agent an owner of the outcome, not a messenger for every error

Within the agreed task boundary, the coding agent should trace defects, implement the change, run checks, inspect the UI, and repair ordinary friction. A compile failure should not automatically become another planning meeting. Conversely, autonomy does not authorize it to change customer commitments or discard data. Distinguish routine engineering recovery from a decision the builder genuinely owns. At completion, ask for the visible result, verification evidence, important repairs absorbed, and remaining uncertainty.

What a Driftbreak package adds, and what it cannot promise

The package connects a confirmed product direction with architecture, a technical blueprint, an adaptive implementation campaign, and operating prompts. That gives the coding agent a connected starting point rather than a detached task list. It does not guarantee perfect model behavior or mean that no repository inspection is needed. The agent must bind the direction to the code and tools actually available, and the builder still owns consequential product decisions.

See what the implementation handoff contains