In short: Most AI dashboards count supply: adoption, accepted suggestions, pull requests. An absorption dashboard counts what the engineering system turns into validated value. Its core numbers are the absorption rate, the share of changes produced that reach production and hold, and validated business value per unit of human intervention, built largely from data organisations already hold.
Why can't most CTOs show what AI is worth?
Engineering is where leaders believe AI pays most visibly. In Battery Ventures' 2026 enterprise technology spending survey, published in July, 28% of the CXOs surveyed named software development and engineering productivity as their clearest area of AI return, and 98% of respondents planned to increase AI spend over the following twelve months. Only 6% reported a well defined framework that tracks return consistently across the organisation, and 43% were still working out how to measure it at all.
Battery's explanation for the engineering result is revealing: coding assistants and automated testing produce gains that are relatively easy to track. Those are measures of production. Across the survey, cost savings and time saved were the most common ways of measuring return, at 76% and 73%, while 38% tracked revenue attributed to AI. Battery is a venture investor and the article does not state its sample size, so these figures are best read as directional.
The pattern is the one described in What Is Your AI Engineering System Optimising For?. Boards see what AI produced, and few organisations can show what the business received in return.
What do today's dashboards actually count?
Adoption, accepted suggestions, pull requests, tokens and time saved all measure supply. Each is taken at the point of production, which is the part of the system AI inflates, so each can rise while delivery stands still. Not Yet showed where that leads: in a modelled case of twelve teams, extending agents to every team raised supply and left the signature metric 1% lower.
An absorption dashboard places a second column beside the first. It asks how much of what was produced the organisation actually absorbed, and what that was worth for the human effort it required.
Absorption rate is the share of changes produced in a period that reach production and hold through their health window. It is read by cohort, once the window has closed for every change in the cohort, so that a change merged last week cannot count as absorbed before it has had the chance to fail. The remainder is the Absorption Gap expressed as a rate: work still waiting, abandoned, reverted or traced to an incident.
What do DORA and DX already get right?
Existing frameworks cover a great deal, and an absorption dashboard should be built on top of them. DORA's delivery metrics remain the standard way to read flow and stability. DX's AI Measurement Framework, published in July 2025 by Abi Noda and Laura Tacho, measures AI along three dimensions, utilisation, impact and cost, and deliberately leaves acceptance rate out. With DX Core 4, which spans speed, effectiveness, quality and business impact, it is the most complete public framework for measuring AI in engineering.
DORA's 2025 report adds the finding that matters most here. AI adoption is now associated with higher delivery throughput and still with higher instability, and organisations with mature value stream management see markedly stronger organisational benefits from AI. Value stream management is, in effect, the practice of measuring absorption.
Others have reached the same diagnosis by different routes. In April 2026, Zendesk's engineering team argued that generative AI has moved the limit in software delivery from writing code to what it called absorption capacity. What remains rarely instrumented are the two ends of the ratio: validated value in the numerator, and human intervention, by cause, in the denominator.
What should the dashboard show, and to whom?
Three layers tend to work, each answering a different question for a different reader. Supply and absorption stay in separate columns at every layer.
Figure 1. The absorption dashboard. Supply and absorption sit in separate columns at every layer, and adoption moves down to diagnostics.
The board view carries six numbers: the signature metric; the absorption rate, with supply and absorbed change drawn as two lines; the constraint now and where it moves next; escapes per hundred changes; lead time; and AI spend per validated change. Five of these were proposed in Not Yet, and the cost line comes from the metric piece.
The CTO view reads each step of the AI Engineering Production System through the same three questions: how long work waits there, how much escapes or comes back, and how many human minutes each change consumes. The step with the longest wait relative to the supply reaching it is where the constraint sits, and the AI Engineering Capacity Map names the capacity at each one.
The diagnostics hold the measures that explain movement without deciding anything on their own: DORA metrics, adoption, agent reach and effectiveness, developer experience and spend. Adoption remains useful at this level for finding the teams that have been left behind.
The two headline numbers are most informative when read together. When the absorption rate and the signature metric fall together, supply is outrunning absorption somewhere downstream. When the absorption rate holds while the signature metric falls, the organisation is absorbing work that moves no declared outcome, or spending more human hours to absorb it, which usually points upstream to focus and intent. A rise in both is the signal that the redesign is working.
How do you compute the two halves of the ratio?
The metric piece defines each term of validated business value per unit of human intervention, and the dashboard should use those definitions unchanged. What the dashboard adds is the source of each half.
The numerator starts with absorbed change, which delivery data supplies directly. Value comes next: counting the absorbed changes that met an outcome declared before build is the simpler and more auditable option, and weighting by value class belongs to a later stage.
The denominator is where most of the new work lies. Each earlier piece in this series named a human cost that belongs there: supervision hours in the Verification System, restoring a broken main branch in the delivery pipeline, interventions caused by missing context in the context supply, incident attribution in operating capacity and approval queues in the control plane. The dashboard collects them in one place, tagged by cause and by step, and measured from systems wherever possible.
Tagging by cause turns the denominator from an estimate into a diagnosis. A total of human hours shows that the ratio moved; hours by cause show which capacity is costing the most to keep up.
Why is the delivery half the easier half?
In one organisation where I contribute, the delivery half is already measured well: merge request rate, the size and speed of merge requests, cycle time and the DORA metrics. These figures come from the code hosting platform and the pipeline with little additional effort.
The value half is harder. Tracking features end to end, reading product metrics after release and validating business outcomes against the human effort they required all depend on things no tool supplies on its own. They need task management that models the value stream, wait states recorded as states rather than buried in comments, and people whose role includes watching the flow.
This is DORA's value stream finding seen from the inside. The numerator of the signature metric is an operating model question before it is a tooling question, and an organisation that buys a dashboard without that discipline tends to obtain a sharper view of supply.
What do you actually build?
The architecture has five layers: sources, linking, a core model, metrics and views. Only the linking layer is genuinely difficult.
Figure 2. What to build. Sources and views are the easier part; the linking layer is where most organisations stall.
Sources. Most already exist: the initiative or portfolio register, work tracking with its status history, code hosting, pipelines and deployments, incidents and observability, product analytics, and the telemetry and spend data from AI tools.
Linking. Every record needs to connect to the next: an initiative to its work items, a work item to its changes, a change to its deployment, a deployment to any incident it caused, and the initiative to the outcome it declared. Each change also records its author type, person or agent, as operating capacity recommends for change provenance. Shared identifiers make these joins possible, the same identifiers a governed context supply depends on, and their absence is the most common reason the value half never appears.
Core model. Seven entities are enough to start: initiative, work item, change, deployment, incident, outcome reading and intervention. The intervention record carries hours, cause and step.
Metrics and views. The metrics layer computes supply, the absorption rate, the signature metric, the three questions per step and the diagnostics, and serves them to the board, the CTO and the teams.
The table below shows which sources feed each number and which link it depends on.
Engineering intelligence platforms already cover much of the source and delivery work, and buying that part is usually sensible. The links to initiatives and outcomes tend to remain the organisation's own work, because they depend on how it plans, declares value and owns its outcomes.
How do you read the constraint from it?
An illustrative quarter shows how the numbers behave. The figures are round and chosen for illustration; Not Yet works through a fully modelled reference case.
Figure 3. An illustrative quarter. Supply rose 41% while the signature metric fell 12%. Illustrative figures.
A product area adopts agents and produces 480 changes in the quarter, against 340 in the quarter before. Of these, 400 reach production and 336 hold through their health window, so the absorption rate falls from 85% to 70%. Of the held changes, 190 carried a declared outcome and 95 met it. Human intervention rises from 2,500 to 3,000 hours, so the signature metric falls by about 12% while supply rises by 41%.
The breakdown indicates where to look. Review and supervision take the largest share of the hours, and 80 changes are still waiting before release, which points to verification and integration. The drop from 336 held changes to 190 with a declared outcome points elsewhere, to intent and focus, where much of the work started without anyone stating what it was meant to change.
How does the dashboard get gamed, and who should it measure?
The metric piece sets out how the ratio itself can be gamed and how to close each route. A dashboard adds routes of its own: changes behind feature flags can be left out of supply, the health window can be closed early, and interventions can be tagged to whichever cause looks most favourable. Versioned definitions with a named owner, and escapes reported beside every rate, close most of them.
The more consequential choice is the unit of measurement. An absorption dashboard measures teams and the system, never individual engineers. Absorption is a property of the flow, so an individual view would mislead as well as discourage, and it would invite the very gaming it is meant to prevent.
The unit also has legal weight. In Germany, the works council has a right of co-determination over the introduction and use of any technical system capable of monitoring employee behaviour or performance, and the capability alone is enough to trigger it. In France, the employee representative committee must be informed and consulted before such tools are introduced. Aggregating at team level does not remove these requirements, since the underlying data can still identify individuals, but agreeing the definitions and purpose with employee representatives from the start tends to make the dashboard easier to introduce and more trusted once it runs. This is a reading of common practice rather than legal advice.
Where should a CTO start?
A sequence of about ninety days tends to hold. In the first month, compute supply, absorbed change and the absorption rate from existing delivery data, together with the wait at each step from work tracking history; the 30 day test in The Absorption Gap provides a first baseline.
In the second month, tag human intervention for the two or three largest causes, measured from systems: review time, rework, restore time and incident time. In the third, link new initiatives to a declared outcome, read the first cohort of outcomes, and name an owner for the dashboard and its definitions.
What should a CTO decide?
Give the absorption dashboard an owner, and fund the linking layer as shared infrastructure alongside environments and test data. Report the absorption rate beside AI spend in every review where spend is discussed. Agree with the business which outcomes count before the work starts, and keep the whole instrument at team level.
The question for your next board
Every AI programme can now show what it produced. The programmes that can also show what was absorbed, and what it was worth, are likely to be in a stronger position when the spending questions become harder.
If your board asked what last quarter's AI spend absorbed, which number would you show?
Read further
FAQ
What is absorption rate in software delivery?
Absorption rate is the share of changes produced in a period that reach production and hold through their health window, without being reverted or traced to an incident. It is read by cohort once the window has closed. It makes the Absorption Gap readable as a single number: when supply rises faster than absorbed change, the absorption rate falls, whatever adoption and pull request counts show.
How do I measure the impact of AI coding tools on delivery?
Measure what the delivery system absorbs as well as what it produces. Track supply and absorbed change as two lines, compute the absorption rate by cohort, and divide validated business value by human intervention tagged by cause. Adoption, acceptance rate and token use belong among the diagnostics, since all of them can rise while delivery stands still.
What should an AI engineering dashboard show the board?
Six numbers are usually enough: validated business value per unit of human intervention, the absorption rate with supply and absorbed change as two lines, the constraint now and where it moves next, escapes per hundred changes, lead time, and AI spend per validated change. Adoption can move to an appendix once most teams use AI.
Can I build an absorption dashboard from the tools I already have?
Most of it, yes. Code hosting, pipelines, work tracking and incident tools already hold the delivery half, and engineering intelligence platforms can assemble it. The value half needs shared identifiers linking initiatives, work items, changes, deployments, incidents and outcomes, plus outcomes declared before build, which depend more on how the organisation plans and owns its work than on any tool.
Should we measure individual developers' use of AI?
An absorption dashboard should measure teams and the system rather than individuals. Absorption is a property of the flow, individual views invite gaming, and in countries such as Germany any system capable of monitoring performance requires the works council's co-determination. Team level reporting, agreed with employee representatives, keeps the instrument accurate and easier to introduce.