Put the roadmap on a Continue button

Last month a week-long feature landed in my repo and I was barely in the room for it. I wrote the paragraph that started it. Then I tapped a button a few times over three days — once at dinner, once from my phone, once from bed — and the whole thing showed up as a single pull request against main. The agent did the engineering. I never read a diff. I never touched my keyboard for it after the first sentence.

That is not how handing a big feature to an AI usually goes. So let me show you the actual machine — the blueprint I approve, and the loop that grinds under it. There's a live one further down you can press yourself.

The babysitting tax

Hand a real feature — not a one-line bug fix, an actual feature — to an agent that can write and ship code, and you get one of two deals.

Babysit every diff. You sit there reading code you didn't write, hunting for mistakes you can't predict, approving hunks you half-understand. Congratulations, you're the bottleneck. The agent types faster than you and you slowed it down to your reading speed.

Or let it rip and lose the thread. You look up an hour later with no idea what it actually built, whether it's close, or which of the four things you wanted it quietly skipped. Now you're a spectator to your own product.

I've got a name for the first deal: the babysitting tax. Every hour you spend shoulder-surfing an agent — reading its diffs, catching its mistakes, re-explaining what you meant — is leverage you were promised and didn't get. Neither deal is the reason you reached for an agent in the first place. And both chain you to the chair, because the second you close the laptop the thing either stalls waiting for you or wanders off a cliff. The leverage evaporates the moment you stand up.

I only work at one altitude now

The fix wasn't a smarter model. It was drawing a hard line between two altitudes and only living at one.

The unit of work is an initiative: a big piece of work broken into milestones. The entire trick is what a milestone is.

• Milestone = a user story. "A user can invite a teammate." A product criterion a real person would care about, stated as an outcome — either met or not. This is my altitude. I review the stories, reorder them, rescope them.
• Sub-task = the technical breakdown. When a milestone starts, the agent shreds that story into implementation tickets and works them one at a time. This is its altitude. I never open one. I never name a function. I never see a branch.

Every decision I make is a product judgment. Everything below it is machinery.

That line is the whole design. The moves that need taste stay with me; everything mechanical — including the agent's own mistakes — stays below the line.

The blueprint is the only thing I read end to end

Before any code exists, the loop hands me one artifact: the blueprint. The agent takes my one-paragraph pointer, researches how the thing is normally built, writes the spec I couldn't be bothered to write, and — the part that matters — breaks it into an ordered list of user stories.

Say my pointer is "let a workspace owner invite teammates." The blueprint comes back looking like this:

Initiative — Team invites. Email-based invites, role assigned on accept, seat count reconciled to billing, revocable. Reuse the existing auth + billing seat model; no new provider.

Milestones (user stories):

1. An owner can send an invite to an email address.
2. An invitee can accept the link and land in the workspace with the right role.
3. Adding a teammate updates the seat count on the next invoice.
4. An owner can revoke a pending invite or remove a member.

That's the whole thing I actually read. Four sentences a user would recognise, in the order they'll ship. I comment until it's right — "drop revoke for v1, it's not load-bearing" — and the agent regenerates the list. No code has been written. No branch has been cut. I'm editing outcomes, not architecture, and it costs me a coffee's worth of attention.

Get the blueprint right and you've done 90% of your job for the week. Everything after is yeses.

The agent opens PRs. It never merges.

Here's the fence that makes it safe to walk away. The agent's only forward move is opening a pull request. It can't merge. It can't cut a branch. It can't touch main. Not "is asked nicely not to" — can't.

Everything lives in a two-level tree: main at the root, an initiative-42 branch cut beneath it, one branch per milestone below that. The agent works a milestone on its own branch and, when it thinks it's done, opens one PR into the initiative branch — never into production. That PR is how it raises its hand. It literally cannot do the next thing; it can only say "this one's ready" and wait.

Every branch, every merge, every advance is a deterministic system's move — and only when I say so.

The loop, move by move — press it

There are exactly six moves between a pointer and a shipped feature, and I only make one of them: Continue. Rather than describe it, here's the actual thing. This is the blueprint from above (trimmed to three stories after my comment), wired to a real Continue button. Press it and watch a week of work go by:

Notice what happened while a milestone was running: the button went dead. It's greyed out until the work is actually ready, so I can only ever advance something that's genuinely done — I can't fat-finger the pipeline forward. The six moves, for the record:

1. Blueprint. Agent drafts the spec + user-story list. I comment until it's right. No git yet.
2. Continue → start. The system cuts initiative-42 off main and kicks off milestone 1.
3. Milestone run. The agent works the milestone on its own branch and opens one PR into the initiative branch (never main). A preview build and a QA pass fire automatically.
4. Continue → advance. I review the outcome; the system merges that milestone's PR into the initiative branch and starts the next one.
5. Final PR. After the last milestone, the system opens the final PR: initiative-42 → main — the whole feature in one reviewable diff against production.
6. Continue → ship. One last Continue merges it to main.

And here's what unchains me from the desk: none of this runs on my laptop. Every milestone is a durable background job — the same headless-agent-in-a-sandbox machine every one of my loops runs on. I close the lid, get on a train, the roadmap keeps moving. The babysitting tax goes to zero, because there's nothing running on the thing I'm carrying around.

Every milestone fixes itself before it reaches me

You saw it self-heal in the demo. That's the load-bearing part. Two Continues from now doesn't mean two hopes — between my taps, the loop is grinding to earn them. Each milestone PR runs the real build and real QA, and two capped inner loops handle failure entirely out of my sight:

• Build-fix loop. Build fails → the agent reads the failing build log, fixes the root cause, pushes to the same branch (never a new PR), and the build re-runs. A green build flows straight into QA.
• QA-fix loop. QA drives the app like a user. It fails → the agent fixes the issue and re-runs QA on the same branch. This loop gets its own budget, separate from the build loop.

Each loop is capped at five rounds — an initial attempt plus four fixes. I only hear about it if a loop burns through all five, at which point it stops and pings me instead of flailing forever. So by the time a milestone reaches my review, something already tried five times to break it and failed.

That quietly changes what my review even is. The real bottleneck on AI-written code was never generating it — it's reviewing it, and how fast one person can read the results. My loop attacks that bottleneck, but not by making me read diffs faster. It changes what I read. "Is this code correct" was already answered by a QA agent that exercised the story like a user. The only question left is "does this user story work" — which was always the one that's mine.

The unglamorous specs that make it survive a real repo

Three more specs, because a real repo moves and a demo doesn't:

• Nightly merge-down. A week-long initiative means main shifts underneath it while other things ship. So a nightly job — plus a step at the start of every milestone — merges main back down into the initiative branch and the active milestone branch, so they never drift into one giant end-of-week conflict. Merge only, never rebase: I'm not letting an automated system rewrite history on a branch I'll eventually put into production.
• Blocking human gates. The agent can flag steps only a human can do — add a secret, point a DNS record — and a blocking one pauses the whole pipeline until I check it off. It never bluffs its way past something it can't actually reach.
• A week of after-care. For about a week after the feature ships, the agent revisits the live thing like a picky user and files small improvement tickets — the dead empty state, the button nobody clicks. Shipping isn't where it stops caring.

The roadmap runs itself

Add it up and my job on a whole feature shrank to a paragraph, a blueprint I sharpened over one coffee, and five yeses — none of which needed me at a keyboard, or even at home. The agent owns everything mechanical, including its own mistakes. I own the two things that were ever mine: are these the right stories, and does each one actually work.

This is one of a stack of loops I run this way inside 1mn — the big-feature one, the one I never named out loud. Internally it's the Initiative Loop, and it's the same bet as all the others: fence the agent hard enough that being wrong is cheap, hand every irreversible move to a system that can't be charmed, and keep for yourself only the decision that was ever yours.

Keep the taste, delegate the typing — and let a roadmap that advances on a single button mostly run itself.