We stopped debating task order, and let the agent map the dependencies instead

the order nobody agreed on

Every team has a version of this moment. The design is approved, the architecture decisions are written down, and now someone has to turn that into a list of tickets a developer can actually pick up on a Monday morning. Which piece unblocks which other piece. What can run in parallel. What quietly depends on something three tasks away that nobody flagged.

That used to live in a spreadsheet, or a whiteboard from standup, redrawn every few days as reality caught up with the plan. Most of the ordering was fine, worked out from memory and experience. Some of it wasn’t, and you didn’t find out until a developer picked up a task, got two hours in, and hit a wall because the piece it depended on hadn’t been built yet. Reordering at that point isn’t free. Someone’s already lost the morning.

We wrote about our agentic SDLC a little while ago: six staged phases, each with its own gate, though several of them run inside the same command, AI agents doing the volume work while our team makes every call that matters. Our PM wrote the first close-up, on Discover (our /feature command), and one of our senior developers followed with Design, our /tech-design command. This is the third, one phase over: Plan, from the seat of the person who owns that gate.

I’ll be specific, because “AI plans your sprint” undersells it and also gets it wrong. The design phase hands over a validated architecture. Plan is where that architecture becomes an ordered, dependency-checked list of tasks, before a single line of code exists, and before anyone has to hold the sequencing in their head.

what actually changed: from remembering the order to confirming it

The old workflow put the sequencing wherever the most experienced person’s memory happened to be. You’d look at a feature, mentally simulate the build, and try to catch every place task four secretly needed something from task seven. Some of that catches. Some of it doesn’t surface until someone’s actually building.

The new workflow starts the same way every phase in this pipeline starts: from what the previous phase actually produced. Plan is the first thing that happens inside our /implement command. One subagent reads the validated design and follows our own plan-implementation skill. It doesn’t ask what order feels right. It works out what order is forced by the dependencies actually written into the design: which files a task touches, what has to exist before something else can be tested, which pieces are genuinely independent and can run side by side.

It doesn’t just list the tasks. It orders them, and the order is where the real thinking happens.

you don’t need the sequencing in your head before you start

This is the part I didn’t expect going in. You don’t walk into Plan already knowing the build order. You need the validated design from the phase before it. That’s the whole prerequisite.

The subagent writes an implementation/plan.md file: every task gets an id, a title, the acceptance scenario it satisfies, which layer of the system it touches, the files involved, what it depends on, and what “done” actually means for that task. Alongside it, it builds a coverage map: every feature we surfaced back in Discover, matched against the tickets that actually implement it. Nothing discovered at the start gets to quietly disappear by the time we’re building.

Before either is handed back to us, we get the task list as a numbered summary, and we’re asked to confirm it or adjust it. Only after that does it create a live entry for every task, so progress is visible from the first day of the build, and write the initial state file that the build phase picks up from.

inside the session: the dependency you forgot you had

Here’s what the session actually surfaces, because “it plans the tasks” could mean almost anything.

What it’s good at isn’t guessing at priority. It’s good at surfacing the dependency you didn’t remember you had. On the feature we ran this on, one of the tasks was a straightforward-looking permission check on an existing endpoint. Nothing about it looked like it needed to wait for anything. The plan put it fourth anyway, because two earlier tasks quietly introduced the field that check needed to read. Left to instinct, I’d have scheduled that task whenever it felt convenient, probably in parallel with the other endpoint work, and found out it was blocked only once someone actually sat down to build it.

“What it’s actually good at is surfacing the dependency I forgot I had. I’ll read a task list and think it’s fine, then it flags that step four quietly assumes step two shipped something first.”

That’s the value in one sentence. Not that it out-thinks a tech lead about the feature, it doesn’t, I still decide what counts as one task versus three, and where the real risk in the build actually sits. It’s that the order stops depending on whoever happens to be holding the whole picture in their head that week.

the moment it earns its keep

We ran this on the same P&L engine already familiar from Discover and Design, on the people management module, continuing straight from the validated design that phase produced. One session, about 15 to 20 minutes of our own review, and a plan with 29 tasks, each one placed by an actual dependency rather than a guess.

We’ve only taken one feature through Plan so far, so this is a single data point, not an average, and I’d rather say that plainly than dress up one session as a trend. But the shape of it already tells you something worth noting: the review at this gate is already lighter than either of the two phases before it. Discover and Design both involve real back-and-forth, a spec being interviewed into shape, an architecture being argued over one trade-off at a time. Plan is closer to reading a proposal and checking it against what you already know to be true. That’s not nothing, it’s still the point where a wrong call gets expensive to fix later, but it’s a different kind of attention than the phases upstream of it ask for.

what you walk away with: a plan that survives contact with the build

The output isn’t a spreadsheet that’s already stale by the time the sprint starts. Two artifacts come out of Plan, and both are things the build phase depends on being accurate, not paperwork for its own sake.

An ordered task list, implementation/plan.md. Every task carries its id, the acceptance scenario it satisfies, its layer, the files it touches, what it depends on, and its done-criteria. The order isn’t a suggestion, it’s the actual build sequence, because the dependencies are the ones the design really has, not the ones somebody remembered on the day.

A coverage map. Every feature that came out of Discover, matched to the tickets that implement it. If something we discovered at the very start quietly has no ticket by the time we’re planning the build, that’s visible here, not three months later when someone asks why it never shipped.

Before either is treated as final, we see the task list as a numbered summary and confirm it or send it back. Only then do live task entries get created, one per task, and the initial progress file gets written, every task marked pending, tied to this phase, with the branch and base commit it starts from recorded alongside it.

the gate didn’t move, the thinking did

People ask, reasonably, whether the agent is deciding the plan now. It isn’t. I still confirm the task list, or send it back if something’s wrong. That part hasn’t moved.

What changed is where the effort goes. It used to go into remembering: every file a change touches, every earlier task a later one secretly needs, writing all of that down before it slipped out of someone’s head. Now it goes into judgment: is this genuinely one task or should it be three, is the risk this plan assumes the risk I actually think we’re carrying. That’s the part of planning that was always the real job. The rest was overhead that happened to require experience to get right, without being what the experience was actually for.

doing this as a tech lead

I want to be direct about what this asks of me, because it isn’t what I expected. It doesn’t ask me to type out a task list faster. It asks me to look at an already-ordered plan and decide whether the granularity is right, whether a task that looks small is hiding a task-and-a-half of risk, and to say so before the build starts rather than midway through it. That’s a narrower question than “did I think of everything,” and a much easier one to get right, because the dependencies in front of me are the ones the design actually has, not the ones I’m trying to hold in memory.

The gate reflects that. We confirm or adjust the task list ourselves, before a single line is written. The agent proposes the breakdown. I still decide what’s one task versus three, and that judgment call didn’t move to the tool, it just got faster to make.

why this matters beyond one phase

Plan is the third of six phases, and it’s the hinge between deciding what to build and actually building it. A design with every trade-off written down is only as useful as the sequence built on top of it, and a task list nobody checked against its own dependencies is a sprint that stalls out somewhere around Wednesday. Every task this phase orders correctly, and every dependency it catches before the build starts, is something the build phase and the reviewer after it don’t have to discover the hard way.

Which is really the same lesson the two phases before this one already taught, from a different angle: the bottleneck was never writing the list. It was getting the order right, at the point where getting it wrong was still cheap to fix.

what’s next

This is the third in a series looking at each phase of our agentic SDLC in turn, each written from the seat of the person who owns that gate. Three more to go: Build, Review, and Ship.

If you’re a tech lead who’s watched a sprint stall out on a dependency nobody flagged, or a leader wondering what “human in the loop” looks like at the planning table rather than on a slide, we’d be glad to talk.