How do top tech companies measure agentic engineering?

What you're going to get out of this guide:         

A clear list of metrics that make sense for every stakeholder: from your CEO to your SREs and QA teams.

A framework for connecting engineering metrics to the business outcomes your C-suite actually uses to judge AI investments.

So, why do we need a measurement framework for agentic engineering?

Agentic engineering is moving fast. We're well past the stage of simple coding assistants, we're moving into an era where AI leads engineering workflows end to end, with humans providing oversight and judgment rather than executing every step. AI triages bug reports and resolves the straightforward ones. It detects a failing CI pipeline, diagnoses the root cause, and pushes a fix.

Your existing engineering metrics like DORA still work. Deployment frequency is deployment frequency regardless of who wrote the code. A production bug is a production bug. DORA doesn't care about the author.

But agents introduce three blind spots those metrics weren't designed for:

The cost model is fundamentally different. A human engineer costs you a salary whether they ship 5 PRs or 50. An agent costs you per attempt, tokens, API calls, or according to compute. When an agent fails a task, it retries. Sometimes 8 times. Each retry costs money. Traditional engineering metrics have no concept of "cost per successful task" because you never paid per-attempt for a human. Without tracking this, you can have an agent that looks productive on DORA dashboards while quietly burning $40K/month in failed retries.

Throughput metrics can now be inflated in ways that weren't possible before. A human engineer doesn't split one logical change into 10 micro-PRs because it would be more work, not less. An agent does this naturally. Suddenly your PR throughput goes up 10×. Your deployment frequency doubles. Your DORA dashboard looks incredible. But the actual value delivered hasn't changed. You need counterweights like code churn rate and rework rate. The old metrics aren’t wrong, but agents have created new ways to look productive without being productive.

There's a new category of engineering work that didn't exist before: governing the AI. Your engineers now spend hours reviewing AI-generated PRs, fixing AI-generated bugs, and maintaining agent workflows. If you don't track that time, you can't answer the most basic question: is the AI making us faster, or just replacing old work with new work?

The reason is straightforward. Productivity and throughput are not the metrics your C-suite uses to assess business impact. As competitors adopt the same AI coding assistants, productivity gains are quickly commoditized. Coding faster no longer provides a durable competitive advantage. Your CFO and board care about revenue growth, customer lifetime value, risk reduction, and strategic capability. If you can't connect your engineering metrics to those outcomes, someone else will take over the conversation.

This framework doesn't replace your existing metrics. It closes the blind spots that agents create around cost, inflated throughput, and hidden human overhead. And it connects your engineering data to the business outcomes that determine whether your AI investments keep getting funded.

The metrics library

Six categories, each building on the last. Start with the ones that match your maturity. The detailed how-to for each metric follows in the second half of this guide.

The metric library

Each metric includes a definition, how to measure it, and a common trap. The table above maps each metric to its category and audience.

Time to market

Three numbers your board needs. Feature lead time proves speed. Release frequency shows throughput. Output per engineer proves efficiency. But here's what makes these numbers matter to your C-suite: they are proxies for revenue velocity. Feature lead time doesn't just tell you how fast your team ships, it tells your board how quickly the organization pulls revenue forward. Release frequency doesn't just show throughput, it shows that your team has a repeatable engine for delivering customer value. If you present these without connecting them to the business outcome they serve, you're reporting engineering metrics that stay in the engineering silo.

1. Feature lead time

Total elapsed days from feature request to live in production. Start counting when the ticket is created and stop when the code is deployed. This is the single number that tells your board whether AI is actually accelerating delivery. It proves you're getting value to customers faster, not just generating more code.

Set up stage gates in your project tool (Jira, Linear, Shortcut): ticket created → work started → PR opened → review done → staging → production. Enable automatic timestamps on each transition. Pull a monthly report: median elapsed days from first gate to last gate. Segment AI-led tickets vs. human-led tickets. Track the median, not the average. One slow ticket won't skew the whole number.

⚠ Anti-patterns: Measuring only commit-to-merge misses the real story. 60–80% of lead time is waiting: for review, for QA, for approval. Track the full cycle or you'll optimize the wrong thing.

2. Release frequency

Production releases per week that deliver new value to users. This excludes rollbacks, config changes, and feature flag flips. Frequency proves your team can ship continuously. It separates teams that deliver one thing quickly from teams that have a repeatable engine.

Tag each deploy in your CI/CD pipeline with a type: new-release, rollback, config-change, or flag-flip. Most CI tools support custom labels. Count only new-release deployments per week. Compare the 4-week rolling average before AI adoption vs. current.

⚠ Anti-patterns: Inflated counts. If agents split one logical change into 10 micro-PRs, your deploy count goes up 10× but actual value delivered stays the same. Pair with output per engineer.

3. Output per engineer

High-complexity deliverables completed per senior engineer per quarter. This connects AI investment to headcount efficiency. Your CFO and board use this number to decide if agentic engineering scales output or just scales cost.

The key distinction: don't just count features or epics. AI makes simple work trivial, so the interesting question is whether it's enabling harder work, not just more work. Track the number of high-complexity, net-new deliverables per senior engineer: complex decision automation, cross-system orchestration, capabilities that remove bottlenecks tied to specialist knowledge. This proves to your technology and product leadership that AI is acting as a skills magnifier, freeing capacity for higher-order product innovation rather than just routine operational work.

Segment: how many were AI-assisted vs. fully human? This shows where AI contributes most. Report to the board alongside headcount: "output up X% with Y% headcount growth."

⚠ Anti-patterns: Showing output without code churn rate. If output rises 60% but most of that code gets rewritten within two weeks, the gain is an illusion. Always present both numbers together. And showing output without complexity weighting. 50 dependency bumps is not the same as 5 new capabilities.

Return on investment

Three metrics that build your CFO's picture. From unit economics of a single AI task to aggregate hours reclaimed to the ultimate question: are validated business outcomes growing faster than AI costs?

4. Cost per successful task

Total cost to get one AI task done correctly. This includes failed attempts and any human cleanup. This is the unit economics of agentic engineering. It tells you if AI is cheaper than the human alternative after counting failures.

The core principle: don't divide total spend by total attempts, divide by successful attempts. If 30% of attempts fail and each costs $2, your real cost per completed task is ~$2.85, not $2. The difference compounds at scale.

How to measure it: Set up an observability layer to log every agent API call: tokens used, model, and outcome (success/failure). For each task type (code review, bug fix, test generation), add up all spend across all attempts, including the ones that failed. Divide by the number of tasks that actually succeeded. Track which model handles which tasks. 60–80% of routine requests can run on smaller, cheaper models without quality loss.

This metric is also your early warning for value drift. Changes in usage patterns, scale, or pricing can quietly undermine ROI over time. If cost per successful task is rising month over month while the task mix hasn't changed, your economics are eroding, investigate before it compounds.

5. Engineering hours reclaimed

Hours per month that AI now handles instead of a human. It also tracks what those freed hours produce. Reclaimed hours only count as ROI if they produce something valuable. This metric forces you to track real leverage instead of an illusion of savings.

List every task type your AI agents handle (code review, bug triage, test writing, dependency updates, docs). From your project tool, pull the average human time per task before AI adoption. Multiply: AI-completed tasks this month × historical human time. Apply a conservative discount of 20–40% because humans still review, govern, and handle edge cases.

Track where the freed time goes. Tag the replacement work in your project tool: new features, architecture improvements, or operational overhead.

The highest-return capacity redirects are those where AI fundamentally alters what the organization can deliver, not just how quickly it delivers. Focus freed capacity on work that was previously too slow or economically infeasible to justify, systems that constrain future innovation if left unchanged, or new capabilities that directly create growth or resilience. If freed hours get absorbed back into backlogs, maintenance, or incremental delivery, the savings vanish.

⚠ Anti-patterns: Three traps. First: claiming 100% of the time is saved (realistic: 60–80% after accounting for oversight). Second: not tracking what the freed hours produce, 500 hours per month redirected into meetings is not a productivity gain. Third: letting freed capacity be absorbed back into existing work. Without deliberate redirection, AI-freed time disappears into the backlog and you can't prove ROI to anyone.

6. Value validation ratio

The ratio of validated business outcomes enabled by AI to the total cost of delivering and operating those AI capabilities. This is the metric that connects engineering investment to the business outcomes your C-suite uses to judge AI investments.

How to measure it: Identify the business outcome each AI initiative is expected to influence, revenue growth, customer retention, risk reduction, time to market, strategic capability. Track the realized outcome (actual cost savings, avoided risk exposure, attributable revenue influence) and divide by the total cost of delivering and operating that capability (token consumption, API usage, compute, operational overhead, human oversight time).

This is not a metric you instrument on day one. It requires alignment with product, finance, and business leaders on what counts as a validated outcome. But it's the metric that determines whether your AI budget grows or gets reallocated.

⚠ Anti-patterns: Measuring this in isolation from your engineering metrics. Value validation ratio without cost per successful task and engineering hours reclaimed gives you a number with no diagnostic power. When the ratio drops, you need the underlying metrics to tell you whether costs are rising, outcomes are shrinking, or both.

Velocity and throughput

All four DORA metrics plus two agentic-specific signals. Google's DORA 2025 found AI improves throughput 2–18% but often decreases stability.

7. Deployment frequency

DORA metric for how often you successfully release to production per week. This is the baseline heartbeat of your delivery engine. If AI isn't increasing this number, the throughput gains are getting stuck in the pipeline.

Count successful production deployments per week from your CI/CD tool. Exclude staging, preview, and canary deployments. Tag each deploy: AI-initiated (agent opened the PR and triggered deploy) vs. human-initiated. The "% AI-initiated" sub-metric tracks your agentic maturity over time.

⚠ Anti-patterns: Counting staging deploys or feature-flag flips as production releases. Only code reaching real users counts for DORA.

8. Lead time for changes

DORA metric for time from code commit to that code running in production. Agents can write code in minutes. This metric reveals where the bottleneck actually is. It shows if speed gains evaporate in a review queue.

Capture timestamps at each CI/CD stage: commit → build start → tests pass → review approved → deploy complete. Split into two numbers: execution time (build + test + deploy) vs. wait time (sitting in review queue, waiting for approval, waiting for a deploy slot). Report the median of each.

⚠ Anti-patterns: A single lead-time number hides where to invest. 2 hours execution + 10 hours review wait = fix your review process. 11 hours execution + 1 hour wait = invest in faster CI. The split tells you which.

9. Change failure rate

DORA metric for the percentage of production deploys that cause a failure requiring action. Speed without stability is reckless. This metric catches stability tradeoffs before your customers do.

Formula: (failed deploys ÷ total deploys) × 100. Write down your definition of "failure" and share it with the team so everyone counts the same way. Segment by code origin: AI-authored PRs vs. human-authored PRs. Compare rates. If AI code fails more often, investigate your review and testing process for AI-generated changes.

⚠ Anti-patterns: Excluding fast rollbacks from the count. A deploy that fails and rolls back in 30 seconds still shipped broken code to production. Count it.

10. Mean time to recovery

DORA metric for time from incident detection to service restoration. Recovery speed determines the real cost of failure. AI auto-resolving routine incidents protects your deployment frequency and customer trust.

Measure from alert-fired timestamp to service-restored timestamp. Report P50 (typical), P90 (bad day), and P99 (worst case), not just the average. Segment by resolution method: AI-auto-resolved (zero humans involved), AI-assisted (agent helped, human deployed the fix), human-only. Track auto-resolution rate monthly.

⚠ Anti-patterns: Reporting only the average. If 95 incidents resolve in 5 minutes (AI) and 5 take 8 hours (human), the average is 29 minutes, looks great. But P99 is 8 hours. Always report the distribution.

11. PR throughput

Merged pull requests per engineer per week. Always report this alongside median PR size. This is the most direct measure of how much code your team is shipping. It separates genuine gains from agents gaming the number with micro-PRs.

Count merged PRs per engineer per week from your git hosting platform. Segment AI-authored vs. human-authored. Calculate median PR size in lines changed alongside throughput. A useful composite: total lines merged per engineer per week.

⚠ Anti-patterns: Throughput without size is misleading. If agents split one change into 10 micro-PRs, throughput looks 10× higher with identical actual output. Always show both numbers.

12. Code churn rate

Percentage of new code that doesn't survive two weeks. This is the single most important hidden cost metric. High churn means your team is moving fast but building on sand. It tells productive velocity apart from busy velocity.

If your PR throughput is up 3× but churn is up 8×, your team is writing code that gets thrown away. Ask your platform team to run a rolling 2-week analysis: how much code written in week 1 gets deleted or substantially rewritten by the end of week 2?

Run a git log analysis over rolling 14-day windows: count lines added, then count how many of those same lines were deleted or replaced within the window. Formula: (churned lines ÷ total lines written) × 100. Segment by author: AI-generated commits vs. human commits. Track weekly.

⚠ Anti-patterns: Ignoring this metric because deploy frequency and PR throughput look strong. If PRs are up 3× but churn is up 8×, the productivity gain is an illusion.

13. Rework rate

Percentage of merged PRs that need a follow-up fix within 7 days. Rework is velocity in reverse. It signals that your review process for AI code needs tightening.

For each merged PR, check git history: were any subsequent commits to the same files within 7 days tagged as a bug fix, hotfix, or regression fix? (Use commit message conventions or PR labels to identify fixes vs. planned work on the same file.) Formula: (PRs followed by a fix ÷ total merged PRs) × 100. Segment AI-authored vs. human-authored. Supplement with a sprint retro question: "How much time did you spend this sprint fixing AI-generated code? None / Some / A lot."

⚠ Anti-patterns: Choosing the wrong time window. 2 days is too short (misses bugs found in staging). 30 days is too long (captures unrelated work on the same files). 7 days is the practical default.

Quality

These metrics answer the question: is the AI output actually good? Agent success rate is the gold standard, paired with acceptance rate, escalation rate, and the Developer Experience Index. Anthropic's data: agent success rates drop 18–31% from benchmarks to production.

14. Agent success rate (ASR)

How often AI agents complete tasks correctly. Success is measured by the outcome, not by how the output looks. This is the most honest measure of whether your agents are production-ready. It asks if the agent actually did the job.

Prefer objective verification over human scoring. Most agent tasks have a testable outcome, a pipeline that passes, a vulnerability that disappears from the next scan, a test suite that goes green. Use those signals first. Fall back to human review only for tasks where the outcome can't be verified automatically (architecture decisions, documentation quality, complex refactors).

For each agent task type, define what "success" means in terms the system can verify. The definition should be specific and binary where possible: did the fix work, or didn't it? Formula: (tasks that met the success criteria ÷ total tasks attempted) × 100. Segment by task type, an agent that scores 90% on dependency bumps and 40% on incident remediation needs very different attention than one that scores 65% across the board.

For tasks that require human judgment, use a simple 3-point scale: Succeeded (no rework needed), Partial (usable but needed meaningful edits), Failed (had to redo from scratch or caused damage). Monthly sampling of 50+ tasks is enough to track trends.

Example 1: Incident fix success

An agent is assigned to solve a memory leak in a Java service via a PagerDuty alert, diagnoses the root cause, writes a fix, and opens a PR. Success criteria (all must be true): the CI pipeline passes on the agent's PR; the specific alert that triggered the task does not re-fire within 24 hours after the fix is deployed; no new P1/P2 incidents are traced back to the agent's change within 7 days. If any condition fails, CI breaks, the alert re-fires, or the fix introduces a regression, the task counts as a failure, even if the agent's diagnosis was correct.

Example 2: Vulnerability fix success

A SAST scanner flags a SQL injection vulnerability in a PR. An agent picks up the finding, writes a remediation patch, and opens a follow-up PR. Success criteria (all must be true): the same SAST scanner runs on the agent's PR and the original finding no longer appears; no new vulnerabilities of equal or higher severity are introduced by the patch; the existing test suite passes. If the agent's patch silences the scanner but introduces a new high-severity finding, the task counts as a failure.

⚠ Anti-patterns: Relying only on human scoring when objective signals exist. If you can verify an outcome with a test, a scanner, or an alert, use that. Human reviews are expensive, inconsistent, and don't scale.

15. AI output acceptance rate

Percentage of AI-generated pull requests that human reviewers accept without major rework. This quality signal is closest to the developer's daily experience. If reviewers keep rejecting PRs, the tool is creating work instead of saving it.

For every AI-generated PR, log the review outcome: accepted as-is, accepted with minor edits (cosmetic, naming, formatting), required major rework (logic, architecture, security changes), or rejected. Acceptance rate = (as-is + minor edits) ÷ total. Write a short rubric defining "minor" vs. "major" and share it with all reviewers before you start measuring.

⚠ Anti-patterns: No shared rubric. Without one, reviewers classify inconsistently, one calls a variable rename "major," another calls a logic rewrite "minor." The data becomes meaningless. Write the rubric first.

16. Escalation rate

Percentage of agent tasks that require a human to step in and take over. This defines the boundary of what your agents can handle autonomously. Tracking it shows if your agentic maturity is expanding over time.

Log every point where a human intervenes in an agentic workflow: PR review overrides, deploy approvals, incident responses. Formula: (escalated tasks ÷ total tasks) × 100. Healthy range: 10–20% for complex work, under 5% for routine tasks. If the rate drops below 5% across all task types, add random spot-check reviews.

⚠ Anti-patterns: Celebrating 0% escalation. Zero means nobody is actually reviewing AI output, that's rubber-stamping, not trust.

17. Defect escape rate

Production bugs per release. This compares releases that contain AI-generated code vs. those that don't. This is where AI quality hits your customers. It shows if your testing process has caught up with your code generation speed.

When a production bug is reported, trace it to the release that introduced it. Check whether that release included AI-authored PRs (use your AI/human PR tagging from metric 11). Calculate: bugs per release for AI-inclusive releases vs. human-only releases. Track monthly. A simpler alternative: bugs per 100 PRs, segmented by author type.

⚠ Anti-patterns: Blaming AI for bugs in adjacent code. A dependency update that exposes a pre-existing issue is a testing gap, not an AI quality failure. Trace bugs to specific PRs, not just to "releases that had AI code."

18. Developer experience index (DXI)

A quarterly survey measuring how developers experience AI-assisted workflows. It tracks trust, focus time, and rework burden. System metrics tell you what is happening. Sentiment tells you if the team trusts it. DXI prevents credibility problems that stall adoption.

Run a quarterly anonymous survey, 5–10 questions, under 10 minutes. Key questions: "I'm confident in the quality of AI-generated code I review" (1–5). "How much of your time goes to fixing AI-generated output?" (None / Some / A lot). "How easy or difficult is it to get your work done?" (1–5). Add an AI Tool NPS: "How likely are you to recommend our AI tooling to a colleague?" (0–10). Track quarterly. Always pair survey results with system metrics from this guide.

⚠ Anti-patterns: Trusting survey data alone. Studies show developers consistently report feeling faster with AI while objective measurement shows mixed results on complex tasks. Survey data tells you how people feel. System metrics tell you what's actually happening. When they diverge, investigate.

Manual engineering signals

Where to point the AI next. These metrics surface tasks that are still done manually, ranked by frequency and cost. Shopify's engineering blog: "The toil that humans correctly deprioritize turns out to be the perfect workload for an autonomous loop."

19. Automation coverage by SDLC phase

The percentage of recurring tasks handled by AI vs. manual work in each SDLC phase. This is your automation roadmap. It shows which phases are still human-heavy. You can then invest in agents where the gap is biggest.

With your engineering leads, list every recurring task per phase. Takes 2–3 hours in a room. Classify each: fully automated (AI does it end to end), AI-assisted (AI does the bulk, human reviews), or fully manual. Calculate the automation percentage per phase. Revisit quarterly as you roll out new capabilities.

⚠ Anti-patterns: Classifying "AI-assisted but mostly human" as "automated." If a human does 80% of the work, that's human-led. Be honest, the goal is finding real gaps to fill, not painting a rosy picture.

20. Manual toil hours per team per sprint

Hours each team spends on repetitive, automatable tasks per sprint. Toil hours are the raw material for AI ROI. Every hour of reported manual work is a concrete automation opportunity with measurable results.

Add two questions to your sprint retro or a quick Slack poll: (1) "How many hours did you spend on repetitive manual work this sprint?" (0–2 / 2–5 / 5–10 / 10+). (2) "What was the most automatable task you did this sprint?" (open text). Aggregate by team. Rank by toil hours. The open-text answers are your automation priority queue, engineers will tell you exactly what to automate.

⚠ Anti-patterns: Surveying once and calling it done. Toil shifts as services change. Measure every sprint. And act on results, if the same task appears 8 sprints in a row without being automated, the team stops responding.

21. Ticket touch count

Number of human interactions needed to close a ticket. High-touch tickets on routine work are process friction in plain sight. Shifting these toward zero-touch is the clearest path to AI-led workflows.

Pull the activity log for closed tickets from your project tool (Jira, Linear, and Shortcut all track this natively). Count distinct human actions per ticket. Classify tickets: zero-touch (AI resolved end to end), low-touch (1–2 human interactions), standard (3–5), high-touch (6+). Track the distribution monthly. Goal: shift routine work toward zero-touch.

⚠ Anti-patterns: Treating all tickets the same. A complex architecture decision that needs 15 human touches is working as intended. A dependency bump that needs 8 touches is a process problem. Segment by complexity before drawing conclusions.

22. Manual CI/CD intervention rate

Percentage of pipeline runs where a human had to intervene. Every manual retry or approval slows delivery. This metric shows how close your pipeline is to being fully autonomous.

Use your CI/CD audit logs to count human actions during pipeline runs: manual retries, manual approvals, manual config edits, manual test validation. Formula: (runs with at least one human action ÷ total runs) × 100. Break down by intervention type. Target: below 5% for your core deploy pipeline.

⚠ Anti-patterns: Automating away gates that exist for good reasons. Security review checkpoints and compliance gates should stay manual. Auto-approve on a security checkpoint gone wrong causes far more damage than the time you saved.

23. Repeat incident rate

Percentage of production incidents that recur within 90 days with the same root cause pattern. Recurring incidents are high-value automation targets. An agent can learn to prevent or auto-resolve these patterns.

Tag each incident with a specific root cause category (e.g., "memory leak in Java services," not just "infra"). Track whether the same category appears again within 90 days. In every post-mortem, require a concrete "automation action": what specific automation will prevent or auto-resolve this if it recurs? Track whether those actions actually get completed.

⚠ Anti-patterns: Defining "repeat" too narrowly. A memory leak in Service A and a memory leak in Service B are the same pattern. Track root cause categories, not exact incident fingerprints.

24. Capacity allocation ratio

How engineering time splits across features, bug fixes, maintenance, and overhead. This is the bottom-line question for agentic engineering. It shows if AI is shifting the team toward building new value or just new toil.

Tag all tickets in your project tool with one of four types: Feature, Bug Fix, Maintenance, Ops Overhead. Pull the distribution monthly. For untracked work, run a monthly 2-minute survey: "Estimate what percentage of your time this month went to each bucket" (slider to 100%). Ticket tagging catches tracked work, the survey catches everything else.

⚠ Anti-patterns: Not measuring this at all. Without it, you can't answer the most important question: is AI actually freeing the team to build more features, or just replacing old toil with new toil (reviewing AI output, fixing AI bugs, maintaining agent workflows)?

Platform efficiency

One metric that tracks whether your AI platform is scaling efficiently or rebuilding from scratch every time.

25. AI artifact reuse rate

The proportion of AI initiatives that reuse standardized platform components, shared model access, prompt patterns, evaluation pipelines, agent frameworks, rather than building from scratch. High reuse means your marginal cost, risk, and delivery time drops with each additional AI use case. Low reuse means every new initiative carries the full cost of the first one.

Track the percentage of new AI initiatives that consume shared platform components vs. those that build custom infrastructure. Audit quarterly. If reuse is below 50%, your platform team has a prioritization signal: the shared components either don't exist, aren't discoverable, or don't meet teams' needs.

⚠ Anti-patterns: Measuring reuse without measuring whether the shared components actually work. A shared prompt pattern that every team uses but nobody trusts is worse than custom implementations. Pair reuse rate with the quality metrics from category 4.

Connecting engineering metrics to business outcomes

Here's a pattern we see constantly: an engineering leader builds a solid measurement practice, shows a dashboard full of green metrics, deployment frequency up, lead time down, AI acceptance rate at 80%, and the CFO asks: "So what? How does this affect revenue?"

The engineering leader doesn't have an answer. Not because the data isn't there, but because nobody drew the line between the engineering numbers and the business numbers.

This is where most measurement frameworks stop, and it's why engineering teams keep losing the AI budget conversation. Your board doesn't think in deployment frequency. They think in four categories: are we spending sustainably, are we growing revenue, are we building capabilities we couldn't build before, and are we managing risk. Every metric in this guide maps to one of those categories. But if you don't make the mapping explicit, your C-suite will fill in the blanks themselves, usually with less favorable assumptions.

"Is this sustainable?" is the cost question. Cost per successful task (#4), engineering hours reclaimed (#5), and AI artifact reuse rate (#25) answer it directly. They prove that your AI economics work at current scale and won't break at 3× scale. If your cost per successful task is flat or declining while task volume grows, you have a defensible cost story.

"Is this making us money?" is the revenue question. Feature lead time (#1) and release frequency (#2) answer it, but only if you connect them to something the business cares about. "Lead time dropped from 14 days to 9 days" means nothing in a board deck. "We shipped the pricing tier feature 5 days faster, which pulled forward $X in Q3 revenue" means everything. Value validation ratio (#6) forces this connection by tracking whether the business outcomes AI was supposed to influence actually materialized.

"Can we do things we couldn't do before?" is the capability question. This is where most engineering teams undersell themselves. Output per engineer (#3), especially when measured by complexity rather than volume, shows that AI is letting senior engineers tackle work that was previously too slow or too expensive to justify. Automation coverage (#19) and capacity allocation ratio (#24) show whether the team's time is actually shifting toward new capabilities or just cycling faster through the same backlog.

"Are we in control?" is the risk question. Change failure rate (#9), mean time to recovery (#10), defect escape rate (#17), and escalation rate (#16) answer it. They prove that your AI-assisted deployments are stable, that incidents get caught and resolved, and that humans are still in the loop where it matters. For your CISO and your board's risk committee, this is the category that determines whether agentic engineering gets expanded or frozen.

When you present to your board, don't show 25 metrics. Pick the one from each category that tells the clearest story for what the business is focused on right now. If this quarter is about growth, lead with feature lead time and value validation ratio. If it's about proving efficiency, lead with cost per successful task and engineering hours reclaimed. The engineering detail, the DORA numbers, the churn rates, the acceptance rates, lives one click behind for anyone who wants to drill in. But the top-level story should always be in the language your CFO already uses.

The teams that get this right don't just keep their AI budgets. They're the ones who get asked to expand.

Where should you start?

Pick 5 metrics, not 25.

Start with one from each category. Here's a proven starter set:

These five are measurable with tools most teams already have, they cover every stakeholder from board to IC, and none of them require specialized agentic tooling.

Three rules to make metrics stick:

Every metric needs an owner who checks it. Not someone who "has access to the dashboard", someone who reviews the number weekly and takes action when it moves. If nobody loses sleep when a metric goes red, it's not a real metric.

Make the data accessible, not buried. A monthly PDF that nobody opens is worse than no dashboard at all. Put your starter metrics somewhere your stakeholders already look: the board deck, the engineering all-hands slide, the sprint retro template.

Expand only after the first five are producing consistent data. If you've been measuring your starter set for two months and someone is actually reviewing the numbers, add the next tier: cost per successful task (#4), PR throughput (#11), escalation rate (#16), automation coverage (#19), and value validation ratio (#6). If your starter metrics are still inconsistent or unreviewed after two months, adding more won't help, fix the process first.

What "good" looks like:

You can answer these questions with real data:

How much faster are we shipping with AI? Is the AI output actually good enough, or are we spending time fixing it? Where are the biggest manual bottlenecks left? Are validated business outcomes growing faster than AI costs?

If you can answer all four, you're ahead of most engineering organizations, and you have the foundation to scale measurement as your agentic capabilities grow. If you can only answer the first three, you have strong engineering metrics but you're vulnerable to the ROI conversation shifting to someone else's terms. Add value validation ratio and the business outcome connection, and you own the full story.