agentic-engineeringproduct-managementprddecisions-logsprintsdefinition-of-doneopen-sourceai-agentssw-3claude-codecodexcursorgeminidevin

Speed Was Never the Hard Part

Agents write code at machine speed. What keeps it from becoming fast chaos is product management — now the load-bearing layer of an AI-built project.

Admin•Invalid Date

Speed Was Never the Hard Part

{/* HERO (publish lane): attach media/s3e1-pm/s3e1-pm-hero-v2.png as the post hero —
frontmatter already points at the v2 blob URL. v2 (2026-07-29, ARIA redesign
after founder rejected the v1 dark dashboard): the memory handoff — the worker
offers the project's worn journal to a fresh agent that just raced in to
re-build yesterday. House cartoon register (cast-locked, text-free scene +
Fraunces/Space Mono). Rendered 3200×1800 in real Chromium via
media/s3e1-pm/build-hero-v2.mjs. */}

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 stops being overhead and starts holding everything up.

[Part 1](/blog/project-scaffolding-101) gave the aerial view of our open scaffold — the folder shape we start every agent-built project from. [Part 2](/blog/agentic-team-every-cli) walked through the named crew inside it and how it travels between coding tools. This post is about the layer underneath both: the discipline that keeps the 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. Refusing to call any of it done until it's been shown to be done.

That discipline is product management. On a human team it's the layer nobody thanks. On an agent team it's the steering wheel.

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/` — 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.

Here's the folder's load-bearing shape, straight from the public repo (the full listing adds a README, an index, and reference docs):

```
project-management/ # the project's memory — read first, every cold session
├── 0k_PRD.md # the what & the why — settled before any code
├── 0l_DECISIONS.md # append-only — no silent re-arguing
├── 01_ARCHITECTURE.md # technical truth (Part 1 covers this)
├── 03_MODULE_CONTRACTS.md # reuse-first (Part 1 covers this too)
└── sprints/
└── sprint_01/
├── index.md # one goal · bounded scope · definition of done
├── todo/ # the task cards
├── reviews/ # the checks
├── reports/ # what actually happened
└── acceptance/ # the evidence — a human signs the last line
```

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. A call made once doesn't get 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 the definition of done; the task cards live beside it in `todo/`. 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. Beside the tasks sit `reviews/`, where the work gets checked, `reports/`, for what actually happened, and `acceptance/`, where the human owner signs off.

"Done" means proven — the rule that ties the other three together, and 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.

{/* VISUAL BRIEF (design lane): the interactive is BUILT and gate-passed locally —
at ~680px width, AUTO gate 17/17 on 2026-07-29). "Open the project's memory": four
pillar buttons — PRD · Decisions · Sprints · Acceptance — light their nodes in the
real project-management/ tree from the public scaffold repo and narrate what a cold
agent reads there; the Sprints pillar also lights the loop
open → scope → build → review → acceptance → close. Deploy per
media/s3e1-pm/README.md (visual-packs path, or the proven iframe-to-blob route from
Part 2); the fenced tree above is the static fallback. */}

If the embed doesn't show in your reader: the interactive is a guided tour of the same folder — the fenced tree above is the static version, and the real thing is one clone away at [github.com/SynaptixLabs/scaffold](https://github.com/SynaptixLabs/scaffold).

Now let's do it for real

Nodding along to a discipline is easy. 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, stated once: 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 article stops 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.

---

Previously in The Lab. Part 1 — [Your Repo Is the Prompt Now](/blog/project-scaffolding-101) — the whole scaffold from the air: the structure, the three-agent team, and the project's memory. Part 2 — [Bring the Team, Not the Prompt](/blog/agentic-team-every-cli) — the same named crew, carried across every CLI.

Up next. Part 3B — the worked example: the memory game, built with exactly this process, end to end in the open. It lands when the game ships — no invented sprints in the meantime.

---

Part 3 of 3 — Part A. Grounded in the public [github.com/SynaptixLabs/scaffold](https://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.