The economics of AI coding agents: why cost-per-feature beats story points

Story points were never really about points. They were a proxy, a rough way to compare effort across tasks when the actual unit that mattered, time and cost, was hard to measure consistently across a team of humans with different speeds, different specialties, and different definitions of "done." For a purely human team, that proxy was good enough. It stops being good enough the moment agents enter the picture, because agents make the thing story points were always approximating, actual cost, directly measurable for the first time.

Story points assume a roughly constant cost per point

The implicit assumption behind velocity tracking is that a point is a point, more or less, regardless of who does the work. That assumption was always a little shaky with humans (a senior dev and a junior dev do not cost the same per hour, even if they estimate the same story the same size), but it was close enough that nobody worried about it much.

Agents break the assumption completely. Two tasks that would have been estimated identically in story points can have wildly different actual costs once you account for token spend, iteration count, and review overhead. A task that looks like a 3-pointer might cost a few cents in agent time and ten minutes of human review. Another 3-pointer might cost several dollars in token spend across a dozen failed iterations before converging on something mergeable. Story points do not distinguish these. Cost-per-feature does, immediately.

What cost-per-feature actually captures

A cost-per-feature view is not just "how many tokens did this take." Done properly, it is a small set of numbers that together tell you whether a piece of work was actually cheap or just looked cheap:

• Direct cost: token spend for the agent work itself.
• Iteration count: how many attempts it took to converge on a working solution. High iteration count with low direct cost can still mean a task that took an agent six tries to get right, worth knowing even if the dollar figure looks small.
• Review overhead: how much human time went into getting the output mergeable. A "cheap" agent task that needs forty minutes of human cleanup before it ships is not actually cheap; the review time is a real cost that a token count alone will not show.
• Rework rate: whether the shipped feature needed a follow-up fix within a short window after merge. A feature that looked complete and then needed a patch three days later has a real cost that a single snapshot in time does not capture.

Put those four together, per feature, and you get something velocity charts were never built to show: which categories of work are genuinely a good fit for agent delegation, and which ones only look efficient until you account for what happens after the initial diff lands.

The question this actually answers: where should agent effort go next quarter

The practical value of tracking this is not retrospective bragging rights. It is a forward-looking allocation decision. If a specific category of task, say, routine test coverage additions, consistently shows low direct cost, low iteration count, and low rework rate when handled by an agent, that is a strong signal to keep routing that category to agents. If another category shows low direct cost but high review overhead and high rework, the "cheap" appearance is misleading, and it might genuinely be faster, all-in, to route it to a human instead.

Without cost-per-feature tracking, this decision gets made on vibes, usually the vibes of whoever had the most recent bad experience with an agent output, which is not a reliable basis for an org-wide allocation policy.

Why this matters more to CXOs than it sounds like it should

Agent spend is a genuinely new line item, and it is one that is easy to either underreport (nobody is tracking it carefully, so it looks smaller than it is) or overreact to (a few visible expensive failures get remembered more than the many quiet cheap successes). Cost-per-feature tracking, done at the level of individual features rather than an aggregate monthly total, is what lets a CXO answer "was this investment worth it" with an actual distribution instead of an anecdote. It is the difference between "agents seem to be working out" and "agents are clearly worth it on these three categories of work, and we should reconsider the other two."

Story points are not going away. They are just not the metric that matters anymore.

None of this means story points are useless; they still help with rough team-level planning conversations. But as the metric that determines whether your AI-agent investment is paying off, they were never built for that job, and pretending otherwise is how orgs end up six months into agent adoption with a gut feeling about ROI and no actual number behind it.

SignalsAI tracks cost, iteration count, and rework per feature, split by human and agent, so this is not a report you have to build by hand.