14 posts
Eighth lesson in a series on running an AI-powered software team of one. Put the runner on a timer and hear from it only when you are needed: an event reaches your phone when something you do changes what happens next, quiet hours hold t…
Seventh lesson in a series on running an AI-powered software team of one. Looking away is safe when four steps hold without you: the work happens in a disposable copy, a second session grades the diff against the spec, the pipeline runs…
Sixth lesson in a series on running an AI-powered software team of one. A to-do list is for a person to browse; an agent needs a queue it can drain: one file where every item carries a status, an acceptance line, its dependencies, and th…
Fifth lesson in a series on running an AI-powered software team of one. A permission prompt per task trains you to say yes without reading, and an agent with no written limits guesses. One standing file per role answers the question once…
Fourth lesson in a series on running an AI-powered software team of one. A session pointed at one repository commits there and nowhere else, so a project that lives in one folder cannot be delegated safely. Split it into one home per sta…
Third lesson in a series on running an AI-powered software team of one. A rule you write in a README gets broken by the first session that never reads it. A folder of one-script checks, run by git before every push, turns your most-repea…
Second lesson in a series on running an AI-powered software team of one. A fresh agent session cannot see what you rejected, so it proposes it again. One page per settled choice, an index, and one standing line make every session read yo…
The full path to an agent platform that edits its own instructions is already published, scattered across seven articles that never mention each other. I run that architecture as one person: supervisor and worker tiers, verification guar…
First lesson in a series on running an AI-powered software team of one. Before you ask an agent to build, give your project a home for intent: a small directory of numbered specs grown from one template your agent fills in and you approv…
SpecSelf looks like a set of features: coherence checks, persona rotation, review cadences, an audit trail. Every one of them was implied by ten frontmatter fields decided on day one. A life-OS is not a feature list. It is a schema decis…
I built a method as a public repo and the product that runs it as two private ones, and none of them treated the others as a source of truth. The domain enum lived in four places. A persona drifted between its lens file and its API contr…
Dumping the whole corpus into an AI agent makes it worse, not better. The fix is architectural: each task loads a curated slice, not everything you have. Here is the method, and the same move at three different layers: specs, sensor data…
Spec-driven development reads like a methodology for controlling AI agents. It isn't. It's a methodology for managing context across stateless sessions. The spec is the persistent memory.
Why spec-driven development and structured folder architecture are the missing infrastructure for AI-assisted engineering: methodology, common mistakes, and where to start.