The business always wanted a date

Nearly every company I have worked with over the last fifteen years ran agile and committed in waterfall.

The ceremonies were real. Standups, sprints, grooming, a velocity chart somebody maintained. And underneath them, the actual commitment was a list of features against a date: this month, this quarter, by the user conference. Nobody said "we are doing waterfall with standups," but if you followed the money and the promises, that is what was being managed. Pick whichever mangled term you like for it.

I do not think that was dishonesty or incompetence. A business has to commit to dates because the rest of the business runs on them: contracts, hiring, launches, revenue recognition. Agile never offered an alternative to that. It offered a better way to find out you were wrong earlier, which is not the same thing.

Story points were the translation layer between the two. Engineering sized complexity, velocity converted complexity into a rate, and the rate produced a date that a sponsor could plan around. It was a rough translation and everyone knew it, but it held together because effort and complexity moved together for a human team.

Coding agents broke that correlation, and with it the translation layer.

What breaks, precisely

Typing is no longer the scarce thing, so sizing by effort stopped predicting duration. Work I would have called two weeks lands before lunch. Work I would have called an afternoon takes three days, because the agent surfaced four things that were already wrong and each one needed a decision from me.

Here is the part I find hardest to say out loud, because it sounds like an admission of incompetence: once I have written good requirements and clear exit criteria and set a fleet of agents going, I genuinely do not know how long it will take. Not roughly. The work heads off and comes back, and the elapsed time depends on how many rounds of correction it needs, how long the adversarial review cycles, what the review bots find, and how fast I turn around the decisions it gets blocked on. I have watched a well-specified piece of work land in an hour, and I have watched its sibling spin for two days in review.

So an estimate for a single item is now close to worthless. That is a real loss, and pretending otherwise is how teams end up defending a velocity chart nobody believes.

What replaces it is something the business wanted anyway

The thing is, aggregate throughput did not get less predictable. Only per-item duration did.

Two changes make that usable.

Cap the size instead of estimating it. Stop asking how big a piece of work is and start enforcing how big it is allowed to be. My own rule is that a story has to be provable by one round of gates, and that there is a soft ceiling on how much non-test code it should produce before it gets split. The ceiling is not really a scope control. It is a reviewability control, which matters for reasons I will come back to.

Then forecast by counting rather than by adding up estimates. Count how many of those bounded items actually finished per week over the last couple of months. That gives you a history. Sample from that history at random, a few thousand times, to ask "if the next eight weeks look like some mix of the weeks I have already had, when does a batch of this size finish?" You get a spread of answers rather than one date, and you report the point where, say, 85 percent of those runs finished.

That technique is not new and is not mine. It predates agents by years and it was always a better forecast than summing estimates, because it uses what happened instead of what someone hoped. What agents changed is that it is no longer the sophisticated option. It is the only one left standing, because the estimate it replaced no longer correlates with anything.

And this is closer to what the business was asking for the whole time. It wanted a date it could plan around and a sense of how firm the date was. For twenty years we handed it a point total and a velocity and let it infer the firmness, which it did badly, usually by assuming the number was a promise. Now the uncertainty is in the output instead of hidden inside it: a date, with a confidence level, that moves when reality moves.

It also hands the sponsor a lever they actually control. Most of a piece of work's elapsed life is not spent being built, it is spent waiting on a decision. When you measure that share and report it, "your answer time is in my critical path, and here is how much of the calendar it is eating" becomes a conversation about something the business can fix this week. That conversation was never available from a velocity chart.

The cost, which is not where people are looking

This is the part I think is being skipped past.

The old arrangement was not only a delivery system. It was a training system, and the structure of the work was what did the teaching.

Senior people designed and broke the work down. Mid-level people took feature work and got better at it by doing it. Early-career people supported the team and found places to fit in, and in finding those places they learned how the thing was built. Nobody designed that ladder on purpose. It fell out of the fact that work had to be divided into pieces that matched the people available.

Add global delivery and it got more complex, with its own price. Work definition and deliverables shifted between time zones through the day, which bought you hours and cost you overlap. Thin handoff windows, and days lost to each region's holidays and office hours. Everybody who ran that model knows the arithmetic.

Agentic development changes the shape of that work, and the part it changes most is the middle. The feature work mid-level engineers used to grow on is the work agents are best at. The support tasks where early-career people used to find a foothold often collapse into a single prompt. What remains is knowing what needs to be built, dividing it so it can be built without collisions, and recognizing when what came back is subtly wrong.

That is a change in what the work is. It is not an argument for fewer people. The parts that remain are precisely the parts an agent does not carry: the tacit knowledge of how a system got this way, the context of what the business is actually trying to accomplish, the memory of the decision that looked clever two years ago and is now the reason a migration is hard. An agent has none of that, and it is not its job to. So the capacity that used to go into feature work does not evaporate. It has to be pointed somewhere, and working out where is the live problem for anyone running a team right now.

The way out, as best I can tell, is to teach that judgment on purpose: observed, shown and corrected in live work, the way anything tacit passes between people. It used to accumulate as a side effect of doing the junior work, and the junior work is what agents absorbed, so waiting for people to season is not an answer any more. Skip the teaching and in ten years the people reviewing agent output will be the ones who never saw a system fail at scale. That is a different problem from adopting the tools, and it is getting almost none of the same attention.

It is worth saying where that leaves someone starting out, because a warning on its own is no use to them. The work that is growing is the work of keeping generated code in check, and it is growing precisely because the volume is outrunning anyone's ability to read it: specifying closely enough that an agent can execute without you in the room, cutting the work so several agents do not collide in the same files, building the gates and harnesses that decide whether output can be trusted, and being the person who can look at a plausible change in an unfamiliar layer and say why it is wrong. None of that is junior work in the old sense and all of it is engineering. If I were advising someone finishing a computer science degree this year, I would tell them to get good at verification and system design early, because that is where the scarcity and the leverage both sit.

I am not going to pretend I know how a profession replaces its own training pipeline. But I am fairly sure of the smaller claim, which is that an organization measuring only output will not see this happening. Two people driving agents produce similar volume and similar diff sizes in their first month. The difference between someone who has seen a system go wrong at scale and someone who has not shows up later, in rework, in escaped defects, and in the architectural dead ends nobody catches until they are expensive. If your measurement window is shorter than that lag, your data will tell you experience does not matter.

The companion to this note, Team size has a ceiling, and agents lowered it, takes the other half of the same question: not what the work becomes, but how many people a piece of it can hold before adding another one slows it down. Between them they frame the thing I want to write about next, which is the step from prompting an agent to running several of them with intent. That step is where the judgment above stops being a nice quality in a senior engineer and starts being the constraint on what a team can deliver.

Two practical notes, since this is a field note

Push the gates to where they are cheap. If adversarial review and the review bots only run once a change reaches a pull request, the cycle gets long and you pay for it twice: in calendar time while it spins, and in build minutes. Most of what those reviews catch can be caught before the change leaves the machine it was written on. Running the same checks locally first turned my pull requests from a place where problems are discovered into a place where they are confirmed.

The size cap is about review, not scope. The reason to split a piece of work is not tidiness. It is that a diff you cannot actually read is a diff you are approving on faith, and the honest response to "I cannot keep up with what is being written" is to make each thing smaller and let mechanism cover the rest, rather than to read faster and pretend.

What I am sure of, and what I am not

Sure: effort-based sizing has stopped predicting anything, bounded items plus counting works better than estimates, and per-item duration is genuinely unknowable right now in a way the industry is not admitting.

Not sure: whether the training-pipeline problem is as bad as it looks from where I am standing, or whether something replaces the ladder that I cannot see yet. I am one person running this across a single platform and a handful of repositories, which is a vantage point, not a dataset.

If you are running this with a real team and your forecast is holding up, or falling apart, I would like to hear which.