Series · 5 parts
AI SDLC: cheaper code & new risks to manage
A delivery manager's diary of shipping one feature the new way. The map of the series.
Building software has become faster and cheaper. The process around it has become easier too: an AI agent can interview you about the idea, keep the documentation for you and ask for each decision at the right moment. The accountability stays with you.
I am a former developer and a lifelong learner. I wanted to learn something new, so I built my own website, the one you are reading this on. This is not the first feature I have built this way, so I had some practice before this run. I am writing it down so that less technical delivery managers can see how the process feels without going through the learning curve themselves.
For this series I took one feature from a voice note to production on my own site, with AI agents doing most of the building. The series is the diary of that day, mistakes included. It has five parts, and each one can be read on its own.
The day in one film
A six-minute film shows the whole day, from the first voice note at 14:00 to the last deploy after midnight. Every slide of the film is also attached at the end of this page as a PDF, if you prefer to read at your own pace.
I wrote it for delivery, program and project managers. If you are accountable for AI-supported delivery, you need to understand how an AI SDLC works. You do not need to write the code. You need to know where the risks sit now.
SDLC stands for software development life cycle: everything between an idea and software that runs, from requirements and design through building and testing to release and maintenance. In an AI SDLC, AI agents do much of that work. People still decide what gets built and stay accountable for the result.
Was it cheaper?
The feature in this series is really three: an articles section on the site, an admin panel to publish articles, and the site's AI assistant learning from them. From twenty years in software delivery, I would plan that scope for a small team: a business analyst at 0.3 of their time, two developers and a QA engineer at half time, for about three weeks.
Here it took one day. About 11 hours from the first voice note to the last deploy, of which about 2.5 to 3 hours were mine. The AI agents ran for about 38 hours in total, many of them in parallel, and the tokens would have cost roughly 270 to 330 USD at pay-per-token prices. You can price the team with your own rates. The gap is large either way. Part 5 explains what this comparison leaves out.
The series in one minute
Part 1: Requirements start as a voice note. I dictate the idea, then an agent interviews me one decision at a time. One feature becomes three. The agent trusts a stale document and asks the wrong question.
Part 2: The agent that does not wait for me. The Dispatcher decides, builds and asks in parallel, and I answer from the side. It learns how I decide, ships first by design, and my review catches an extra link behind a flag.
Part 3: How the agents build. Specifications and tests first, a fresh sub-agent per task, one owner of integration, clear limits on what the agent may do, then CI, auto-merge and deployment with live checks.
Part 4: Where the human still decides. My own acceptance test finds what the green gates could not, including a mistake in the agent's test plan. A credential picks up invisible characters in a step I approved.
Part 5: What it cost, and why scope never stopped. Ideas parked and ideas not parked, six runs in one day, the bill in tokens and limits, and a laptop at 96% CPU.
The numbers in short
- First run (14:00 to 18:09): three features in production in under three hours, all fixes live after about four.
- Whole day (14:00 to 01:00): 11 pull requests, 10 releases, no rollback.
- Whole day: about 720 million tokens across all sessions, roughly 270 to 330 USD at pay-per-token prices, paid as a flat-rate subscription.
- Whole day: six runs of the Dispatcher, about 38 hours of AI agent time, 2.5 to 3 hours of mine.
Every number in the series comes from one table in Part 5, with its scope next to it.
What delivery managers should take away
The code was the fast part. The risks sat around it, and in the end they come down to two. Some are old risks that now arrive much faster. Others are new, such as an agent that decides before it asks.
Risk 1: deciding what to build is faster than anyone can check it. Requirements now arrive as talk, scope grows inside a single answer, and the agent decides before it asks.
| Where it showed up | Control | Part |
|---|---|---|
| Unsigned requirements | Keep the original voice notes and answers; get the requirements signed off | 1 |
| The wrong weight of documentation | Size the documents to what you build; cut what nobody reads | 1 |
| Agents trust stale documents | Keep agent instructions as current as the code; ask for evidence if in doubt | 1 |
| Scope decided in a click | Log every question and answer; a new requirement is a change | 1 |
| Decisions nobody made | Define what the agent may decide alone; keep the decision log and verify it | 2 |
| Every demo grows the wish list | Separate defects from wishes; decide on each wish before anyone builds it | 4 |
| Scope that never stops growing | A visible backlog; "not in this release" is a normal answer; count the rounds | 5 |
Risk 2: building and running it without seeing the full cost. Agents build in parallel, ship before review and use your token budget and your machine while they do it.
| Where it showed up | Control | Part |
|---|---|---|
| Review after release, by design | Feature flags, a list of decisions, an implementation review that happens | 2 |
| No definition of done | Specifications and tests first, reviewed by engineering leads | 3 |
| Agents colliding in the same code | One owner of integration for the whole team | 3 |
| Green checks, wrong feature | A scheduled human review of what the business asked for and what was built | 4 |
| The manual step nobody verifies | Script the steps around secrets and settings, verify the result, let the next release check it | 4 |
| Token spend that keeps running | A subscription that covers the work; watch the usage limits at each stage | 5 |
| The machine is part of the budget | Heavy tests in CI or on a separate machine; cap parallel test runs | 5 |
Most of the controls are familiar to anyone who has run delivery. What changed for me is the speed, plus a few costs that did not exist before: each of these now shows up within hours, and the person accountable has to be ready for it.
Downloads
- The day in slides . Every slide of the film, in order: the timeline of the day, the failures, the tests, the risks and the numbers.
Ask the assistant, or ask me
The assistant on this site has learned this series; that was one of the three features. Ask it about any step, risk or number, in plain words, or ask it what a term like SDLC or CI means.
If you are planning to bring AI agents into your delivery team and want to talk through the operating model, the decisions and the controls, write to me.
In this series
- Requirements start as a voice noteBefore any code: how the requirement is captured, and how an agent turns it into decisions.
- The agent that does not wait for meHow the build runs while I keep working: the Dispatcher decides first, asks second, and ships before my review.
- How the agents build: from spec to production without a hand-offWhat happens between "approved" and "live" when agents do the building: method, parallel work, limits on what the agent may do, and automated gates.
- Where the human still decidesGreen checks are not acceptance. A test plan I ran myself, what it found, and the steps an agent should never take alone.
- What it cost, and why scope never stoppedIdeas multiply when building is cheap. How I park them, where I did not, and what one day of agents cost in time, tokens and limits.