The Meter Was Running

The CFO is in the room now. Eight months ago, when leadership said "give every developer AI coding tools, it'll pay for itself in productivity," the CFO wasn't asking questions. The cost was small enough to wave through. The promise sounded plausible. Everyone else was doing it.

Now the quarterly bill is a line item. Projected annual spend is well into six figures — and that's before engineering teams start adopting agentic workflows, which will multiply token consumption significantly. The conversation has shifted from "everyone needs AI tools" to "prove these tools are worth what we're paying."

And engineering managers across the industry are finding they can't. Not cleanly.

You've got adoption metrics — developers use the tools daily. You've got satisfaction scores — they like the tools, which is table stakes. You've got proxy metrics — PR merge time is down. But the connection between those numbers and actual revenue impact, or a specific dollar figure of productivity gained? Genuinely impossible to make. Not because the tools don't work. Because nobody built the measurement framework before hitting deploy.

This is the governance gap. And it's landing on engineering leadership everywhere right now.

The Bet That Became a Budget Line

"It'll pay for itself" is a bet, not a plan. Bets don't require ROI frameworks. Investments do. The distinction matters because when you deploy tools as a bet, you never build the measurement infrastructure that would let you cash out later.

The trap is that proxy metrics feel convincing in the moment. PR merge time is a real signal. Developer satisfaction matters. Daily usage tells you adoption actually happened. These aren't fake numbers — they're just not the numbers that answer the CFO's actual question, which is whether the organization is getting more done, faster, in ways that translate to customer and revenue outcomes.

If you didn't measure baseline cycle time before deployment, you can't calculate change. If you didn't tie delivery acceleration to revenue impact, you can't build the case. The meter was running from day one, but nobody was watching it.

We've seen this pattern across engagements. The instinct is to instrument after the fact — pull historical data, reconstruct a baseline, find something that looks like correlation. Sometimes it works well enough to satisfy a CFO short-term. But you're always fighting uphill, and the next request is harder: justify the expanded spend when agentic workflows add another 40% to the bill.

There's also a quieter problem hiding in the cost structure: token waste. The same codebase context gets re-sent with every inference request — no caching, no persistent understanding, no efficiency optimization. It's the equivalent of re-indexing your entire library every time someone looks up a word. That's a solvable technical problem, but only if someone owns it deliberately. Nobody owned it because nobody planned for the bill.

The Constraint Moved and Nobody Noticed

Here's the more interesting problem — and the one governance frameworks mostly miss: AI didn't just change the cost structure. It changed where the bottleneck lives.

For most of the history of software engineering, code production was the constraint. That's why teams were structured with five engineers per designer, per PM. Writing the code was the hard, slow part. Everything else — requirements clarity, code review, quality assurance — was organized around that reality.

AI tools accelerated code production. Which means the constraint moved. Teams are now producing more features than they can reliably test, review, or validate. Requirements that were vague before remain vague, but now engineers implement them faster. Code review queues are backed up because humans can't review AI-assisted output at the pace it's being generated. QA is overwhelmed. Unsanctioned design choices multiply because engineers are moving so fast that architectural alignment doesn't happen until after the fact.

More output isn't more value when the bottleneck is downstream. You optimized the one thing that wasn't limiting you, and left the actual constraints untouched. The team structure, the review process, the QA investment — all of it was calibrated for a world where writing code was the hard part. That world is gone, and the org chart hasn't caught up.

Some teams are responding by declaring bankruptcy on human code review altogether — shipping faster, attributing accountability to the individual engineer, relying on rollback capability and DORA metrics as their safety net. That can work in specific contexts. But it requires the kind of intentional governance decision that most teams never made explicitly. It just happened, because review queues got long and everyone quietly stopped waiting.

That's not governance. That's drift.

Two Gaps, One Problem

The practical situation is actually two distinct governance gaps that tend to get collapsed into one.

The first is cost governance: token budgets per team, caching strategy for repeated codebase context, visibility into which teams are driving consumption, and clear decision rights about which workloads justify agentic workflows versus simpler autocomplete. Most organizations that deployed AI tools broadly have none of this. The bill is an undifferentiated lump that nobody can attribute or optimize.

The second is constraint governance: deliberately restructuring around where the bottleneck actually lives now. That might mean shifting headcount toward review and QA. It might mean investing in better requirements discipline so that what gets built faster is also worth building. It might mean recognizing that the PM-to-engineer ratio that made sense three years ago doesn't make sense when engineers ship three times faster. These are organizational design decisions, not tool configuration problems.

Both gaps have the same root cause: the tools got deployed by leadership, and governance got left to figure itself out. Tool vendors don't solve this for you. Team leads can't solve it independently because it crosses organizational boundaries. It requires someone with both the technical understanding to see the constraint shift and the organizational authority to act on it.

Getting in Front of It

If you're deploying AI coding tools now, the governance framework comes first. Not after the bill arrives, not after the CFO asks. Define what you're optimizing for before you turn on the meter: delivery cycle time, defect rates, time from requirements to production. Establish team-level token budgets and cost visibility from day one. Ask what constraint you're actually trying to remove — and verify that it's code production, not something else.

If you're already deployed without a framework, start with the baseline reconstruction. Pull the data you have. Be honest about what you can prove and what you can't. Then build forward — instrument what's missing, set up caching and cost attribution, and have the explicit conversation about how team structure needs to shift given where the constraint actually lives. The CFO question is hard to answer retroactively. It's straightforward to answer if you built for it in advance.

The organizations getting real value from AI tooling aren't the ones who deployed the most tools. They're the ones who treated the deployment as an engineering problem: measure the current state, define success, attribute costs, and adjust when the constraint moves. That rigor is the difference between a productivity bet and a productivity investment.

If you're navigating this and need help building the governance framework — before or after the CFO walks in — that's exactly the kind of work we do.