Measuring Value Generated By AI

Let’s get this out of the way. If you’re not doing your job with AI, you’re already behind. That’s not hyperbole. That’s where we are.

The fallacy I keep hearing: personal productivity adds up to organisational productivity. It doesn’t. A team of individually “productive” people can still ship nothing that matters. So how do leaders actually move the needle?

As a believer in Agile, I continue to embrace change and adapt. This is how I’m tying AI transformation to measurable value.

The Adoption Onion

Every podcast, every opinion piece is about how teams are shipping code faster with AI. Meanwhile, headlines about headcount rationalisation confirm the stakes. The FOMO is justified.

The response is predictable: bootcamps, hackathons, re-skilling, new hiring rubrics. All valid.

However, underneath every one of these initiatives is an untested assumption — that AI adoption automatically translates to organisational output. It doesn’t.

This the Adoption Onion. Peel it fast enough and tears are guaranteed.

CFOs are still understanding token costs and their sticker shock. Security teams are drawing lines around IP — and the risk of blindly accepting AI-generated code without scrutiny is real, with enterprise-scale consequences. Legal is trying to protect organisations that can’t wait for the legalese to catch up. IT is still figuring out provisioning, metering, and SSO integration across a sprawling tool landscape.

Even after all that — you still have to get every product manager, designer, engineer, and automation tester to actually change how they work. The lines between definition and implementation will blur.

The tears are unfortunately, mandatory. Every transformational technology has demanded them.

The Towel

If the onion guarantees tears, you need a towel. No metaphor fits this moment better — the disorienting scale of change, the need to just keep moving. RIP Douglas Adams.

As I mapped out a guide for my team, I kept returning to the same question: why do we build anything? To deliver value to customers. Everything else is noise.

I’ve written before about Planning & Value Scores. That framework is more relevant now than when I first wrote it.

Measuring Value With AI

Productivity is a dark art. Everyone claims it individually. Almost no one can prove it organisationally. Tying AI-driven productivity to organisational benefit isn’t optional — it’s the whole game. Technical teams (Product, Design, Engineering) are notoriously hard to measure. Methodologies exist. None are consistent.

We celebrate wins and forget how we got there. Every org refactor, every structural change compounds the complexity and masks measurement further.

Leaders outside engineering largely operate on observable outcomes — revenue, retention, customer sentiment — measured or otherwise. To be clear, that’s not a gap in their rigour, that’s the job. What’s missing is the translation layer: a way to make engineering output legible in those terms.

That’s what the Value Score is. Not a vanity dashboard for engineers. A common language for the whole organisation.

Value Score

Quick recap of the framework. Any unit of work that results in something a customer can experience: Value = 1. Everything else; bugs, production issues, debt that doesn’t measurably improve cost or operations deliver Value = 0.

It’s binary. Deliberately. If it’s fixing what’s already live, you’re not adding value, you’re recovering ground. The Product Manager, as the designated voice of the customer, makes the call on grey areas.

What’s The Baseline?

Teams are already delivering value — without AI. That’s the baseline. AI should move it up.

Though, here’s what actually going to happen: building with AI unlocks more throughput, which floods every downstream function that hasn’t adapted.

Think about what happens to your CI/CD pipeline when code generation accelerates dramatically. The code review gates, test coverage thresholds, environment parity requirements, none of that scaled with the AI tooling. You end up with an accordion effect: more code in, same constrained pipe, longer queues, slower actual delivery. The throughput gain evaporates at the merge queue.

Observability makes this worse. Your monitoring and alerting frameworks were calibrated for a system that changed at a human pace. AI-assisted development means your system is changing faster than your dashboards can track. You’re flying faster with a smaller windshield. Observability frameworks must keep up with the rate of change — not as a nice-to-have, but as a prerequisite for delivery at scale. There is a whole area of Observability around what your agents are doing and how you’re feeding back into their learning loop, to improve them.

The constraint isn’t engineering effort anymore. It’s pipeline homogeneity. Teams that don’t aggressively standardise their CI/CD tooling, deployment patterns, and observability stacks will hit a hard ceiling — not because they can’t build, but because they can’t ship and monitor what they’ve built.

AI transformation isn’t an engineering problem. It’s an organisational one.

Insisting On AI-Led

Value Score alone isn’t enough. You can hit great numbers and never touch AI. Transformation is the goal, you have to incentivise the method, not just the outcome.

One check metric: AI tool usage logged per story. Not perfect — every metric gets gamed. Though the question to ask is: are you honest about what you’re optimising for? Vanity metrics feel good. They don’t keep you competitive.

Consider the test case scenario: a team uses AI exclusively to generate test data and test cases. No direct customer value in those stories. Over time, quality improves, production incidents drop, and the team reclaims time to ship features. The value score lags the actual improvement. That’s fine — it’s a check metric, not the whole story.

The proof is in what you can demonstrate to the organisation: we are moving faster, with fewer regressions, and our customer-facing output is compounding.

The Agentic Layer

Everything so far assumes a human picks up a story, uses AI as a pair, and ships. That’s already changing.

Agentic AI brings autonomous systems that don’t just assist but act, that is the next layer of the onion. Agents that can read a brief, write code, run tests, flag anomalies, and open a PR without a human in the loop for every step. This is happening in production environments now.

It changes the measurement question but doesn’t break it. Agents still need to pick up work from somewhere. They still produce output that either delivers customer value or doesn’t. The Value Score holds. What changes is who; or what, is doing the work. I catch myself referring to agents as if they were real assistants and it’s frankly spooky! Another thing to get used to.

The implication is actually a forcing function for something we haven’t been good at: writing good stories. A well-formed story: clear acceptance criteria, defined scope, observable outcome, vertical slicing, thats is what makes work portable. A human engineer can paper over a vague brief with judgment and a Slack message. An agent cannot. Sloppy articulation of work becomes a full stop.

The discipline of writing better stories isn’t just good hygiene anymore. It’s the interface between human intent and agentic execution. Get that right and you can plug in any worker, human or autonomous , and get consistent output. Get it wrong and your agents will produce confident, fast, and incorrect results.

Governance follows the same logic. Agents need guardrails, what they can access, what decisions require human sign-off, how their actions are logged. This is not a technical problem. It’s a policy problem that technical teams will be left to solve if leadership doesn’t engage. The organisations that treat agentic governance as an engineering concern will regret it at scale.

The Skills Reckoning

I’ll be direct about something the upskilling conversation usually avoids. There is an assumption baked into most enterprise AI transformation programs: given enough time, training, and psychological safety, everyone will adapt. Run the bootcamp, fund the courses, celebrate the early adopters, and the organisation moves together. I don’t think we have that kind of time.

The gap between workers who are AI-fluent and those who aren’t is not a gentle slope. It’s widening, fast. The engineers who’ve internalised AI-assisted development aren’t just faster — they’re operating at a different level of capability entirely. They’re taking on work they couldn’t have done before. The ones waiting for a structured program to tell them how are already behind.

I’ll be opinionated here: we work with smart people. Smart people see which way the wind is blowing. They adapt because they want to stay relevant, not because a training calendar told them to. If someone is genuinely capable and motivated, the tools are available, the expectation is clear, and the support is there, they will find a way.

The organisational obligation is to make the expectation explicit and the tools accessible. The individual obligation is to move. Waiting for the organisation to carry you through this transition is a bet I wouldn’t make.

Geopolitical Risks, Costs, and Tooling

It would be naive not to think about geopolitical risk in 2026. We are currently assuming that cloud-accessible frontier models will remain available, affordable, and unencumbered. That assumption deserves scrutiny. Export controls, data sovereignty requirements, and the concentration of SOTA models in a handful of US-based providers are real variables.

Organisations should think about continuity: what happens if a key model or API becomes inaccessible overnight.

This connects directly to spend. Token and licence costs will come under the same ROI scrutiny as any other infrastructure line item. When that conversation happens, and it will, a value score that your investors and board can understand and see evidence will be the difference between continued funding and a rationalisation exercise.

Tooling will also need a step change. The more interesting question isn’t which AI tools to standardise on — it’s how existing systems evolve their role. Ticketing systems and Scrum or Kanban boards are natural candidates to become control planes for agentic work: the place where human intent is articulated, picked up, and executed, by a human or an agent. Teams are already building in this direction. Stripe’s Minions and OpenAI’s approach to agentic engineering are useful thought starters on where this is heading.

On model strategy: local hosted models, trained over time on organisational knowledge, will handle the majority of common tasks well. Reserve SOTA for genuinely complex problem statements.

This split — local for breadth, frontier for depth — is likely how most mature organisations will manage AI costs without sacrificing capability.

Do We Have A Towel?

Our systems and metrics will keep evolving. They should. What matters is that we can show tangible, defensible value — not just activity.

This moment is different from previous waves of productivity tooling. The capability is too broad and the pace too fast to treat this as optional. Adopt, adapt, and measure what matters.

The towel is the plan. Ship it.