Back
ESEN

2026

Product OS

My own harness on top of Claude Code for agentic development based on Spec-Driven Development, without losing control of the code.

The problem

A project’s state lives in the chat, and the chat loses it. Every new session starts without knowing what was decided or where the last one stopped.

And the agent that writes the code also decides when it is done. Nobody looks at its work with other eyes.

How it works

  • Spec-Driven Development at the core. Every requirement starts with a spec that defines what gets built and how it is tested, before any code is written.
  • A workflow that adapts to the requirement. It runs linearly or in parallel depending on the context, with review at every stage.
  • Context lives in core repo files. Decisions are documented, progress lives in PROGRESS.md, the agents’ operating context in AGENTS.md, and design and architecture rules in DESIGN.md and ARCHITECTURE.md. Every session starts by reading instead of rebuilding from memory.
  • Guardrails and MCPs. A security and quality floor that no type of project lowers, and MCPs like Context7 so agents work with up-to-date docs for each technology.
  • Scripts for deterministic work. Tasks that need no reasoning run in scripts, so the LLM is used where it adds value and token usage goes down.
  • The right model for the difficulty. Each task goes to the model that fits its complexity.
01

Log

newest first

  1. Reuse before writing

    Every change is checked against what the repo already has, so code is not duplicated.

  2. Closing and starting as commands

    The close writes down where the session stopped and the start reads it, instead of rebuilding it from memory.

    Read the note

  3. A reviewer who did not write the code

    The phases of this site were approved by a reviewer other than whoever built them, and the exceptions were written down.

  4. What else a change touches

    When a fix touches sensitive code, what else it may have affected gets checked before it is closed.

  5. State in the repo

    State lives in repo files, not in the conversation, so no session depends on the last one.