Preface & History

Who this is for — developers who want to build more software than they can personally remember.

Read this if — you want the argument and the story behind it.
Skip this if — you have five minutes; take the Rule Index, then The Golden Path.

Takeaways

1. Building was never the bottleneck; maintenance is where fleets sink.
2. Automate verification before you automate creation — everything else follows.
3. Correctness lives in the repository’s checks, not in the developer’s memory.

Last updated: 2026-08-02.

An Unreasonable Idea

This book is built on an idea that sounds unreasonable: a single developer can build — and, harder still, maintain — a whole fleet of focused, high-quality apps. Not prototypes that rot after the demo. Real tools: an emoji picker with a hand-tuned TUI engine, a terminal graphics renderer with golden-file test suites, a documentation engine that prints its own books to PDF. Each one small, each one finished, each one still alive a year later.

The catch is that building was never the bottleneck. Maintenance is where fleets sink. Every app you ship adds a standing cost: dependencies drift, terminals change behavior, toolchains update, and your memory of why the code works fades. Multiply that by ten apps and the classic answer is: you can’t. Pick one project, archive the rest.

Agentic development changes that math — but only if you set it up right. This book is the record of how, and the rules that made it hold.

Two Principles

Everything else in this book unfolds from two sentences:

• Engineering Principle: Spec just enough, code for quality, verify and fail fast, iterate, succeed.
• Agentic Principle: Don’t automate the creation before you automate the verification.

The second one is the load-bearing wall. An agent that can write code you cannot cheaply check is not leverage — it is unpaid review work arriving at machine speed. But once every app in the fleet carries its own verification harness — a make preflight, a canary script, a golden corpus — then any agent (and any future you) can safely touch any app, on any day, without re-loading a year of context first. That is the whole trick. The fleet stays maintainable because correctness is checked by the repo, not remembered by the developer.

The Journey

2022 — First Contact

My journey with agentic development started in late 2022, playing in the OpenAI Playground with code-davinci in private beta. The completions were erratic, the context tiny — and I was hooked from day one, because even then the shape of the future was visible: the machine could write; it just couldn’t know when it was wrong.

The Hand-Holding Era

In the early days, I tuned my own tools from the start. Back then, agents needed constant supervision to get anything right. Every session was babysitting: watch the diff, catch the hallucinated API, re-explain the project. The lesson that stuck was not “agents are weak” — it was that I was spending my time on checks a script could run. I learned to build the guardrails, not just the prompts.

2025 — Trust, but Verify

The turning point: I stopped reviewing every step and started verifying every result. Automate the checks first, then let the agent run. A failed check costs nothing; an unverified merge costs a weekend. This inversion — verification before creation — is when one developer maintaining many apps stopped being a slogan and started being a Tuesday.

2027+ — Wide Open

Super curious where this leads. The models change every month, the harnesses change every week — and I want a front-row seat, with my repos ready for whatever shows up next.

Stance & Vision

The Problem: Harnesses are getting too big and too opaque. They eat developer time and hide what the agent is actually doing.

The Answer: Frontier models + a few generic helpers + many manually triggered skills and commands. The human triggers the steps; the human stays in control.

Models get better every month. Piling on complex harness code and endless context docs will age badly and do more harm than good. When a project goes spaghetti, a frontier model cleans it right back up — as long as the harness stays out of the way.

How to Read This Book

The chapters follow the same arc the fleet did:

1. The Manifesto states the rules; the Glossary pins the words down.
2. The Golden Path runs one real feature through every rule in this book — including the part where the agent is wrong and the harness is not yet watching. If you only believe demonstrations, start there.
3. Canary-First Development shows how we verify the environment before trusting it, and Agentic Dev Patterns collects the day-to-day workflow habits.
4. TUI Restoration and the Golden-Change Playbook are deep dives: what disciplined verification looks like when the problem gets genuinely hard.
5. The Solo Fleet, Reviewed closes the book by turning the lens around: where this CLI-first, local-first approach genuinely wins, where it would break inside a team or a product organization — and what those organizations should steal from it anyway. The Colophon then says how the book itself was made, and what the agents got wrong while making it.
6. The appendix, House Rules, holds the language subsets for Go, Zig, Bash, and Make. It is reference material — grep it, don’t read it.

Read it linearly for the story, or jump straight to the playbooks when something is on fire. Two pages are built for the reader in a hurry: the Rule Index is the whole book as one checklist, and every chapter opens with who it is for, what it assumes, and three takeaways.

Three signs recur throughout, and they carry the argument:

Every 🤖 in this book is followed by a 🛡️. That pairing is not a formatting habit; it is the thesis.

The argument here is proved one shelf over: the Emojig Chronology is six weeks of the same practices with the commit counts, the deletions, and the millisecond measurements attached.