Written by: Mark Hull, Co-Founder and CEO, Exceeds AI | Last updated: July 21, 2026
Key Takeaways for AI-Era Engineering Metrics
- Quantitative engineering performance metrics convert Git, CI/CD, and incident data into signals such as cycle time, deployment frequency, and change failure rate so leaders can benchmark teams and justify investments with evidence.
- DX, LinearB, and Swarmia all rely on DORA metrics derived from metadata, but none can segment results by code provenance, because they do not read code diffs at the line level.
- AI tools compress coding time yet increase review time and technical debt. Platforms limited to metadata cannot attribute these shifts to AI-generated code, which hides true ROI and stability risk.
- Exceeds AI addresses these blind spots with Exceeds Ink, a provenance layer that writes line-level attestations into the repository, enabling commit-level AI impact tracking across tools like Cursor, Claude Code, and Copilot.
- Engineering leaders ready to move beyond metadata-only dashboards can start a free pilot with Exceeds AI to surface AI versus human outcomes in hours, not months.
Core Quantitative Metrics Engineering Leaders Track
Quantitative engineering performance metrics include deployment frequency, lead time for changes, change failure rate, mean time to recovery, cycle time, PR review time, code churn rate, defect density, complexity-adjusted throughput, and work in progress. Each metric converts engineering activity into comparable data points that help leaders benchmark teams, identify bottlenecks, and justify investment decisions with evidence rather than intuition.
How DX, LinearB, and Swarmia Handle DORA Metrics
All three platforms treat the four DORA keys, deployment frequency, lead time for changes, change failure rate, and MTTR, as their measurement backbone. Each ingests Git and CI/CD metadata to compute these signals without requiring access to code diffs.
LinearB focuses on git-centric DORA measurement paired with workflow automation. It surfaces PR cycle time breakdowns and integrates with issue trackers to connect delivery data to sprint planning. LinearB benchmarks report elite cycle time under 25 hours and median cycle time around 83 hours.
Swarmia combines Git, issue-tracker, and CI data with lightweight developer surveys to highlight team blockers and DORA metrics. Its primary value is surfacing delivery bottlenecks and encouraging developer engagement through Slack notifications.
DX (GetDX) supplements DORA delivery data with developer experience surveys and, through its AI Code Insights module, captures AI usage signals via a closed-source CLI. The DX Core 4 framework, developed in collaboration with DORA, SPACE, and DevEx authors including Dr. Nicole Forsgren and tested with over 300 organizations, places DORA metrics within Speed, Effectiveness, Quality, and Impact dimensions.
The shared limitation across all three is structural. When AI assistants and coding agents enter the SDLC, DORA velocity metrics inflate first while stability metrics degrade quietly, and none of these platforms can segment DORA results by code provenance, because none of them read code diffs at the line level.
Cycle Time Decomposition for AI-Heavy Teams
Cycle time is not a single number. It decomposes into at least four sequential phases, each with its own bottleneck profile.
- Coding time: From branch creation or first commit to PR open. AI tools compress this phase most aggressively, sometimes from hours to minutes.
- Pickup time: From PR open to first substantive review comment. PRs reviewed promptly are more likely to merge without rework.
- Review time: From first review comment to approval. Faros AI’s 2026 Acceleration Whiplash report, based on two years of telemetry from 22,000 developers across more than 4,000 teams, found median time in review up 441.5% under high AI adoption, and the incidents-to-PR ratio rose 242.7% as teams moved from low to high AI adoption.
- Deploy time: From merge to production. This phase is typically the most automatable and least affected by AI code volume.
These four phases matter because AI tools affect each one differently. The critical 2026 insight is that AI shortens coding time while lengthening review time. Review time increases by 91% in high AI adoption teams because human approval becomes the main constraint on delivery speed. Aggregate cycle time may appear flat or improved while the internal composition has shifted dramatically. DX, LinearB, and Swarmia can surface this shift at the phase level but cannot attribute it to AI versus human code without diff-level analysis.
Investment Allocation Metrics in an AI-Driven SDLC
Engineering investment allocation tracks how capacity is distributed across new features, bug fixes, maintenance, and technical debt remediation. The standard diagnostic ratio is the 40-20-40 rule. Teams target 40% new feature work, 20% rework, and 40% maintenance or operational work, and AI can accelerate all three simultaneously, which makes quarterly tracking essential to detect rising quality debt.
Healthy teams typically allocate 60–70% to features, 15–20% to bugs, and 15–20% to maintenance. When AI adoption is unmanaged, that balance shifts. LinearB’s 2026 Software Engineering Benchmarks Report, analyzing 8.1 million pull requests across 4,800 teams, found that technical debt increases 30–41% following AI tool adoption.
LinearB and Jellyfish both surface investment allocation through work-category tagging tied to issue trackers. Swarmia provides lighter-weight effort breakdowns. None of the three can attribute rising maintenance burden specifically to AI-generated code versus human-written code, because that attribution requires reading the diff.
These allocation shifts highlight why structured measurement programs matter. Organizations that track work categories and code provenance together can see when AI-driven feature velocity hides a growing maintenance burden and can rebalance capacity before technical debt compounds. Teams without this visibility often mistake AI-accelerated output for sustainable productivity.
Workflow Automation Strengths and Gaps
LinearB’s primary differentiator among the three is workflow automation. It offers automated PR routing, review assignment, and cycle time alerts that trigger based on configurable thresholds. These automations operate on metadata and do not require code access.
Swarmia focuses on Slack-based nudges and team habit formation. It surfaces blockers and encourages review participation through lightweight notifications rather than deep workflow integration.
DX emphasizes the developer experience layer, combining survey-driven friction identification with AI utilization tracking. Intercom doubled engineering throughput in nine months by standardizing on Claude Code while using DX to measure developer productivity.
All three platforms automate around the delivery pipeline. None automates around AI code quality, because none has the provenance data to distinguish which automated alerts should fire differently for AI-generated versus human-written changes.
AI Impact Metrics: The Gap DX, LinearB, and Swarmia Cannot Close
All three platforms share the same structural limitation. They read metadata from Git, CI/CD, and issue trackers, but they do not read code diffs at the line level and do not capture what happened on the developer’s machine during an AI coding session. This gap creates three specific blind spots that matter to every VP of Engineering justifying AI spend in 2026.
Commit-level AI versus human line attribution. Without AI attribution instrumentation at the IDE level, connecting an AI coding session to a PR and production outcome is structurally impossible because version control records only human commits. DX’s AI Code Insights module captures some AI usage signals via its closed-source CLI, but all attribution data lives in DX Data Cloud, nothing is written into the repository itself, and the capture mechanism is not auditable by a CISO. LinearB and Swarmia have no AI attribution capability at all.
30-day incident rates on AI-touched code. New Relic’s 2026 State of AI Coding report, surveying 200 U.S. technology decision-makers, found that 94% of leaders rate AI-generated code as higher quality than human-authored code at review time, yet 78% report more production incidents after deploying it. Tracking whether AI-touched code causes incidents at a higher rate than human-written code requires knowing which lines were AI-generated and then monitoring those specific lines longitudinally. As noted earlier, the Faros AI report documented both review time and incident rate increases under high AI adoption. DX, LinearB, and Swarmia can surface aggregate incident rates, but none can segment them by code provenance.
AI technical debt tracking. The empirical study “Debt Behind the AI Boom” analyzed 302,579 verified AI-generated commits across 6,299 GitHub repositories and identified 484,366 distinct technical issues introduced directly by five widely used coding assistants, with 22.7% surviving into production architectures. Heavy AI users experience 39% higher code churn, with refactoring-related moved code falling from 25% to less than 10% of changed lines. Measuring AI technical debt requires longitudinal outcome tracking anchored to per-commit AI attribution, which in turn requires both repo access and a provenance layer.
Exceeds AI closes this gap through Exceeds Ink, the on-machine provenance layer that writes a portable, line-level attestation alongside every commit as a Git Note. Every line carries its tool, model, session, interaction mode, and timestamp. That attestation feeds AI vs. Non-AI Outcome Analytics, which tracks immediate outcomes such as cycle time and review iterations and long-term outcomes such as incident rates 30 or more days later, follow-on edits, and test coverage for AI-touched versus human-written code across Cursor, Claude Code, Codex, GitHub Copilot, and Windsurf.
See how Exceeds Ink tracks AI impact in your codebase — start your free pilot now.
Decision Matrix: Matching Platforms to Team Profiles
The right platform choice depends on three variables: team size, AI maturity, and reporting requirements. For 50–200 engineers in early AI adoption who need a DORA baseline quickly, Swarmia or LinearB provide fast setup and solid DORA visibility, although these metadata-only platforms cannot segment results by code provenance.
Once a team reaches 200–1,000 engineers with active multi-tool AI adoption, that limitation becomes critical. Boards require ROI proof that metadata alone cannot provide, which is why Exceeds AI delivers commit-level AI attribution across Cursor, Claude Code, Codex, Copilot, and Windsurf with longitudinal outcome tracking and setup in hours.
For any size team where CFO-driven financial reporting on engineering spend is the priority, Jellyfish offers strong financial alignment. For teams prioritizing developer experience surveys as the primary signal, DX provides broad engineering intelligence with a strong compliance posture.
For 500 or more engineers with high security requirements who need auditable AI provenance in-repo, Exceeds AI with Exceeds Ink supplies Git Notes attestation that lives in your own repository along with HMAC-signed ingest and self-host options. For teams that primarily need traditional DORA without AI context, LinearB or Swarmia remain purpose-fit, while Exceeds AI is built for the AI era.
Discover your team’s fit in minutes — start your free pilot.
Implementation: Repo Access, Rollout, and Time-to-Value
Repo access is the central implementation variable. LinearB, Swarmia, and DX operate on metadata pulled from Git APIs, with no code diff access required, which simplifies security review but eliminates code-level AI attribution. DX’s AI Code Insights module adds a closed-source CLI that runs on developer machines, introducing a daemon-based operational footprint that security teams must evaluate on faith rather than inspectable code.
Time-to-value varies significantly across platforms, largely because of how they handle data ingestion and analysis depth. Swarmia and LinearB typically deliver initial dashboards within days because they pull metadata via API with minimal configuration. DX involves consulting-heavy onboarding measured in weeks to months due to its survey-driven methodology and custom framework alignment. Jellyfish commonly takes around 9 months to show ROI because its financial modeling requires cross-system integration and historical baseline establishment.
Exceeds AI delivers first insights within 60 minutes of GitHub OAuth authorization, complete historical analysis within 4 hours, and real-time updates within 5 minutes of new commits. Exceeds Ink installs as a lightweight Rust binary via standard Git hooks, with no long-lived daemon, no PATH-shimmed git binary, and no global git config mutation. Per-repo opt-in means security teams can scope the rollout precisely.
Rollout complexity scales with team size but not linearly. A 300-engineer organization can onboard Exceeds AI in a single day. The Exceeds Ink provenance layer installs on developer machines via a hook-direct model that fires only at commit time, which keeps the operational footprint minimal and the audit surface readable by any CISO in an afternoon.
Pricing structure also differs materially. LinearB and Jellyfish charge per contributor, creating a cost that scales with headcount. Exceeds AI charges per manager seat with no per-contributor data tax, and the Pro plan is $49 per manager per month at Early Partner Pricing, which aligns cost to the leaders who act on insights rather than penalizing teams for growing.
Frequently Asked Questions
Why do DORA metrics look misleading when AI coding tools are heavily adopted?
DORA metrics were designed for human-authored workflows. When AI tools generate 30–70% of committed code, deployment frequency and lead time improve for the wrong reasons, because AI produces boilerplate and scaffolding faster than humans can review it, which inflates velocity signals without corresponding quality gains. Change failure rate is the earliest honest signal of AI-related problems because stability failures from larger batch sizes and missed edge cases lag velocity improvements by 30–90 days. The 2025 DORA report found that higher AI adoption correlates with increases in both software delivery throughput and software delivery instability. To use DORA accurately in 2026, teams must segment all four keys by code provenance, human-authored, AI-assisted, and agent-authored, and add AI-specific counters for rework rate, review latency per cohort, and incident traceability to AI-authored changes. None of DX, LinearB, or Swarmia perform this segmentation automatically.
What is AI technical debt and how is it different from traditional technical debt?
AI technical debt is the hidden maintenance burden introduced when AI-generated code passes initial review but contains architectural misalignments, duplicated logic, or subtle correctness errors that only surface in production weeks or months later. It differs from traditional technical debt in two ways. It accumulates faster, because AI can generate thousands of lines before a morning standup, and it is less visible to the developer who committed it, because a human who writes a shortcut usually knows it is a shortcut, while AI-generated shortcuts are invisible to the reviewer. GitClear’s analysis of 211 million lines of code found that copy-pasted code rose between 2021 and 2024, while refactoring activity collapsed from 25% to under 10%. As the Investment Allocation section noted, technical debt can increase 30–41% following AI adoption, and the “Debt Behind the AI Boom” study found that 22.7% of AI-introduced issues survived into production architectures. Tracking AI technical debt requires longitudinal outcome monitoring anchored to per-commit AI attribution, which means knowing which specific lines were AI-generated and then watching whether those lines cause incidents, require rework, or degrade test coverage over 30, 60, and 90 days.
Can DX, LinearB, or Swarmia measure AI ROI for multi-tool teams using Cursor, Claude Code, and Copilot simultaneously?
No. LinearB and Swarmia have no AI attribution capability and cannot distinguish AI-generated from human-written code at any level. DX’s AI Code Insights module captures some AI usage signals, but its capture mechanism relies on a closed-source CLI daemon and filesystem heuristics as a fallback tier, signals that top out at roughly 20–25% accuracy for tools that do not expose native telemetry. All DX attribution data lives in DX Data Cloud rather than in your repository, which makes it non-portable and non-auditable by external parties. As discussed earlier, none of the three platforms can segment outcomes by code provenance, and this limitation extends to per-tool comparisons. They cannot distinguish Cursor versus Claude Code versus GitHub Copilot outcomes because they lack per-tool checkpoint materializers that resolve edit evidence at commit finalization. For teams running multiple AI tools simultaneously, which describes most engineering organizations in 2026, the only way to get aggregate AI ROI across the full toolchain is with a provenance layer that has dedicated adapters for each tool and writes portable attestations into the repository itself.
How should VPs of Engineering present AI ROI to a board that only trusts hard numbers?
Board-ready AI ROI requires connecting AI tool usage to business outcomes at the commit and PR level, not adoption statistics. Adoption statistics, such as percentage of developers using Copilot and acceptance rates, tell the board how many licenses are being used. They do not answer whether AI-touched code ships faster, breaks less often, or requires more rework than human-written code. The metrics that convert to board language are AI-attributed cycle time delta, 30-day incident rate on AI-touched versus human-written code, AI-driven change failure rate segmented by tool and interaction mode, and complexity-adjusted throughput comparing AI-assisted versus human-only work. These metrics require code-diff access and a provenance layer. Without them, leaders are presenting adoption proxies to a board that is increasingly asking for causation, not correlation. Many leaders expect to see AI impact within two years, yet few have seen a clear, measurable impact from AI investments to date, which creates a gap that metadata-only tools cannot close.
What security controls should engineering leaders require before granting repo access to any analytics platform?
The minimum security bar for repo access in 2026 includes read-only scoped access with no write permissions, no permanent source code storage, encryption at rest and in transit, LLM no-training guarantees on any code sent to AI providers, SSO or SAML support, audit logs, and a clear data residency option for regulated industries. For teams with higher security requirements, additional controls include an in-SCM deployment option where analysis runs inside your own infrastructure with no external data transfer, HMAC-signed ingest with revocable per-machine tokens, and an aggregate-only mode that keeps prompt content off the wire entirely. The operational footprint of any on-machine component matters as much as the cloud controls. A platform that installs a long-lived daemon, a PATH-shimmed git binary, or a global git config mutation creates attack surface and operational drag that security teams must evaluate separately from the SaaS data handling policies. Platforms whose capture code is inspectable by a CISO in an afternoon present a materially lower trust burden than closed-source alternatives.
Conclusion: Moving Beyond Metadata-Only Analytics
DX, LinearB, and Swarmia are well-built platforms for the problem they were designed to solve, which is measuring software delivery performance using metadata from Git, CI/CD, and issue trackers. In 2026, that problem remains necessary but no longer feels sufficient. AI coding tools have broken the underlying assumptions of every metadata-only framework, so DORA velocity metrics inflate, code churn accelerates, incident rates rise, and review time balloons while aggregate dashboards still show improvement.
The gap is not a feature gap. It is a category gap. Proving AI ROI, tracking AI technical debt, and segmenting outcomes by code provenance require reading the diff at the line level and knowing which tool, model, and interaction mode produced each line. That requirement calls for a provenance layer and a platform built to act on what that layer reveals.
Exceeds AI is the upgrade path for engineering leaders who have outgrown metadata-only analytics. Exceeds Ink writes a portable, auditable, line-level attestation alongside every commit. The Exceeds platform connects that attestation to cycle time, incident rates, rework patterns, and board-ready ROI reports across Cursor, Claude Code, Codex, GitHub Copilot, and Windsurf in hours, not months.