The Real Costs of AI-Driven Development: Tokens Are the Cheap Part

When a team considers adopting AI coding agents, the budgeting conversation usually starts and ends with the subscription: some amount per seat per month, or a metered API bill. Compare that to an engineer's salary, conclude it is a rounding error, approve it, done.

The conclusion is right — the tokens are a rounding error — but the accounting is wrong, because the subscription is the smallest line item on the real invoice. Having built three open-source infrastructure tools with agents doing most of the typing, we can report where the money and the hours actually went. None of it showed up on the API bill.

The Cheap Part

Let's dispose of the visible cost first. Token spend and seat licenses are real money, and heavy agentic use — long sessions, large contexts, many iterations — costs more than autocomplete-style tools. It still lands an order of magnitude below the cost of the engineer driving the session. If your adoption decision hinges on the difference between two vendors' per-seat pricing, you are optimizing the wrong line. The expensive lines follow.

Cost One: Review Time

Every line an agent writes still needs a qualified human reader before it ships. That sentence sounds obvious; its budget implication is not. When code generation gets ten times cheaper, code review becomes the bottleneck — and review is done by your most experienced people, whose time was already the scarcest resource you had.

This cost is not optional and does not shrink with better models, because it is not a defect-detection cost — it is a responsibility cost. Someone must be able to say "I understand this change and stand behind it." We wrote a separate piece on how to review AI-generated code without rubber-stamping it; here the point is simpler: put the hours in the budget. If you adopt agents without moving review capacity to match, you have not increased throughput — you have increased inventory of unreviewed code.

Cost Two: Rework from Vague Specs

The most expensive failure in AI-driven development is not the agent producing broken code. Broken code fails CI and costs a retry. The expensive failure is the agent producing a plausible solution to the wrong problem — code that compiles, passes the tests it wrote for itself, reads well in review, and implements a misunderstanding.

That class of failure traces back, in our experience almost every time, to a vague specification. "Add rate limiting" becomes token-bucket-per-IP when you needed per-account; three days later someone notices, and the rework costs more than writing it carefully once would have. The agent did not fail — the spec did. It just failed faster and more convincingly than a human would have, because a human would have asked.

The mitigation is to spend the time up front: specs precise enough to be wrong on paper instead of in production. That is a real cost — senior-engineer thinking time, the least compressible kind — and it is the heart of our development workflow. Budget it. It is still far cheaper than the rework.

Cost Three: The Guardrails

Agents need fast meaningful tests, CI that gates merges, linting, typechecking, and a written conventions file. Teams that have these pay nothing extra. Teams that don't discover that agent adoption comes bundled with the engineering-hygiene project they deferred for years.

We would frame this cost honestly: you owed this debt anyway. Tests and CI pay for themselves with or without AI. What agents change is the interest rate — an ungated codebase rots at the speed one team can type; with agents it rots at the speed agents can type. The absence of guardrails used to be survivable. Now it is expensive immediately, which is arguably a favor. Our adoption playbook for small teams covers the sequencing; the budget point is that "agent adoption" line items often turn out to be 80% "the CI and test suite we should have built in 2023."

The same applies on the infrastructure side: if agents touch your systems, the access scoping and audit logging are part of the price of admission.

Cost Four: The Learning Curve

The skill that determines output quality is no longer typing speed or API recall — it is specification and verification: saying precisely what you want, and checking rigorously that you got it. That skill is unevenly distributed across every team we have seen, and it does not correlate neatly with seniority. Some excellent implementers write vague prompts and skim diffs; some mid-level engineers turn out to be superb at it.

Expect a period where productivity is uneven and a few loud successes and failures coexist. The cost here is training time, patience, and — the part managers underestimate — the discomfort of your best people learning to work in a way that makes their old comparative advantage matter less and their judgment matter more.

What Actually Got Cheaper

An honest accounting cuts both ways. These got dramatically cheaper for us:

• Boilerplate and scaffolding — new services, packaging, config plumbing that used to eat days
• Migrations and mechanical refactors — rename-across-forty-files chores that nobody budgeted honestly before, because nobody wanted to do them
• Documentation upkeep — READMEs, usage docs, and changelogs that actually track the code, because regenerating a draft costs minutes
• Activation energy — the cost of starting something (a tool, a test suite, a doc) collapsed. Projects that would have stayed on the someday list got built. This one is hard to price and might be the largest item on the credit side.

Our own experience: as a very small team we shipped three real, released, packaged tools — nftably, birdy, and meerkat — with output volume far beyond what we could have typed by hand. But that held only because design and review stayed human. The sessions where we got lazy about specs or skimmed the diffs produced exactly the rework this post is about.

Measuring ROI Without Fake Numbers

You will be asked for an ROI number. Resist the fake ones. Lines of code generated is meaningless (volume is now free). "Acceptance rate" flatters whoever configured the tool. Instead track two things you can measure honestly:

1. Reverted-diff rate — how much agent-produced code gets reverted, rewritten, or bug-fixed within a few weeks of merging. This is your rework cost, trending over time. It should fall as specs and conventions files improve.
2. Review hours — actual time spent reviewing, from calendars or PR timestamps. This is your largest real cost, made visible.

If rework is falling while output holds, the adoption is paying. If rework is flat and review is drowning, the problem is upstream — specs, tests, conventions — and more tokens will not fix it.

Takeaways

1. The subscription is the smallest line item — budget review hours, spec time, and guardrails, not just seats
2. Review is a responsibility cost, not a defect-detection cost — it does not shrink with better models
3. The expensive failure is plausible-but-wrong code from a vague spec — precision up front is cheaper than rework
4. Guardrails are debt you owed anyway — agents just raised the interest rate
5. The scarce skill is specification and verification — expect an uneven learning curve
6. Track reverted diffs and review hours — the only ROI numbers that can't flatter you

If you are making the adoption case and want the guardrails, workflow, and honest cost model set up by a team that has already paid this invoice, talk to us.