AI Development & Costs: What really adds up

Four instalments of this series have laid the foundation: Part 1 sorts out the market terms context engineering, harness engineering, loop engineering. Part 2 shows why AI code review needs to become a structural principle and how the verification trilemma of human oversight, exhaustive audits and vibe accept can only be dissolved through structural answers. Part 3 describes the five failure patterns we see repeatedly in enterprise loop projects at codecentric. Part 4 introduces the codecentric loop model as a thinking frame, four loops (coding, validation, learning, business), connected through enterprise context management. This instalment draws the economic consequence: what does AI-assisted development actually cost, and where do the bills show up later when no one has planned for them?

A simple prompt does not deliver production-ready software. But with the right loops and clean (enterprise) context management, that frame can be built: at codecentric we now generate highly automated deployable increments for various clients in very different stages of maturity. In practice, we see that it works technically.

But this automation has several price tags, and not all of them are visible at once.

We use AI at scale across the software lifecycle: agents transcribe, document, automate processes and write code. We rethink processes, team rituals and work itself. That works very well, but it also produces a monthly token bill in the deeply six-figure range. Two years ago we would still discuss in projects whether a tool licence for 30 euros per user was worth it. Today autonomous agents with huge context windows rename three files, push a commit through, and burn two euros each along the way which adds up quickly to large sums. The more loops run, the faster the token counter spins.

The pure generation costs, though, are only the obvious factor. Other costs lurk that we quietly push to tomorrow.

AI-assisted development processes can produce large amounts of code in a short time. But they also produce work and obligations in specifying, reviewing, understanding and maintaining code. These downstream costs are currently rarely budgeted. At the same time, new agentic loops also open up opportunities to reduce existing technical debt automatically in the future.

Why Code Review Becomes the New Bottleneck

Code generation gets many times faster human cognition does not.

In a recent Sonar survey of over 1,100 developers, 38 percent said that reviewing AI-generated code is more effortful than reviewing code from their own team. The reason: with machine-generated code, the shared context and the reasoning behind the solution are missing. Yet less than half of respondents currently verify the AI output systematically.

What this gap feels like in practice is illustrated by a large financial services company: after introducing AI coding tools, output jumped from 25,000 to 250,000 lines of code per month. The result was not a faster release, but a blocked system with a review backlog of over one million lines.

Generation grew tenfold. The number of people who have to read, review and understand that code stayed the same. The effort did not disappear — it merely changed its "cost centre".

Which Downstream Costs of AI Development Should We Consider?

We break it down into three blocks:

Cost block	Effort / cost
1. Verification effort (verification tax)	Every output needs structures that make it reliably reviewable: test infrastructure, licences, verification tokens, person-hours in review
2. Comprehension debt	Reviewers understand what the code does but no longer why it was built that way. Hard to measure. Signals: slower onboarding, harder bug analysis
3. Technical debt	Code without real understanding of the enterprise context is harder to extend. Quick workarounds cost later: maintenance backlog, refactoring costs, declining feature velocity after 6 months

1. Verification Effort (Verification Tax)

Anyone who wants to secure AI-generated code in production needs tests that are created independently of the generated code, and mature review gates for critical parts that understand the organisation's requirements and compliance. This effort could be called verification tax — a tax that applies to every generated contribution.

AI is very good at making code look plausible and making tests turn green. Simple, shallow tests are not enough for critical systems.

If we don't check, production will. Those can turn into expensive tests …

Whoever raises the AI share in the code needs a stronger safety net. If you don't plan this budget for test infrastructure up front, you pay the bill later in unplanned bug-fix time.

2. Comprehension Debt

When an agentic loop produces 200 lines of code in five minutes, in review the human often only sees the "what" but can no longer grasp the result semantically at that speed. They no longer see why a solution was chosen or whether subtle edge cases in the data model were missed.

Addy Osmani describes this as comprehension debt: the growing gap between the codebase and the share of it that anyone on the team still understands deeply. A Microsoft Research study (Lee et al., CHI 2025) with 319 knowledge workers and 936 AI use cases shows the shift empirically: cognitive effort moves from task execution to task oversight, from problem-solving to response integration, from information gathering to verification. Whoever trusts the AI more thinks less critically along; whoever trusts themselves more thinks more.

There is a difference to classic technical debt, though. Technical debt has a ticket owner. Comprehension debt has no owner. It only shows up when an extension has to happen under time pressure or during a production incident („I can see what the code does — but I have no idea anymore why").

Where experienced developers are missing, assessments quickly tip towards „vibe accept" you simply wave through what looks good. (Part 2 on AI code review describes the psychological mechanisms behind this in detail: Normalization of Deviance and the IKEA effect.) Every feature also comes with more context that must be documented in a machine-readable form. Conversations between POs and developers can be transcribed, for example, to make all the small details traceable.

3. Technical Debt Through AI

AI in the coding loop produces syntactically correct code, but without the right context management it knows neither the long-term target architecture of the enterprise nor the roadmap for the next quarter. Without AI, technical debt arises because you take shortcuts while coding. You sometimes decide consciously: „the right path is currently too expensive or too involved, we'll take a shortcut." With AI, shortcuts become less necessary; debt arises more from not having specified up front where you want to be over a longer period.

What looks like dramatic acceleration in the first few sprints turns, a few quarters later, into a system that resists change. Lines of code without clear architecture create a web of implicit dependencies, until rewriting components becomes cheaper than refactoring them.

That is not necessarily bad, it opens up new ways of thinking about the topic. We know the principle from operations, where it is cheaper in the long run to tear systems down and reprovision them than to „nurture and maintain" them until they reach an unmaintainable state.

Why These Downstream Costs Are a Feature, Not a Bug

The three blocks above should not be read as a warning sign, but as a frame. Anyone who takes AI development seriously cannot drive verification effort, comprehension debt and technical debt to zero — they are the price of generation becoming faster than cognition. Whoever keeps them low has either generated too little (the AI acceleration is not working) or reviewed and understood too little (the bill comes later).

The serious path is not „minimise downstream costs" but „make downstream costs visible, budget them, steer them". We didn't optimise testing effort away over the last 20 years — we established it as a discipline. Downstream costs of AI code are the same step, only for the AI era.

LLM FinOps: How to Keep Token Costs Under Control

Back to the obvious costs on the bill. Anyone using AI at scale usually needs an infrastructure that is billed per token. Subscription models are often too small or not usable for compliance reasons. Own hardware is hard to run, and you only get the available open-source models in return (which, depending on the task, are now also very capable).

Users of AI need a view of what costs they are producing when they use AI. Only then can they use the available tools economically. This requires FinOps practices that have to be established in the teams.

The Commercial View in the Team Ritual

Developers need a feel for the price tag of their tools. A review agent that analyses trivial code with the most expensive model burns budget invisibly.

Simple questions in team rituals work in every sprint (examples); of course you can also measure metrics automatically in the build pipeline and track them back to the ticket:

• What did we generate today?
• What did it cost in tokens?
• How could we have achieved the same result more cheaply?

In addition, it can pay off to invest in the following areas:

• Missing enterprise context: An agent without domain knowledge invents its own realities. We have developed a method for this called „consumable domain" that makes enterprise knowledge machine-readable.
• Clearer specification: What has not been defined precisely up front cannot be verified automatically later.
• Senior time in review: Comprehension debt can only be reduced by someone who holds the overall system in their head.
• The right model for the right job: Small local models, or a central LLM gateway that provides different models across different providers.

Finally, more and more best practices are emerging for using AI more efficiently. To improve specification and reduce review effort, colleagues have developed a methodology that carries decades of established best practices into the AI world: EXACT Coding (by Marco Emrich and Ferdinand Ade).

The core sits before generation: examples before code. A well-chosen example is the cheapest and most precise form of specification. A failing test defines the next step in the loop more exactly than any ticket.

Through the principle „humans as corrective at clearly defined checkpoints", scarce senior time is used as a targeted architectural guardrail. This makes downstream costs steerable.

FAQ: Common Questions on AI Costs & Software Development

Why are our development costs rising, even though our teams demonstrably generate code faster with AI?

Because AI coding tools don't eliminate the effort they shift it from writing to downstream phases. While pure generation time drops, the effort for code reviews, automated test infrastructure, understanding foreign logic (comprehension debt) and later refactoring goes up.

What is the difference between classic technical debt and comprehension debt?

Classic technical debt usually arises consciously (e.g. through deliberate shortcuts for a quick release) and can be managed as concrete refactoring tickets in the backlog. Comprehension debt is unconscious and has no ticket owner: it describes the growing gap between the amount of code in the system and the share the team actually understands semantically. It doesn't show up in the linter, but only as time loss during complex extensions or critical bug analyses in production.

At what point does pure token consumption in AI development become a business problem?

Agents that plan in loops, read context, change files and run tests consume many times more tokens per task. LLM FinOps becomes necessary to manage sharply rising API costs. Not every small task is a job for the most expensive agent. Some tasks are still cheaper done by humans.

How do we prevent developers from verifying under time pressure and lapsing into „vibe accept"?

By shifting quality assurance in front of the actual generation loop. Instead of having developers read thousands of lines of black-box code at the end, requirements must be specified up front through clear examples and automated, isolated acceptance criteria (as with EXACT Coding). The generated code is only released for human review once deterministic tests have already proven functional and architectural integrity.

And in Part 6 …

In the final instalment of this series we widen the view once more: how verification and loop thinking extend beyond the coding loop. Shift Left, Shift Right and why the loop model applies to much more than just software development.

Further Reading

• Addy Osmani: Comprehension Debt — the original text on comprehension debt (O'Reilly Radar)
• Melanie Volk: The human side of AI transformation — the same shift from a psychological perspective
• Microsoft Research: The Impact of Generative AI on Critical Thinking — empirical evidence for the shift from information gathering to verification
• Ethan Mollick: The Cybernetic Teammate — on the question of when delegation is worth it in the first place
• Wes McKinney: Adversarial Agents and Roborev — open-source tool for continuous review via Git hook
• EXACT Coding by Marco Emrich and Ferdinand Ade — the training and the book