How We Price an AI-Native Sprint: Criteria First, Tokens Second

Man-hours and story points were built for teams where a person’s working speed is roughly stable. AI-native development breaks that logic: two orchestrators can close the same scope of work with completely different resource spend, and the same orchestrator can spend very differently depending on how clearly the task is defined. A client used to hourly estimates first reads this as a lack of transparency. In practice, the formula is more transparent than the classic one — just different.

Step one: criteria, not tokens

Estimating in tokens without defining criteria first is estimating blind. So before we count cost, we fix what “done” actually means for a given task: which scenarios the solution has to cover, which architectural constraints apply, what level of testing is expected.

This step looks like unnecessary process only until the first time it gets skipped. Without clear criteria, an AI agent is just as capable of writing code that technically works but misses the intent and then the tokens spent go not toward the result, but toward fixing iterations.

Step two: token estimate and the hour cap

Once criteria are fixed, a task can be broken into smaller pieces and estimated separately — more accurate than estimating the whole project as one block. Each piece gets an approximate token spend, and the sum converts into a time cap: five hours of orchestrator work on a specific piece of functionality, for example.

That cap isn’t a reporting formality. It works as a budget boundary: if a task starts exceeding the projected spend, that’s a signal to stop and go back to the criteria, not to keep generating code hoping the next iteration will fix the last one.

The result is a cost-effective solution in the literal sense: the client sees the cost before work starts, not on the invoice after the fact.

Why the orchestrator’s experience changes the price

Token spend depends not only on task complexity, but on who is driving the AI agent. A less experienced specialist can burn through several times more tokens on the same task — not because they work worse, but because they write less precise prompts, skip the criteria step, or miss it when the agent drifts off architecturally.

This directly reshapes the role. A senior orchestrator is no longer someone who “writes code faster” — they hold the architectural frame the AI generates within. That role is what decides how many tokens go toward the result, and how many go toward rewriting what was already done wrong.

The risk the model doesn’t hide

The “criteria → tokens → hour cap” formula makes cost predictable, but it doesn’t remove the risk of depending on one person. If the whole context of a task lives in one orchestrator’s head instead of in documentation, the company loses predictability the moment that person gets sick, takes leave, or leaves the company.

That’s why a team always needs someone who can step in and, more importantly, documentation current enough that this person can enter the task without a week of ramp-up. This isn’t about distrust of a specific specialist; it’s about the operational resilience of the process itself.

Predictability as an advantage

A client choosing an AI-native approach is usually less worried about the technology than about budget control. The “criteria → tokens → hour cap” formula gives that control before work starts, not at the end of the month.

That’s what we offer teams who want to stay within their budget without compromising on the quality of the solution: a transparent estimation method, a senior who owns the architectural frame, and documentation that doesn’t depend on one person.

If you want to see how this formula works on your own task — reach out.