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.

Time Saved

Time Saved answers the first question everyone asks about AI: is it actually making us faster? It expresses the gain in plain work hours and days rather than abstract scores, which makes it the natural headline for adoption reviews.

The idea behind it is simple: we look at the period before your selected window and learn how much review and approval time a unit of coding work used to cost when no AI was involved. That AI-free rate is then applied to the current window's workload — the gap between what the work would have cost at the old pace and what it actually cost is your saved time. Because the baseline comes from your own history rather than an industry benchmark, the number reflects your codebase and your review culture, and it can honestly go negative when throughput regresses.

Cost Saved

Cost Saved turns the saved hours into money and, crucially, subtracts what you actually spent on AI tooling in the same period — so what you see is the net return, not a gross vanity number. Saved time is priced with your company's configured average man-day cost, while the spend side comes from per-user daily cost data collected from the vendors themselves (Copilot billing, Cursor, Claude and so on), scoped to the same team filter.

This is the card to bring to budget and license discussions: a healthy Time Saved that melts away here means the tooling bill is eating the gain. The gross saving and the AI spend are kept as separate fields in the data, so you can always see which side of the equation moved.

Delivery Speed

Delivery Speed isolates pace from volume: of the pull requests closed in the window, how much faster do the AI-assisted ones travel from first commit to close compared to the rest? The result is a simple multiple — "1.8x" means AI-assisted PRs complete in roughly half the time — shown alongside the average completion days of both groups so the ratio always has context. Even when AI work is still a small slice of your output, this tells you whether that slice moves through the pipeline faster.

It is worth being explicit about how this differs from Time Saved, because the two can legitimately point in different directions. Time Saved is an absolute volume metric: it compares the whole organization's current output against its own AI-free past, so it only grows when AI work is big enough to move the total. Delivery Speed is a relative pace metric: it compares AI and non-AI pull requests side by side within the same window, regardless of how many there are. A team with two AI PRs that each closed in hours can show a striking Delivery Speed while Time Saved stays near zero — the pace is real but the volume isn't there yet. The healthy trajectory is Delivery Speed proving the effect first, and Time Saved catching up as adoption widens.

To keep the number honest, the card only renders when both groups have at least five closed PRs. Below that threshold one or two unusually fast PRs would produce absurd ratios, so the card prefers to say "not enough data" rather than mislead.

Agent Contribution

This card focuses on the most autonomous form of AI: coding agents such as the Copilot agent, Devin 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 PRs that merged exactly as the agent opened them, with no follow-up commits, the closest thing to a "did it just work?" rate. 

Human intervention counts the opposite case: PRs where a person had to push corrections into the agent's branch before it could merge. 

Average iterations shows how many rounds a typical agent PR needs from opening to merge; 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.

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

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.

AI Contribution

While Activity Overview focuses on people, AI Contribution focuses on code. 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.

Lead Time

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 PRs 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 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 PR's creation, whichever came first) and ends the moment the PR is ready for review: for draft PRs that's when the draft flag is lifted, otherwise when the PR 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 PR up, the review rounds, and any back-and-forth in between all land here. 

Merge wait is the tail end: the PR 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 rather than any engineering problem.

In most organizations the surprise is that generation is the smallest slice and the human pipeline around the agent: review queues, merge delays 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.

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.