What it cost, and why scope never stopped

At about 18:55 I went to make pancakes with my daughter. When I came back an hour later, the second run had moved on without me, and the bill had grown with it. This last part is about the two things that kept growing all day, the scope and the bill.

Park ideas: requirements multiply

This is the most important habit in the whole process. When building is this fast, every answer brings another idea. One feature became three before any code was written, and two more appeared while I answered the Dispatcher's first questions.

So I park them. Each idea goes into a backlog with where it came from and when to come back to it. By the end of the day the list held seven features:

None of them went into this release. Parked ideas are not rejected. Each one is written down with a note on when to come back to it, so nobody has to fight for it today, and the release stays the size it was planned to be.

Where I did not park

I did not park everything, and I should be honest about how much got through.

• Run 2, a product decision. After the first run I added tables, downloadable files and a skill that publishes articles from my writing tool to the site through an API, so there is no manual upload step. I decided that knowing the cost, with the budget in view.
• Run 3, a "small fix". While reviewing, I noticed that a contact request sent from an article did not say which article. The Dispatcher proposed a small fix, and I agreed.
• Run 4, my own test results. The five requests from my acceptance test in Part 4 did not go to the backlog. They went straight into the next package, together with the two defects.
• Run 5, a series format. I decided that long material should be published as a series of parts. A series needs navigation between its parts, so that decision created one more feature for the Dispatcher.

Each of these was a reasonable call on its own. Together they turned "done" into a series of rounds. What separates a product decision from scope creep, for me, is whether someone decided it knowing the cost, and whether anyone keeps count of the rounds.

Watch out: scope that never stops growing. With AI, adding a feature feels free, so the release never closes. Every new idea competes with finishing the current one, and every review brings one more "small fix". Keep a backlog that the agents and the team can see, make "not in this release" a normal answer, and count the rounds as well as the features.

Was it cheaper?

From twenty years in software delivery, this is how I would staff these three features in a normal team: a business analyst at 0.3 of their time, two developers and a QA engineer at half time, for about three weeks. That is my estimate, not a measurement, but I have planned and costed work like this many times.

Here it took one day: about 11 hours from the first voice note to the last deploy, about 2.5 to 3 hours of my own time, about 38 hours of AI agent time, and tokens worth roughly 270 to 330 USD at pay-per-token prices. Price the team with your own day rates and the difference is obvious.

What the comparison leaves out matters just as much. My time on this feature was short, but it was senior time spent on decisions and reviews. The agents did the rest, on my subscription and on my laptop. And the team estimate includes things this run did not need yet, such as handovers between people and waiting for each other. On a larger product the gap would be smaller: more people to align, more history in the code, more integrations and approvals that agents do not speed up. I would still expect it to be large.

The numbers

All the numbers in the series come from this table. The first three rows cover the first run; everything else covers the whole day, 14:00 to 01:00.

I worked on a flat-rate subscription, so there is no per-token invoice for this day. At pay-per-token prices, the same tokens would have cost roughly 270 to 330 USD. After the first two runs the estimate was 170 to 210 USD; the last four runs, mostly reviews and fixes, added about half again.

The subscription has limits too. Late in the second run the five-hour limit stood at 86%. My current plan costs 100 USD a month, and at this pace it is not enough even for a simple feature. The next plan costs 200 USD.

Watch out: token spend that keeps running. The cost of a feature does not stop at the first deploy. Every review, fix and follow-up round reads the whole context again, so the spend grows with each round as well as with the size of the feature. On a subscription it shows up as capacity you no longer have; on an API bill it is a line item someone has to own. Pick a subscription plan that covers the work, watch the usage limits at each stage, and move up a plan before the limits slow the team down.

The cost nobody mentions

Tokens and CI are only part of the bill. The agents run on my own computer. Late in the evening, while sub-agents were testing the series feature, my laptop sat at 96% CPU: headless browsers running end-to-end tests, Node running builds and tests, and the Claude app itself holding almost 4 GB of memory. That was not a one-off. Over the day the agents ran 319 heavy local jobs (builds, unit tests, end-to-end tests, package checks), about three and a half hours of them, heaviest in the afternoon and again late at night. The laptop was mine on paper. In practice the agents had it, and anything else I tried to do on it was slow.

CI, for comparison, cost me nothing that day. GitHub counted 1.91 USD of usage, all of it within the free allowance of my plan.

Watch out: the machine is part of the budget. Parallel agents bring their builds, browsers and test suites to wherever they run. If that is a laptop you also work on, you pay in your own time. Move heavy test runs to CI or a separate machine, limit how many agents run tests at once, and plan agent-heavy work for hours when you do not need the computer.

My time and the agents' time

The rest of my day went to other work, in parallel with the build. This is what changed most for me as a delivery manager. A day of building took under three hours of my time. What still depends on people is attention, and that is what I would plan for.

What I take from one day

The code was the fast part. Every risk I met sat around it: in requirements, decisions, integration, review and the steps only a person can take. The controls will be familiar to anyone who has run delivery. What changes is how quickly you need them.

If I ran your team

I would not budget tokens per feature. I would buy every developer a subscription plan whose limits cover a month of daily agent work, because running the same work at pay-per-token API prices costs several times more. Then I would watch the usage limits, not the invoice: if the team keeps hitting them, I would move to the next plan before anyone starts rationing agents. I would also agree up front where the heavy test runs happen, so the agents do not take over the laptops the team works on.

The two risks behind all of this, and the controls for them, are on the map page. If you are bringing AI agents into your own delivery team, ask the assistant on this site about any part of it, or write to me to talk it through.