Out now on Leanpub
A coworker needs an environment, not a better prompt.
Principles for running an AI coworker in a one-person studio, with the receipt behind each one. Twenty-five chapters drawn from a working system that ships software.
Published in progress. Buyers get every revision as the system it describes is corrected.
The plateau is not a prompting problem.
Your first week with an AI coding assistant is genuinely impressive. A few weeks later the assistant is no better or worse than it was, and that is precisely the problem. You are still explaining the project from scratch every morning. You are still correcting the habits you corrected last Tuesday. Every one of those failures has a prompt-shaped non-solution, and none of them work.
The plateau does not live in the exchange. It lives in everything between exchanges: between sessions, between documents, between a claim and the state of the world. This book is about the working environment that closes that gap.
Durable memory that gets curated rather than hoarded.
A knowledge store the assistant reads before it asks you anything.
Conventions enforced by machinery instead of repetition.
Gates where its claims get checked against reality before anything ships.
What it covers
Twenty-five chapters in six parts.
-
Part I
Why an operating model
The ad-hoc trap, what an AI operating system is and is not, and where the evidence in this book comes from.
-
Part II
Foundations
Canonical truth against derived views, memory that compounds rather than bloats, the knowledge store, and repository topology.
-
Part III
The primitives
Packaged judgment, mechanical enforcement, specialist agents and project leads, concurrency across parallel sessions, and why one integration got shelved.
-
Part IV
Discipline
Session shape, drift detection and reconciliation, verification honesty, the gate and review chain, estimation, and the token meter.
-
Part V
Receipts
Shipping an app to the Mac App Store, the publish that was reverted the same day, the local model that lied, and building a ledger of what went wrong.
-
Part VI
Build your own
Day one and the minimum viable operating model, growing conventions into enforcement, and what to take from a system built for one person.
One of the principles
Verify delivery, not intent. A mechanism you asked for is not a mechanism that ran.
An override that never applied. A report you were told had been sent, that never arrived. A test suite that ran green because it was never registered. None of those announce themselves, and each was caught the same way: by checking the first instance rather than trusting the class.
Every principle in the book is written like that, with the incident behind it named rather than implied. Where something failed, the chapter says what failed, when, and what the measurement was.
Who it is for
Solo developers and small teams adopting an AI coding assistant seriously enough to be frustrated by it. It uses Claude Code as the running example, but the layers are named generically, so the model applies to whatever tool you run.
What it is not
It is not a prompt library, and it is not a survey of the tooling landscape. It is one working system, described honestly, including the parts that were adopted and then unwound.
Get the book
Published in progress on Leanpub, so it is revised as the system it describes is corrected. Buyers get every revision.