Manifesto of Agentic Dev

Who this is for — anyone deciding how much rope to give a coding agent in their own repository.

Read this if — you want the five commitments the rest of the book unpacks.
Skip this if — you want them as a checklist; that is the Rule Index.

Takeaways

1. Verification comes before creation, always — the rest is detail.
2. Context that is not a file in the repository silently expires.
3. You can delegate execution; you cannot delegate accountability.

We believe in a future where software is co-created by humans and AI agents. That future has two endings. In one, codebases degenerate into unmaintainable spaghetti that no human fully understands and no agent can safely change. In the other, every repository carries its own rules, its own checks, and its own memory — so that any collaborator, carbon or silicon, can pick it up cold and improve it.

We are building for the second ending. These are the principles that keep us on that path:

1. Always Verify First

“Don’t automate the creation before you automate the verification.”

• Never ask or allow an agent to write feature code unless there is a concrete, automated way to verify its correctness.
• Write the validation harness, the canary, or the test suite before writing the feature.
• Let the agent fail fast, iterate, and succeed against strict automated constraints.

Why it matters: unverified agent output is not productivity — it is deferred review debt, compounding at machine speed.

🤖 Agent takes the wheel — writing the harness itself. Test tables, fixture files, and golden corpora are mechanical work with an unambiguous definition of done.

🛡️ The check that makes it safe — make preflight, run before the turn ends. If the harness the agent wrote cannot fail, it is not a harness; see The Golden Path for what that looks like when it goes wrong.

2. Local-First, File-Based Workflows

• The codebase is the sole source of truth for both humans and agents.
• Specifications, ADRs, issues, context glossaries, and agent instructions live as plain files (AGENTS.md, CLAUDE.md, CONTEXT.md, docs/, issues/) inside the repository.
• Avoid proprietary cloud dashboards, hidden prompt injection layers, and complex agent databases. If it is not in the repository, it does not exist.

Why it matters: context that lives in files survives every session reset, every model upgrade, and every vendor change. Context that lives anywhere else silently expires.

3. Human in the Loop, Human in Control

• AI models get smarter and more capable every month. Opaque, heavy agent frameworks and babysitting harnesses age poorly.
• Keep the harness lightweight and transparent.
• The human acts as the architect, making strategic decisions and manually triggering skills or commands. The agent executes targets. The human stays in control.

Why it matters: you can delegate execution, but you cannot delegate accountability. The person who answers for the software must be able to see and steer what builds it.

🧑‍✈️ Human holds the wheel — choosing which steps run at all. Triggering a skill, accepting a plan, and deciding that a green build is nevertheless wrong are not automatable, because they are where responsibility actually lives.

4. Canary-First Verifications

• When a feature relies on an external CLI tool, hardware resource, OS-level socket behavior, or container layout, build a canary first.
• A canary is a minimal, standalone verification script that lives outside the main validation suite and validates the external mechanism in the real environment.
• Run it, observe, document the findings, and keep it in the repository.

Why it matters: assumptions about the environment are the most expensive kind of wrong. A canary converts a weekend of debugging into a thirty-second check.

5. Keep it Minimal and Radical

• Avoid generic, bloated design patterns. Write simple, clean, readable code.
• Prefer strict, self-contained tools (e.g. Go, Zig, static binaries) over massive, resident daemon architectures.
• Limit language usage to the House Rules subset to keep context windows clean and logic bulletproof.
• One component, one language. A second implementation of the same logic is not a backup — it is a divergence waiting to happen.

Why it matters: every line you don’t write is a line no agent can misunderstand, no context window must carry, and no future session must re-learn.

The sharpest version of this principle is a deletion. In Week 4 of the Emojig Chronology, the most consequential commit of the week removed 2,450 lines — the duplicate Go clone mojigo that shadowed the Zig picker and made every search-scoring tweak a two-language edit. Nothing was lost except the divergence risk.

🤖 Agent takes the wheel — carrying out the deletion and re-pointing every build, script, and doc reference at the surviving implementation. Tedious, wide, entirely mechanical.

🛡️ The check that makes it safe — the surviving implementation’s own test suite plus a release build across every target. A deletion is safe exactly when the thing that remains is still provably correct.