haft

Keep AI-assisted engineering from turning into chat history

Coding agents can produce plans, code, and convincing explanations very quickly. The expensive failure is doing the wrong work quickly—or opening the repository a month later and being unable to answer what was decided, why it was decided, where it is implemented, and whether the evidence still holds.

Haft is a local project-memory and reasoning layer for the coding agent you already use. It helps the agent slow down on expensive questions, preserve the results that later work will depend on, and reconnect those results to the code as the project changes.

What Haft changes

  • Better questions before more code. Haft helps distinguish a symptom from the problem, expose alternatives, and make the weakest link visible.
  • Project memory with different kinds of records. A suggestion, a human decision, a plan, performed work, and evidence do not collapse into one transcript.
  • Context that survives a session. Important decisions, specifications, evidence, and code links remain inspectable after the chat is gone.
  • Signals when reality moves. Haft can surface stale evidence, changed code, missing links, and specification drift without pretending those signals are verdicts.

The shortest path to value

  1. Install Haft into a small real project and restart your coding agent.
  2. Choose one question whose answer would be painful to lose or expensive to get wrong.
  3. Ask the agent normally. Add /h-reason when the problem, scope, trade-offs, or architecture are unclear.
  4. Keep the result in conversation if it is local and reversible. Let Haft record it only when another session, person, audit, or costly decision will rely on it.

You do not need to learn FPF, the Haft CLI, or the MCP tool catalog before trying this. The normal interface is still a conversation with your agent.

When Haft is worth the cost

Haft starts paying for itself when one or more of these are true:

  • the project will outlive the current chat;
  • several people or agents need the same rationale;
  • an architectural or product choice is expensive to reverse;
  • you need to know which evidence supported a claim and whether it is still fresh;
  • the link between specifications, decisions, and code matters.

For a throwaway script, a mechanical rename, or an obvious fix with a good test, a coding agent and the test may be enough. Haft should add less ceremony than the mistake it helps prevent.

The trade-offs

  • Typed does not mean true. Haft can catch category mistakes and missing links; it cannot guarantee that the problem framing or evidence is good.
  • Useful links require maintenance. Decision-to-code and spec-to-code links cost attention, and coarse links can create noise.
  • Ceremony is easy to overdo. Not every task deserves a saved problem, comparison, decision, and verification record.
  • The human still owns value choices. Haft can expose options and consequences. It does not know your budget, politics, taste, or acceptable risk.

Where FPF fits

Haft is built on the First Principles Framework (FPF) by Anatoly Levenchuk. FPF gives agents rigorous distinctions and reusable patterns for working with systems. It is large and formal. Haft is the practical handle: it retrieves the relevant, versioned source for the current question and brings the resulting discipline into project memory and code work.

Haft does not make an agent magically correct. It makes important assumptions, choices, boundaries, and evidence easier to inspect and less likely to disappear into fluent prose.

Current release: v9.0.2. Read what changed in v9, or continue with the first useful task.

Older documentation