Written by: Mark Hull, Co-Founder and CEO, Exceeds AI
Key Takeaways
- LinearB measures cycle time as the average duration from first commit to production deployment across four phases: Coding, Pickup, Review, and Deploy.
- Elite teams reach total cycle times under 25 hours in the 2026 benchmarks, with AI-generated PRs showing faster reviews but longer pickup delays and lower acceptance rates.
- LinearB excels at spotting bottlenecks but lacks code-level visibility to separate AI-driven improvements from human-driven improvements.
- Key gaps include AI attribution, hidden quality risk, fragmented multi-tool usage, and untracked verification overhead from AI-generated code.
- Upgrading to Exceeds AI adds code-level AI observability, concrete ROI proof, and fast insights through a simple repo connection.
Executive Overview: LinearB Cycle Time’s Role in 2026 Engineering
LinearB cycle time acts as a practical proxy for DORA’s Lead Time for Changes, tying development speed directly to business outcomes. Elite teams now complete work in under 25 hours from first commit to production, which shows how much productivity improves with streamlined workflows. The stakes are higher in 2026 as AI-generated PRs wait 5.25 times longer for pickup but take 194 minutes to review compared to 252 minutes for manual PRs (1.3 times faster) once review begins.
LinearB cycle time helps teams find bottlenecks across the pipeline, from initial coding through deployment. Teams use these insights to tighten review processes, cut pickup delays, and improve deployment reliability. The metric still falls short for AI ROI proof because it cannot show which parts of the work came from AI tools and which came from human developers.
How LinearB Breaks Cycle Time into Four Phases
LinearB breaks cycle time into four sequential phases, each with specific elite performance targets.
Coding Time: This phase covers the work from the first commit to PR creation, as defined in the LinearB 2026 Benchmarks. It reflects how quickly developers move from starting work to opening a reviewable PR.
Pickup Time: This phase measures how long a PR waits for the first review, with an elite target of less than 1 hour according to the 2026 Benchmarks. It highlights reviewer responsiveness and workload balance.
Review Time: This phase tracks the duration from the first review to merge approval, again defined in the 2026 Benchmarks. It reflects review depth, PR size, and collaboration patterns.
Deploy Time: This final phase runs from merge to production deployment, as captured in the 2026 Benchmarks. It surfaces issues in CI/CD pipelines and release practices.
This step-by-step breakdown helps teams see exactly where time accumulates. Leaders can tell whether delays come from initial development, reviewer availability, review rigor, or deployment automation.
LinearB measures these phases through Git events and deployment integrations, automatically tracking timestamps across the development pipeline. The tool excludes draft pull requests from Cycle Time calculations and uses configurable aggregation methods to keep team-level reporting consistent.
LinearB Cycle Time Formula and Calculation Details
LinearB calculates cycle time as production deployment timestamp minus coding start timestamp, using the first commit or Jira In Progress as the start, with aggregation options such as AVG, P50, P75, or P90. This approach gives a balanced view of performance without letting extreme outliers distort the picture.
The calculation process follows a clear sequence:
- Identify first commit: LinearB records the initial commit timestamp for each feature branch.
- Track phase transitions: The system monitors PR creation, first review, merge approval, and production deployment.
- Aggregate values: LinearB applies the chosen aggregation method across all completed work items in the selected time window.
For example, PR #1523 with a first commit at T0 and production deployment at T+36 hours contributes 36 hours to the cycle time calculation. When LinearB aggregates many PRs, the p75 value shows the duration below which 75 percent of work items finish.
LinearB Cycle Time Benchmarks and p75 Targets
Knowing how to calculate cycle time only becomes useful when teams understand what “good” looks like. LinearB’s 2026 benchmarks, based on 4,800 engineering teams and 8.1 million pull requests, define performance tiers across the cycle time phases.
Elite: Total Cycle Time under 25 hours, with fast Coding Time from first commit to PR creation, Pickup Time under 1 hour, focused Review Time from first review to merge approval, and streamlined Deploy Time from merge to production deployment.
Good: Total Cycle Time between 25 and 72 hours, Coding Time between 54 minutes and 4 hours, Pickup Time between 1 and 4 hours, and Review Time between 3 and 14 hours.
Fair: Total Cycle Time between 73 and 161 hours, Coding Time between 5 and 23 hours, Pickup Time between 5 and 16 hours, and Review Time between 15 and 24 hours.
Needs Focus: Total Cycle Time above 161 hours, Coding Time above 23 hours, Pickup Time above 16 hours, and Review Time above 24 hours.
These benchmarks reflect meaningful gains over previous years, with the elite threshold dropping to the sub-25-hour mark. The data also exposes the acceptance rate gap mentioned earlier, which suggests that faster AI-assisted review times may come with a quality tradeoff. Connect my repo and start my free pilot to see how AI affects your team’s specific cycle time profile.
Strategic Limits of LinearB Cycle Time for AI-Heavy Teams
These benchmark insights highlight a core problem for AI-augmented teams. LinearB can show that cycle time changes, but it cannot explain what drives those changes inside AI-heavy workflows.
This measurement gap stems from LinearB’s metadata-based approach, which cannot see AI’s impact at the code level. The platform cannot tell whether improvements come from AI assistance or from process tuning by humans, which blocks clear AI ROI proof and hides AI-specific risks.
Several critical limitations emerge.
AI Attribution Gap: LinearB tracks PR timestamps but cannot see which lines of code came from AI tools versus human developers. With 41 percent of code now AI-generated, this blind spot prevents accurate ROI measurement.
Quality Risk Invisibility: AI PRs show 32.7 percent acceptance rates, which signals heavy rework that cycle time alone cannot isolate or track over time.
Multi-Tool Chaos: Teams often use Cursor, Claude Code, GitHub Copilot, and other AI tools at once. LinearB cannot compare how each tool affects cycle time or quality.
Verification Tax: DORA research calls out “verification overhead” as a universal AI pattern, where teams spend saved coding time on auditing AI output. Traditional cycle time metrics do not surface this tradeoff.
Upgrade to Exceeds AI for Code-Level AI Insight
Exceeds AI extends LinearB’s metadata view with code-level AI observability. LinearB shows that cycle times changed. Exceeds AI shows whether AI caused those changes and what that meant for quality.
AI Usage Diff Mapping analyzes commit and PR diffs to separate AI-generated code from human-written code across tools such as Cursor, Claude Code, GitHub Copilot, and others. This view lets teams attribute cycle time shifts directly to AI contributions.
AI vs Non-AI Outcome Analytics tracks both near-term metrics, 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. Teams see the real cost behind faster completion times, including the rework patterns that show up in acceptance rates, which delivers complete ROI visibility.
Longitudinal Tracking monitors AI-touched code over extended periods to uncover technical debt patterns that appear after the initial review. This capability matters as AI-assisted coding can increase static analysis warnings and code complexity.
Exceeds AI also shortens the path to value. It delivers insights within hours through simple GitHub authorization, while LinearB often needs weeks of setup and configuration. Exceeds AI works at repo level instead of relying on metadata, so managers can see not just what happened, but why it happened and what action to take next.
Former engineering leaders from Meta, LinkedIn, and GoodRx built Exceeds AI to solve the AI ROI questions they faced with their own boards. The platform supports teams from 50 to 1,000 engineers with outcome-based pricing that does not punish growth. Connect my repo and start my free pilot to experience code-level AI observability.
Checklist: Diagnose Your Cycle Time Bottlenecks
Use this checklist to spot your biggest cycle time opportunities.
- Total cycle time above 25 hours? Focus on the longest phase first, often Review or Deploy.
- Pickup time above 1 hour? Add reviewer assignment automation or rebalance workloads.
- Review time above 3 hours? Encourage smaller PRs or add reviewer capacity.
- Deploy time above 16 hours? Improve CI/CD pipelines and deployment automation.
- Coding time above 54 minutes? Check whether AI tools are speeding up or slowing down initial development.
AI adoption shifts these patterns in noticeable ways. Teams often see faster coding but longer reviews as engineers spend more time “babysitting the AI and reviewing what it is trying to do”.
FAQ
What is the LinearB cycle time formula?
LinearB calculates cycle time as production deployment timestamp minus coding start timestamp, using the first commit or Jira In Progress if configured, with aggregation options such as AVG, P50, P75, or P90. This formula covers work from initial development through production deployment.
What are LinearB cycle time benchmarks for elite teams?
Elite teams achieve total cycle times under 25 hours, with phase-specific targets defined in the 2026 benchmarks. These benchmarks represent the top-performing teams across LinearB’s dataset of 4,800 engineering organizations.
How does LinearB measure cycle time phases?
LinearB tracks cycle time through Git events and deployment integrations, monitoring timestamps from first commit through PR creation, first review, merge approval, and production deployment. The system excludes draft pull requests from Cycle Time calculations and uses configurable aggregation methods for consistent reporting.
Why is repo access necessary for AI cycle time analysis?
Metadata-only tools such as LinearB cannot distinguish AI-generated code from human contributions, which blocks accurate AI ROI measurement and hides AI-specific quality issues. Repo access enables code-level analysis that attributes cycle time improvements correctly and tracks long-term outcomes for AI-touched code.
How does Exceeds AI differ from LinearB for AI teams?
Exceeds AI provides code-level AI attribution and outcome tracking that LinearB does not offer. LinearB shows cycle time trends. Exceeds AI proves whether AI drove those trends, identifies which AI tools perform best, and tracks quality outcomes over time. The platform delivers insights in hours instead of weeks and focuses specifically on AI ROI proof.
Conclusion: Pair LinearB with Code-Level AI Observability
LinearB cycle time metrics give essential visibility into development bottlenecks, but AI-heavy teams also need code-level attribution to prove ROI and manage quality risk. The strongest approach combines traditional cycle time tracking with AI-specific observability to guide multi-tool AI investments. Connect my repo and start your free pilot to move from metadata estimates to code-level AI truth.