Everyone's using AI to skip the SDLC... I used it to rebuild the SDLC.
Two months ago I was doing 20 major tickets a month. Now it's 20 a day and the work got harder, not smaller.
Most teams building software today are using extraordinary new tools to run a fundamentally old process. I did that too…and more recently than I’d like to admit.
Even two months ago, my setup still leaned heavily on a human in the loop at every seam. Each agent would do its part and then stop, waiting for me to make a decision before handing to the next. I was the orchestration layer. Which meant I was also the bottleneck, the whole system ran at the speed of my attention span.
Part of that was the models. They genuinely were not yet capable of the long-form thinking and orchestration required to carry work across multiple steps without a human stitching it together. So the human-in-the-loop was not a choice; it was a requirement. The pieces existed but the connective reasoning did not.
That changed. The models got capable enough to do the orchestration and the sustained reasoning themselves and the moment they did, the human-in-the-loop stopped being a safeguard and started being the constraint. I had to rebuild the process around that, and when I did, something shifted that I did not expect. Work that took weeks started taking days.
I want to lay out how it actually works, because the shift is more useful than any headline number and because almost everyone I talk to is still running the old process with new tools or bypassing what made it good alltogether.
The constraint that no longer exists
Agile; standups, sprints, grooming, handoffs and QA gates was a brilliant solution to a real problem: coordinating humans is expensive. When multiple people build one thing, you have to synchronise them, and synchronising them costs time and creates ceremony. Most of what a modern development process contains is not building. It is the overhead of keeping humans aligned.
Agents change the price of that coordination. Not by a little. Fundamentally!
When the thing doing the work does not need a standup, does not lose context overnight, and can run in parallel with other agents without a meeting and, crucially, can now orchestrate its own handoffs without waiting for me, most of the coordination ceremony becomes not just unnecessary but actively slowing. You are paying a synchronisation tax on work that no longer needs synchronising.
The mistake almost everyone is making
Here is where I want to be sharp, because there is a wrong lesson being drawn from all this.
Having agents at your disposal does not mean you throw out the software development lifecycle. That is exactly what a lot of people are doing right now, pointing a model at a problem, skipping specification, skipping review, skipping structure and shipping confident slop at speed. They have mistaken “the agents can build” for “the discipline no longer matters.” The opposite is true!
The SDLC exists because building software well requires specification, review, testing, and integration regardless of who or what does the work. Those needs did not disappear. What changed is who performs each step and how fast. The opportunity is not to ignore the lifecycle. It is to reimplement it to take the same disciplines that produce good software and rebuild how they are executed using agents and orchestration. Skip the discipline and you get fast garbage. Reinvent how the discipline is delivered and you get something genuinely new.
The people producing slop are not moving fast. They are accumulating a mess they will pay for later, at speed.
The shift, in principle
Here is the framework, stripped to its bones. I will keep it at the level of principle rather than my specific configuration, because the principles are what transfer, your implementation should be your own.
One: the specification is the real artifact. Invert the old order. The spec; clear, structured, living in the repository (or in Google Drive or a package such as Notion or Linear) becomes the thing you author. The build follows from it. This is the highest-leverage change and the hardest, because it demands a discipline of intent most teams have never developed. Vague spec, confident garbage at speed. The quality of your thinking is now the quality of your output, directly and unforgivingly.
Two: build in parallel, not in sequence. The old process was linear because humans are linear. Agents are not. Multiple build agents work separate modules simultaneously, in isolated workstreams, without colliding. The shape of the work stops being a queue and becomes a fan-out. Most of the calendar time in traditional development is waiting for the previous step. Remove the waiting and the calendar collapses. And what happens if you DO happen to create colliding tickets - The machine recognises it during the merge process and simply re-bases or rewrites the code for the PR that is picked up last.
Three: separate building from judging. A build agent produces. A distinct reviewer agent evaluates the merge. A separate auditor checks the result against the specification; against intent, not taste and can open its own fix for the pipeline to gate. The thing checking the work is not the thing that did the work. That separation is what lets you trust output you did not personally write. It is also the SDLC’s review discipline, rebuilt not removed.
Four: the humans move up a level. When coordination and much of the execution is handled, people stop chasing status and start doing the two things that need judgment: deciding what to build, and specifying it precisely enough to be built correctly. Not fewer humans doing the same work faster…humans doing different, higher work.
What actually happened to the throughput
Let me put real numbers on it, because the progression matters more than any single figure.
Two months ago, I was doing roughly 20 major tickets a month with me in the loop at every handoff.
As I rebuilt the process, tested it, learned to trust the review layers, and refined the skills and orchestration, that same volume, around 20 major tickets, started fitting into a week.
Now it is north of 20 a day! And that’s largely limited by my machines compute power and my token use rather than a capability constraint.
I want to be honest about what that number is and is not, because the obvious rebuttal is “you just made the tickets smaller.” I did not. If anything the work has gotten more complex, not less. The tickets today are harder than the ones I was doing monthly two months ago. The throughput gain is real and it is not an artifact of shrinking the unit of work. It came from removing myself as the orchestration bottleneck, letting agents carry work across steps, and rebuilding the lifecycle around parallel execution and automated review rather than sequential human gates.
That progression…month, to week, to day is also the honest shape of it. It was not a switch I flipped. It was two months of building trust in the system, refining the approach, and updating how the agents work. The speed is the output of the discipline, not a shortcut around it.
The catch nobody mentions
This is not free, and I distrust anyone who sells it as effortless.
It demands a level of specification discipline most teams have never built. If your intent is fuzzy, agents produce fuzzy output faster than a human could, with more confidence, which is worse. The skill that used to be optional, thinking precisely and writing intent down unambiguously, is now the core skill. The bottleneck moved from typing to thinking. That is a win only if you are good at the thinking.
It also demands a new kind of trust in your own review layers, built and tested carefully rather than assumed. And there remains a category of genuinely novel, deeply contextual work where agents assist rather than lead. Knowing which is which is itself a skill.
Why I am sharing this
I could keep this to myself. Build velocity is an advantage and there is a case for hoarding it.
I have decided it is not the advantage worth protecting. This methodology is being independently discovered across the industry right now. I refined a recipe, I did not invent the ingredients. Within a year it will be table stakes. The durable advantages are elsewhere: in what you choose to build, how well you understand the customer, and the trust and data underneath the product. None of that lives in a workflow, and none of it leaves the room when I write this down.
If you are building right now, the most valuable question is not “which AI tools should I adopt?” It is “which parts of my process only exist because coordinating humans used to be expensive?”
Answer that honestly, and a great deal of what fills your week turns out to be optional, as long as you have the discipline not to mistake speed for a licence to skip the work that made software good in the first place.
In closing, this is what my recipe looks like today:
Idea > Research > Prototype (vibe-coded) > Requirements > Spec (Linear) > Skills (Intake [Avoid duplication and refine scope] >Design > Review > Develop > Review > Test > Audit > Commit/Push to Git) > PR > Review > Deploy > Close (Linear) > Report > Human in the Loop UAT.
Rinse and repeat.