Speed Was Never the Hard Part

An agent can write a week of code in an afternoon. So the scarce thing stops being typing and becomes the unglamorous rest: knowing what to build, agreeing it's right, and proving it's done. That work has a name — product management — and on an agent-run project it quietly becomes the thing holding everything up.

Two posts in, here's where we are. Part 1 gave the aerial view of our open scaffold — the folder shape we start every agent-built project from. Part 2 walked through the named crew inside it, and how it travels between coding tools. This post is about the layer underneath both: the part that keeps that speed from becoming a fast, expensive mess.

The problem hiding inside the good news

Agents write code quickly. That's the pitch, and it's real. It's also the whole problem.

Speed with nothing steering it isn't progress. It's chaos that arrives sooner. Point an agent at a goal it has slightly misread, and it won't misread it in one place — it'll thread that misunderstanding through forty files, and commit all forty, before anyone looks up.

So what catches that? Not a cleverer agent; you don't control the model. The thing that catches it is the same thing that made human software teams trustworthy long before any of this: the discipline around the typing. Deciding what to build. Writing the decision down. Reviewing what comes back. And refusing to call any of it done until it's been shown to be done.

That discipline has a name — product management — and on a human team it's the layer nobody thanks. On an agent team it's the steering wheel. It goes from overhead to load-bearing.

The same discipline, minus the memory

There's a catch that makes it harder here than on a human team.

A person remembers yesterday. They carry the reason behind last week's decision in their head and bring it to today's work without being asked. A fresh agent session brings none of that. It starts cold, every time.

So the discipline can't live in anyone's head — there's no head for it to live in. It has to live in the repo, in plain files the agent reads before it does anything. In the scaffold that's a single folder: project-management/. Think of it as the project's memory, written down where a cold agent will actually find it. In the template these arrive as blank forms; a real project fills them in.

Four pieces carry the weight.

The PRD — 0k_PRD.md — is the "what" and the "why." The problem, who it's for, what counts as success, and the scope you're explicitly not touching: settled and on the page before a line of code exists. It's there so an agent doesn't get to quietly invent its own answer to "what are we building."

The decisions log — 0l_DECISIONS.md — is the "why" over time. Every real choice, dated, with its reasoning and whether it's reversible. It's append-only: you add to it, you never quietly rewrite it. That's the point — a call made once doesn't get silently re-argued by the next agent, who was never in the room.

Sprints — sprints/sprint_01/, then sprint_02, and on — are where the work happens, in bounded chunks. Each sprint's index.md fixes one goal, spells out what's in scope and what isn't, and states its definition of done; the task cards live beside it in a todo/ folder. The boundary is the point: an agent will happily grow a small job into a sprawling one, so the sprint is the fence around it. Alongside the tasks sit a reviews/ folder where the work gets checked, a reports/ folder for what actually happened, and an acceptance/ folder where the human owner signs off.

"Done" means proven — the rule that ties the other three together. This is the one most people skip. Done is not an agent announcing it's done. Done is evidence: the acceptance criteria are met, anything a person can see has been shown working in a real browser, nothing else broke, and a human signed the last line. No gate closes on a claim. If it wasn't shown, it isn't done.

That's the whole machine. A place for the what, a place for the why, a place for the work, and a bar for done that can't be talked past.

Now let's do it for real

Nodding along to a discipline is easy. Trusting it is another thing, and you don't earn that from a diagram.

So we're going to build a small, complete product using exactly this process — and show every step: the PRD, the first sprint, the agents doing the work, the review, and the gate that decides ship or no-ship.

The plan is a memory game. Small enough to read in one sitting. Real enough to have a screen, tests, and a bar for done you can check with your own eyes. You'll see where the discipline earns its keep — and, honestly, where it feels like pure overhead right up until the moment it saves the whole thing.

One straight answer: the game doesn't exist yet. We're not going to invent its sprints or imagine its results to fill a page. When it's built, the full walkthrough lands here as Part B — the real PRD, the real commits, the real gate. Until then, this is the setup, and we've stopped it exactly where the honest part ends.

The typing was never the hard part. The judgment around it is. That's the job that doesn't go away — so we wrote it down where a cold agent can't miss it, and next, we run the whole loop in the open.

---

Part 3 of 3 — Part A. Grounded in the public github.com/SynaptixLabs/scaffold repo (v1.0, MIT): the real project-management/ folder shape. The worked example (Part B — the memory game) is pending the game build — deliberately not written here. Draft for founder review — not published.