The AI Cost Iceberg

A platform lead pulls up the AI tooling dashboard before a budget review: forty-one seats, an average of a few hundred dollars per developer per month in tokens and subscriptions, a trend line sitting comfortably under the ceiling finance set at the start of the quarter. The number is real, current, and defensible on a single slide. It is also, on its own, roughly a tenth of what the quarter actually cost the organization — the rest never touched a purchase order.

That missing mass is not a rounding error, and it is not a loose metaphor. It behaves like a literal iceberg: the vendor bills the visible tip, precisely metered because someone chose to meter it, while a larger, unbilled body sits below the waterline — hours spent re-explaining context a previous session already worked out, review cycles a pull request needs because nobody trusts AI output on first read, sessions abandoned and restarted from the top, and, increasingly, a second lane of security scrutiny that never existed for human-written changes. None of it appears on the invoice. All of it appears on the calendar, for anyone who goes looking.

Above the waterline

The visible layer earns its visibility honestly: subscription seats, metered API tokens, occasionally a premium-model surcharge. It updates in real time, it is denominated in a currency everyone in finance understands, and — per the AI Engineering Pyramid this volume opened with — it is the layer organizations have gotten reasonably good at watching, which is exactly why it deserves only a sentence here. The economics worth arguing about live underneath it, in costs nobody installed a meter for.

The ratio nobody tracks

This is the AI Cost Iceberg: the visible costs of AI-assisted development — subscriptions, metered tokens — set against a larger hidden mass underneath — context rebuilding, review time, prompt and session retries, rework, and security review. The name is doing real work, not decoration. An iceberg’s exposed tip is not a rough guess at its total mass; it is structurally guaranteed to be the smaller fraction, because ice floats at a ratio fixed by the relative density of ice and seawater — roughly one part visible to eight or nine submerged. Software cost is not bound by physics the way ice is, so no organization should treat “ten percent visible” as a law. But the direction of every finding in this chapter points the same way: the ratio of hidden to visible cost is large, and it is exactly the number that never arrives as a line item, because none of the systems that track it were built to bill anyone.

Below the waterline: five categories

The submerged mass is not one undifferentiated cost. It has a shape, and the shape matters because each category responds to a different fix. Five categories account for most of it, with different degrees of evidentiary support behind each.

Review time

Review time is the best-measured category, and it deserves to be read as a real cost rather than as noise in the productivity data. In one 10,000-developer dataset, teams using AI assistance completed 21% more tasks and nearly doubled pull-request throughput, while delivery metrics held flat and review time grew 91%. It would be a mistake to read that 91% as evidence that AI’s promise is false — it is evidence that verification work scaled to match generation work, almost exactly, which is what a functioning review process should do when the volume of unverified change increases. The honest framing is that review absorbed the entire visible gain. The less honest framing, common in vendor material, is to report the throughput number and stop.

The category also compounds in an uneven way worth naming: review time on AI-authored code tends to fall on whoever the team trusts to catch subtle mistakes, which in most organizations means senior engineers — the most expensive hour on the roster, spent reading code nobody wrote by hand. A dashboard that reports “tokens per developer” and ignores “review-minutes per senior engineer” is measuring the wrong side of that trade twice over.

Code quality debt

Large-scale repository analysis — over 211 million lines examined by GitClear — reports code duplication rising sharply and refactoring collapsing as a share of total changes since AI coding assistants became common, alongside rising churn on recently added code. The methodology is contested: critics point out that correlation with AI adoption is not proof of causation, that duplication metrics are sensitive to how a codebase is chunked, and that some of the trend predates widespread AI use. The direction, though, shows up consistently enough across the debate that it is worth taking seriously rather than dismissing on methodological grounds alone.

The mechanism is plausible even where the magnitude is disputed: an agent asked to add a feature will, by default, generate new code that resembles an existing pattern rather than extract and reuse it, because reuse requires a riskier, more invasive edit that the agent has no strong incentive to attempt unless explicitly directed to. This is quality debt in the strict sense — interest that accrues quietly and comes due later, in exactly the way this volume’s treatment of context debt describes interest accruing on lost understanding. The two debts are related but not identical: one is paid in engineer time re-establishing context, the other in engineer time untangling duplication nobody intended to create.

Context rebuilding

Every session that opens by re-explaining what a previous session already worked out — the shape of a module, a decision already made and reversed, a constraint already discovered the hard way — is paying a tax this volume names and develops fully elsewhere as context debt. It belongs in the iceberg’s hidden mass for the same reason review time does: it is real engineering time, it is triggered directly by AI-assisted workflows, and it does not appear anywhere the finance team looks. The short version, for a reader encountering the idea here first: context that has to be rebuilt rather than retrieved costs the same attention a human would spend re-onboarding onto a codebase, except it recurs every session instead of once per hire.

Prompt and session retries

A session that drifts off its goal, produces output the engineer does not trust, or simply fails to converge pays a cost with two components: the sunk time of the failed attempt, and the extra care the second attempt now requires because the engineer has learned not to trust a thin specification. Two-thirds of developers cite exactly this pattern — AI output that is almost right but not quite — as their single biggest frustration with the tools, which is a rework cost with no corresponding line item. Retries are the category with the thinnest direct instrumentation of the five: almost no organization currently tracks “sessions restarted on the same goal within 48 hours” as a metric, which is precisely why it belongs on a list of things worth measuring rather than a list of things already measured. The session-level accounting this volume develops elsewhere — treating a session, not a token, as the unit that either produced value or did not — is the natural home for retry cost, once a team starts tagging outcomes at all.

Security and compliance review

This is the newest category and the least well-instrumented, and it is worth saying so plainly rather than forcing false precision onto it. What the available evidence does show is organizations adding a scrutiny lane for AI-authored code that did not exist for human-authored code at the same trust level. A large-scale test of AI-generated solutions across more than 100 models found security flaws in 45% of samples, with wide variance by language and vulnerability class. That should not be read as a precise industry-wide rate — sample selection, task design, and “vulnerability” definitions vary — but it points at a real, emerging cost: code that ships faster than the process that used to catch its mistakes, with the gap currently closed by ad hoc extra review rather than a settled practice.

What to track this week

None of the five categories requires new tooling to start observing. Each has one signal a team can begin capturing this week from systems it already runs — not a complete metric, a starting point.

1. Review time — median hours from PR-open to first substantive review comment, split by AI-flagged versus human-only PRs, tracked weekly rather than as a one-time snapshot.
2. Code quality debt — thirty-day churn rate: the share of lines an AI session touched in the last month that get modified again within thirty days, by file or by directory.
3. Context rebuilding — the share of sessions in a repository that open with a re-orientation prompt (“catch me up,” “what did we decide about X”) rather than a direct instruction.
4. Prompt and session retries — the share of sessions that end without a merged change and are followed by a new session with a visibly similar goal within 48 hours.
5. Security and compliance review — time from PR-merge to security sign-off on AI-authored changes, compared to the same figure for human-authored changes in the same repository.

None of these five signals is a finished dashboard. Each is a first measurement of a cost that currently exists only as a feeling engineers describe in retros — that reviews take longer, that the same bug keeps resurfacing, that a session felt like it was starting over. Turning the feeling into a number is the entire point; the number does not have to be sophisticated to be more useful than its absence.

The waterline metaphor has a limit worth stating directly: unlike an iceberg, this ratio is not fixed by any law, and it is not meant to be minimized to zero. Some review time, some context re-establishment, and some extra security scrutiny on unfamiliar code are the correct price of using a fast, fallible collaborator responsibly. The failure this chapter argues against is not that the hidden costs exist — it is that they are invisible to the people deciding how much AI-assisted work to do, and in which parts of the codebase to do it.