The New SDLC: Plan → Delegate → Verify → Ship

The New SDLC: Plan → Delegate → Verify → Ship A few weeks into rebuilding CIS as a multi-agent system, I noticed something odd about my own workflow. I hadn't opened a sprint board in days. I wasn't writing tickets. I wasn't doing standups with myself. But I was still, somehow, following a process — I just couldn't name it yet. Then I actually wrote down what I'd been doing, in order, for every feature I'd shipped that week. Plan. Delegate. Verify. Ship. Every single time, in that order, without ever deciding to adopt it as a methodology. It had just... become how the work happened once agents entered the loop. This post is about that loop — not as a trendy framework I'm pitching you, but as the honest shape my SDLC has quietly reorganized itself into, and why I think most of the "agentic development" advice online skips the part that actually matters. --- What the Old SDLC Assumed That No Longer Holds Every SDLC model I learned in college — waterfall, agile, whatever variant — quietly assumed one thing: the person writing the code and the person making decisions about the code were the same person, moving at the same speed. Requirements gathering was slow. Design was slow. Implementation was the bottleneck, so most process existed to manage that bottleneck — sprints, story points, code review queues, all built around the assumption that writing code takes the most time. That assumption is just gone now. When I hand a scoped task to Claude Code, implementation isn't the bottleneck anymore — my decision-making is. The agent can produce a working first draft of a feature faster than I can finish reading its plan. Which means all the process I inherited — process designed to manage slow implementation — is optimizing for the wrong constraint entirely. I felt this most clearly building NIGHTSHIFT. My old instinct was to break the job-application agent into a two-week sprint: design the scraping logic, then the form-filling logic, then the resume customization, one after another, testing at the end of each. By the time I finished the "sprint," the agent had built things faster than my sprint plan could account for — and the plan itself became the slowest part of the process. That's when I stopped forcing agentic work into a human-paced process and let the actual bottleneck — my judgment — define the loop instead. --- The Loop: Plan → Delegate → Verify → Ship Here's what actually happens now, broken into its real components instead of the ceremony I used to wrap around it. Plan. Before any agent touches a keyboard, I write down what "done" means for this specific piece of work — not a vague ticket, but a real spec. For CIS, this meant defining exactly what evidence the GitHub agent was allowed to pull, what format its output had to match, and what counted as a passing result before the orchestrator would even accept it. This step used to feel like overhead standing between me and "real work." Now I know it is the real work — everything after this is execution of a decision I already made. Delegate. I hand the scoped task to the right agent for the job — sometimes Claude Code for something that needs deep codebase context, sometimes a narrow subagent for something isolated and repetitive. The key discipline here isn't picking the fanciest tool. It's making sure the task I hand off is actually scoped tightly enough that the agent can't wander into decisions that were supposed to be mine. A vague delegation produces vague, hard-to-review output — that's on me, not the agent. Verify. This is where most of my actual engineering time goes now, and it's the step that separates this loop from vibe coding wearing a process diagram. I read the diff like it's a PR from someone I don't fully trust yet — because it is. I run the test suite. I ask myself if I can explain why this works, not just whether it runs. When I caught an agent silently swallowing an exception in a retry loop last month — technically working code that would've failed silently for weeks in production — it was this step, not a smarter prompt, that caught it. Ship. Only after verification actually passes does anything go out. And "ship" here isn't just deploy — it's also deciding what feedback loops back into the next Plan step. Every bug I catch after shipping becomes a constraint I write into the spec next time, which is the only reason this loop gets better instead of repeating the same mistakes on a faster clock. --- Old SDLC vs. This Loop | Traditional SDLC | Plan → Delegate → Verify → Ship | |---|---| | Optimized around slow implementation | Optimized around fast implementation, slower judgment | | Process exists to coordinate people | Process exists to constrain and check agents | | Code review happens because someone might disagree | Code review happens because you can't assume agent output is trustworthy by default | | Sprints sized around estimated coding time | Cycles sized around how fast you can verify, not how fast something gets built | | Planning is a phase | Planning is the highest-leverage phase, full stop | The biggest shift isn't in any single step — it's that Verify has become the load-bearing wall of the whole process. In the old model, review was a nice-to-have gate. In this loop, if you skip it, you don't get a slightly worse outcome — you get a system you don't understand shipping to production, which is exactly how vibe coding disasters happen at scale. --- Here's What Nobody Tells You About This Loop I want to be honest about the part that doesn't show up in agentic-coding hype posts: this loop is not faster in the way people expect it to be. Yes, the Delegate step is dramatically faster than writing everything by hand. But Plan takes longer than most people budget for, because writing a spec precise enough for an agent to execute well is a genuinely different skill than writing a Jira ticket for a human — humans fill in unstated context with judgment; agents fill it in with whatever's statistically plausible, which is not the same thing. And Verify takes longer than people expect too, because reviewing generated code with real scrutiny is slower than skimming a familiar teammate's PR where you already trust their instincts. The net result is real speedup — I'm not disputing that agentic tools make me faster. But the speedup shows up unevenly across the loop, and if you don't budget time for Plan and Verify accordingly, you end up with the worst version of this: fast Delegate, rushed everything else, and a system that looks done but isn't. --- The Rule of Thumb I Actually Use If I ever catch myself spending more time in Delegate than in Plan plus Verify combined, something's wrong — either I under-specified the task, or I'm not actually reviewing the output with real scrutiny. The ratio of time you spend planning and verifying versus delegating is the actual measure of whether you're doing agentic engineering or just vibe coding with a process diagram taped on top. I check this on myself more often than I'd like to admit. Late in a build session, when I'm tired and the agent's output looks plausible, the temptation to skip Verify and go straight to Ship is real. The loop only works if I resist that on the days it's least convenient, not just the days it's easy. --- I'm still tuning this loop project by project — RITE POS needs a heavier Plan phase than a quick internal tool ever would, because the stakes of getting inventory logic wrong are just higher. I don't think there's one universal SDLC for the agentic era yet, and I'm suspicious of anyone claiming they've found it. But naming this loop explicitly has already made me faster in the place that actually matters: catching problems before they ship, not after. This is Day 3 of the series. Next up: the piece of advice I hear constantly in agentic-coding circles that I think is actively dangerous — "just trust the agent" — and why the whole discipline of this loop exists specifically to reject that idea.