AI Adoption Reports

Every engineering organization is somewhere on the same journey right now: AI coding tools have arrived,  assistants that complete code in the editor, chat models that draft whole modules, agents that open pull requests on their own, and licenses have been bought. What comes next is the hard part, because the questions leadership asks cannot be answered from a vendor dashboard or a license count. Is the tooling actually used, or shelfware? Is it making delivery faster, and by how much, in hours and money rather than vibes? Is the speed real, or is it borrowed from quality; half-finished PRs, thinner reviews, code that gets rewritten two weeks later? And with several tools in the mix, which ones earn their seat?

The AI Adoption page exists to answer those questions from your own data: your commits, pull requests, reviews and billing, instead of vendor-reported success rates. That grounding matters more than it sounds, an AI tool that shines in a demo can underperform on a legacy codebase with strict review norms, and the only way to know is to measure it where the work actually happens.

The page approaches adoption from four angles that are worth keeping apart. 

Breadth: how many developers genuinely use AI, not just hold a license (Activity Overview). 

Depth: how much of the code AI actually writes, and how independently agents deliver it (AI Contribution, Agent Contribution). 

Value: what the organization gets back: recovered hours, net money after tooling costs, faster delivery (Time Saved, Cost Saved, Delivery Speed, Lead Time).

Safety: what it costs in quality, the angle most often skipped (Quality & Maturity). Vendor Comparison and AI Effectiveness sit across all four, breaking the picture down by tool and by team.

A few habits make the reports far more useful. Never read a value metric alone, pair it with its context: Time Saved against adoption breadth, Delivery Speed against quality, AI Contribution against rework. Distrust spectacular numbers in the first weeks; several reports deliberately hold back until there is enough data, because two fast PRs can masquerade as a "50x speedup". And treat the team drill-down as the main tool, not a detail: adoption is never uniform, and the teams where AI works brilliantly (or quietly hurts) only become visible one level below the company average.

AI Contribution

It measures how much of the code changed during the selected period was produced with AI assistance versus written without it, and visualizes that distribution over time.

This is one of the clearest indicators of actual AI adoption. Assigning licenses or enabling AI tools does not necessarily mean they are being used in day to day development. AI Contribution reflects whether AI is becoming part of the team's development workflow and how that usage evolves over time.

In many organizations, this metric continues to increase even after license adoption stabilizes. Early adoption typically involves a small group of enthusiastic users, but as confidence grows, AI usage spreads across more developers and more types of work. The result is a gradual increase in AI generated code, even without purchasing additional licenses.

The metric should not be interpreted in isolation. A rising AI contribution is valuable only when delivery quality remains stable. If AI Contribution increases while Quality and Maturity metrics remain healthy, it is a strong indication that teams are successfully integrating AI into their engineering practices rather than simply generating more code.

Delivery Speed

Delivery Speed isolates pace from volume: how much faster does AI-assisted work travel through the delivery pipeline than everything else the team ships? The result is a simple multiple, "1.8x" means AI-assisted work complete in roughly half the time, shown alongside the average completion days of both groups so the ratio always has context. It sits at the head of the cycle-time breakdown it comes from, so the steps underneath always show where the difference was made.

Those steps are the same phases the Cycle Time Breakdown report uses, measured the same way on both halves of the work, so the two screens cannot tell different stories about the same period. Each step carries the mean on the AI side, the mean on the rest, and the gap between them, and a gap is only called out as a real difference when there is enough work behind both sides and the difference is large in relative and in absolute terms. Five minutes against two is arithmetic.

The figures come from the pull requests and issues Valven collects from your connected source control provider and issue tracker, over the selected date range, and follow the same project and team filters as the rest of the screen. 

One case is worth knowing about, because it arrives on its own as adoption widens: a team can reach the point where the selected period holds almost no non-AI work left to compare against. The card does not disappear when this happens. Valven looks for the baseline elsewhere, first across the whole company over the same period and then further back in time, and prints under the legend which one it settled on. When a borrowed baseline is in use, read the figure as "this team, this month, against the company's recent history."

One limit applies whatever the figure says. The comparison cannot see which work was handed to the AI, and developers tend to reach for it on the routine and repetitive parts of a change. Routine work travels quickly whoever writes it, so some of any gap here belongs to the work itself, and the multiple tends to read higher than the tool alone would earn. Treat it as a reason to look at the steps underneath it and at the quality cards further down the page.

Innovation Ratio

Innovation Ratio answers what the delivered work was actually for: of the effort that went into the product in the period, how much built new functionality. It is the outcome most AI programs are bought for. Time recovered from routine work is only worth anything if it flows into features.

The headline covers all the work in scope, AI-assisted and not. The two bars underneath show that same share measured inside each half, so you can see whether AI-assisted work leans further toward new functionality than the rest of the delivery does. They are not a breakdown of the headline: each is taken over its own population, so the three figures have three different denominators and the bars do not add up to the number above them. The counts in brackets are issue counts, there for context only. The percentages are weighted by how much effort each piece of work took, so one substantial feature is not outvoted by a run of small fixes.

The classification comes from the issue tracker you have connected to Valven, so it is only as good as the issue types your teams actually use. Work whose type Valven cannot place as new functionality or as repair is not in either side of the ratio. Where the scope holds no classified work at all the card is left empty, so that a company delivering nothing does not read the same as a company delivering no features. It is read over whole months, so a partial month at the edge of the selected period can move it by a point or two. It can be read for the company or narrowed to a team.

A ratio that falls while AI Contribution rises is the pattern to watch for: more code, more of it generated, and more of the effort going into repairing what is already there. Read it next to Quality & Maturity, which usually says why.

AI Effectiveness

AI Effectiveness is the leadership map of the whole program: every team is a dot, placed by how much AI it uses (the AI-written share of its changed lines) and the quality of what it ships (a single 0–100 blend of PR maturity, review quality and rework). The four quadrants tell the story at a glance: teams that combine high AI usage with high quality are your reference practices worth copying, while teams where heavy AI usage coincides with low quality are where coaching pays off most.

Averages hide exactly this variance, which is why the page needs a scatter and not another single number. Selecting a team drills one level down into its sub-teams, and a team with no sub-teams switches to a per-PR view on the same two axes, so you can follow a pattern from the org level all the way down to individual pull requests.

Agent Effectiveness

This card focuses on the most autonomous form of AI: coding agents such as the Copilot agent, Cursor or Claude Code that author commits and open pull requests themselves. The headline share shows how much of the delivered code the agents produced, their portion of all changed lines in the period. Every agent PR is attributed to the human who triggered it, so the numbers stay meaningful at team level and nothing is credited to a faceless bot account.

The three companion metrics measure how independent that work really was. 

First-pass success is the share of agent work that landed without a person stepping in: PRs that merged exactly as the agent opened them, with no follow-up commits, and sessions that ran through with no interruption and no error. It is the closest thing to a "did it just work?" rate.

Human intervention counts the opposite case: PRs where somebody had to push corrections into the agent's branch before it could merge, and sessions the developer interrupted mid-run.

Average iterations shows how many rounds a typical piece of agent work takes: commits on an agent PR, prompts in a session, averaged over everything the agents did. A value near one means agents mostly land their work in a single attempt.

Read the three together over time: rising first-pass success and falling intervention, with stable quality elsewhere on the page is the evidence that trust in agents, and the scope of tasks you hand them can be expanded.

AI-Assisted PR Stability

Where a period holds no agent work at all, no agent-opened pull requests and no desktop agent telemetry, the same card answers the nearest question it can from pull requests alone. AI-Assisted PR Stability looks at the pull requests carrying AI-assisted work and asks how finished they were when they were opened. The headline is the share that merged exactly as delivered, with nothing pushed on top of them afterwards, and the rest is split by how much correction it took, from a light touch through to a substantial reworking.

The readiness judgment is the same one Quality & Maturity applies to every merged pull request, so AI-assisted work is held to the same standard as the rest of your code. Read it the way you would read first-pass success: stability rising while the AI share rises is the evidence that generated code is arriving finished. Stability falling as the share rises usually means code is being opened for review before anyone has read it.

Agent Effectiveness Over Time

The same four agent figures, plotted month by month across the selected period, so the question stops being "how autonomous are the agents" and becomes "are they getting more autonomous". It is drawn only when the period covers more than one month. There is nothing to trend inside a single one.

This is where a rollout either shows or does not. The shape to look for is the agent share climbing while first-pass success climbs with it and intervention falls, which says the scope of work being handed to agents can widen. A share climbing while the other three deteriorate says the opposite, and usually sooner than the quality metrics on the rest of the page will.

Quality & Maturity

Speed means little if it is paid for with hidden quality debt, and this card is the counterweight to the KPIs above it. It tracks four signals, each with its change against the previous period, so you can see at a glance whether growing AI usage is bending any of them in the wrong direction.

PR maturity looks at how much rework a merged PR needed after it was opened. Every PR is classified, from "ready" (merged exactly as opened) through minor and iterative correction down to heavy rework, and the mix becomes a 0–100 score. A falling score means PRs are increasingly opened half-done and finished under review, a pattern that often appears when generated code is pushed out prematurely. 

Review quality guards the other side of the same door: it blends how many PRs actually received a review, how thorough those reviews were relative to the size of the change, and how quickly authors responded to feedback. AI can flood reviewers with more code than they can genuinely read, and this is where that shows up first.

Churn rate is the share of recently written code that had to be churned again shortly after landing, the classic symptom of code that compiled but didn't fit. 

New work measures how much of the effort went into building new functionality rather than fixing or reshuffling what exists; healthy AI adoption should push this up, since time recovered from boilerplate ought to flow into feature work. If all four hold steady while adoption grows, the speed gains are real.

Activity Overview

While AI Contribution focuses on code, Activity Overview focuses on people.  Activity Overview is the adoption context for everything else on the page. Active users shows the percentage of developers who genuinely used AI in the period, so owning a license is not enough. PR throughput counts the pull requests the organization shipped, and workload converts the total commit and review effort into full-time-equivalent engineers. Each comes with a monthly trend.

Read the value KPIs against this card: zero time saved means something very different at 5% adoption than at 80%. During a rollout the pattern you want is all three moving together: adoption spreading, throughput rising, workload stable; which says more people are shipping more with the same capacity.

Agent Usage

Agent Usage is the raw activity behind every agent figure on the page: how many developers actually ran a coding agent in the period, how many sessions they ran, how long a typical session lasted, how many prompts it took and how many tokens went in and out. These are usage figures, which is why they sit apart from the outcome cards. Each carries its own monthly trend.

Session length is reported as a median rather than an average, because a single session left open over a weekend would otherwise decide the number. It measures active working time: long gaps where nothing happened are not counted as work. The figures come from the desktop agent on your developers' machines, so the strip only appears once that telemetry is flowing, and a team using AI heavily without the agent installed shows nothing here. Tools differ in what they report. Where none of the tools in scope reports token counts, the token figures are left out. They are not shown as a measured zero. Where some of them do and some do not, the token figure names the tool it had to leave out, so a partial total is not read as the whole.

Read prompts per session alongside first-pass success. Sessions that take many rounds to get anywhere are the everyday sign of an agent being handed work it cannot yet do on its own. That pattern shows up here before it shows up as rework further down the page.

Activity Breakdown

Activity Breakdown opens up what happened inside those sessions: the prompts developers sent, the responses that came back, the tools the agent ran, and the edits it made to the codebase. It also breaks down the three ways a session goes wrong: the interruptions a developer made, the tools that failed and the errors the agent hit.

The value is in the proportions. Plenty of tool use and edits against few interruptions is an agent working through tasks on its own. Many prompts producing few edits is a conversation that is not turning into code. Tool failures rising against a steady session count usually points at something in the environment: a missing permission or a broken command.

The chart rests entirely on desktop agent telemetry. Where none has been collected for the selected period, it is hidden altogether, not drawn empty. Sessions whose tool never identified itself are still counted here, even though they cannot be attributed to a vendor on the cards that split by tool.

Model Usage

Model Usage shows which models the work actually went through, with the sessions and tokens reported by the agents themselves on one side and, on the other, the lines of code the commits attributed to each model. The two answer different questions, and it is worth reading them together: a model can take a large share of the sessions and a small share of the delivered code, which is the signature of a model being used to think. Its data is fed by agent telemetry.

Lead Time Breakdown

When agent deliveries feel slow, the reflex is to blame the AI. This report shows whether that's fair. It breaks the total lead time of agent pull requests into phases: generating the code, waiting for and undergoing review, and waiting to be merged after approval, each as a share of the whole.

The report is built from agent-opened pull requests, so it needs some in the selected period to have anything to break down. Where there are none, the card is hidden and no empty donut is drawn in its place.

The value in the center of the donut is the total lead time of a typical agent delivery, in days. Each slice around it is one phase, sized by its share of that total, and hovering a slice shows the phase's own duration alongside its percentage. The three phases have precise boundaries.

Code generation starts at the first commit (or the pull request's creation, whichever came first) and ends the moment the pull request is ready for review: for draft pull requests that's when the draft flag is lifted, otherwise when the pull request is opened. It captures the time the agent (and any human touch-ups) spent producing the change itself.

Review runs from that ready-for-review moment until the final approval: the wait for a reviewer to pick the pull request up, the review rounds, and any back-and-forth in between all land here.

Merge wait is the tail end: the pull request is approved, nothing is being changed anymore, yet it sits unmerged until someone (or a pipeline) actually closes it. A fat slice here usually points at release trains, batched merges or plain forgetfulness.

In most organizations the surprise is that generation is the smallest slice. The human pipeline around the agent, the review queue and the wait to merge, is what dominates the clock. That makes this the right report for deciding where to invest: faster agents, or faster reviews.

Vendor Comparison

If you run more than one AI tool, this report puts them on a single 0–100 scale scored against your codebase and review standards rather than vendor marketing. Each tool's pull requests are evaluated across five weighted dimensions. First-pass success and autonomy carry the most weight and come from agent-opened PRs: did the work merge as delivered, and how rarely did a human have to step in? PR maturity and review quality apply to every AI-assisted PR and reuse the same definitions as the Quality & Maturity card, so vendors are held to the same standard as your human-written PRs. Delivery speed compares each vendor's completion times against your non-AI baseline.

Tools don't all work the same way, so dimensions a vendor genuinely has no data for (a copilot-style assistant that never opens its own PRs, for instance) are excluded and the remaining weights renormalized instead of being punished with zeros. Use the result for portfolio decisions: where to consolidate licenses, which tool to expand, what to pilot next.

Recent Sessions

The most recent agent sessions in the selected period, newest first: who ran each one, how long it was active, how many prompts and interruptions it took, the tokens it consumed and the model behind it. Selecting a session opens the session itself, where the same figures are broken down event by event alongside the commits that came out of it.

The list is the fastest way from a number on this page to the work that produced it. That makes it a person-level view: it is shown only where individual reporting is permitted, and a company reporting at team level does not see it at all. Like everything else built from sessions, it exists only where the desktop agent is reporting.

Shadow AI

Shadow AI answers a governance question: is anyone running a coding agent signed in with a personal account instead of a company one? The account is reported by the agent itself, so this is the one reading on the page that is observed.

It needs your company email domains to be configured before it can judge anything. Without them, Valven hides the section instead of printing a verdict nobody measured. With them in place, every session whose account falls outside those domains is counted. The card names the tool, how many people and how many sessions were involved, and the domains seen, never the addresses themselves, so it stays safe on a screen where individuals may be hidden. A subdomain counts as a different domain, deliberately.

Beside the verdict sit the number of sessions seen at all and how many of them carried an account, and they matter: a clean verdict on a scope that never reported any telemetry is not the same statement as a clean verdict on a thousand sessions. Changing the domain list re-judges the history that has already been collected, since a stored verdict only means anything against the list it was judged with.