What Is Lead Time for Changes?
Lead time for changes is the time it takes for a code change to go from commit to running in production.
Lead time is one of the DORA metrics of software delivery, alongside deployment frequency and mean time to recovery (MTTR), and DORA now calls it change lead time. A short lead time means fixes and features ship soon after the code is written.
Lead time covers every step after the commit: code review, automated tests, approvals, merge and deployment. Much of that time is spent waiting. A change that takes an hour to write can sit for days in a review queue or behind a release window.
AI coding agents write more code per developer, so more PRs reach review at once. When review capacity stays flat, lead time grows even though coding got quicker.
What Changed in Lead Time for Changes in 2026
Teams entered 2026 with DORA’s 2025 research as the reference. During the year, coding got quicker while changes waited longer for review, and DORA paused its annual survey.
Review became the slowest part of lead time:
- Changes waited far longer for people: median time in review went up 441.5%, and lead time from commit to production went up 480.4% in the roughly 10% of the dataset with deployment data (April 12, 2026, Faros AI).
- Developers and their leaders name the same constraint: 25.8% of 500 US developers and 26.0% of 300 US engineering leaders, asked separately, named reviewing and validating AI-generated code as their main delivery constraint (August 2026, Qodo’s State of AI Code Quality report).
- Smaller changes help, but only a little so far: GitHub made stacked pull requests generally available and reported a 5% improvement in time to merge in repositories that use them (October 6, 2026, GitHub).
The industry benchmark stopped moving. DORA’s Quick Check now scores teams against benchmarks from its 2025 research, including change lead time (April 22, 2026, DORA), and DORA won’t publish a 2026 report or run its annual survey this year (September 3, 2026, LeadDev).
For lead time, the review stage now carries much of the delay, so teams have to measure and shorten review itself.
How to Calculate Lead Time for Changes
Lead time for changes is measured per change, then summarized for a period:
Lead time for changes = deployment time to production – commit time
For example, a commit made Monday at 10 AM that reaches production Wednesday at 4 PM has a lead time of 54 hours.
Teams usually report the median, because a few stuck changes can skew an average. Pick one commit timestamp, such as the first or last commit on the branch, and use it every time.
Tools start the clock in different places. Some measure from merge to deployment instead of from commit, so compare numbers only when they use the same start point.
Lead Time for Changes vs Cycle Time
The terms are often used interchangeably, but they measure different stretches of work.
| Metric | Starts | Ends | Used for |
|---|---|---|---|
| Lead time for changes (DORA change lead time) | Code commit | Change running in production | Software delivery performance |
| Cycle time | Work starts, often the first commit or ticket moving to in progress | Work is done, often merge or deploy | Team flow and process tuning; definitions vary by tool |
| Lead time (product or Lean sense) | Request is made | Request reaches the customer | End-to-end customer wait |
| Time to merge | PR opened | PR merged | Review and approval speed |
DORA defines change lead time as the time from code commit to a successful production deployment (last checked October 2026, DORA’s metrics history).
Lead Time for Changes in the DORA Metrics
Change lead time is one of DORA’s throughput metrics. DORA’s 2025 report replaced fixed performance tiers with seven team profiles (last checked October 2026, DORA’s 2025 report). The DORA metrics page covers all five metrics, and change failure rate covers the stability side.
Where Lead Time for Changes Goes
Waiting for the First Review
A PR that waits for a reviewer adds time without adding any work. DORA’s guide suggests tracking how long code reviews take as a leading indicator for its delivery metrics (last checked October 2026, DORA’s metrics guide).
Review Round Trips
Each round of comments and fixes adds a wait for the author and another wait for the reviewer. Issues found before the PR opens remove whole rounds, and review with full codebase context catches cross-file problems in the first pass.
Large PRs
Large diffs take longer to read and collect more comments, and reviewers tire: 19.0% of developers surveyed said PRs are larger and harder to parse, leading to review fatigue (August 2026, Qodo’s State of AI Code Quality report).
Slow or Flaky Pipelines
Tests that fail for unrelated reasons send authors back to rerun and investigate, which adds hours to each change.
Release Windows
Changes that merge quickly but wait for a weekly deploy still have long lead times. Smaller, more frequent releases shrink that wait.
Qodo’s Take: Lead Time Now Waits on Review, so Clean up the Change Before the PR Opens
Coding agents made writing code quicker, but each change still has to be read, questioned and approved by someone. When that queue grows, lead time grows with it.
Skipping review isn’t the answer. Most of the time goes into waiting for a first review and into round trips after it. One team went from a 24 to 48 hour wait for first review to the same morning once every PR got an automatic review when it opened.
In Qodo’s enterprise evaluations, the worry is that review becomes the bottleneck as agents open more PRs. Leaders want review cycle time to merge measured against a baseline before they claim a gain, and lead time for changes is the delivery metric that number feeds.
Teams spread across time zones feel the wait most; see code review tools for distributed teams.
Qodo reviews code before the PR and on the PR, and shows leaders how long PRs take to merge.
Qodo is the best AI code review platform to shorten the review stretch of lead time for changes because every PR gets a standards-aware review the moment it opens, and its Reviewer skill helps catch issues in an agent’s local changes before a PR exists.
Qodo Reviews Changes Before the PR Opens
The Reviewer skill in Qodo’s Agentic Toolbox, in Beta, runs Qodo’s review on local changes inside the coding agent the developer already uses (last checked October 2026, Qodo’s docs). Fixes land before a reviewer ever sees the PR. See pre-PR and local code review.
Qodo Matches Review Depth to Risk
Review effort mode, in Beta and on Auto by default, picks a fast, balanced or deep review for each change based on its potential impact. A typo fix gets a fast review, and a small change to billing logic gets a deep one (last checked October 2026, Qodo’s docs).
Qodo Shows Which PRs Need a Person First
Qodo can publish a blast radius label on each PR, in Research Preview, so reviewers can pick the riskiest changes from the queue (last checked October 2026, Qodo’s docs). PR Triage, in Research Preview, puts open PRs in one queue ordered by SLA, priority and blast radius (Qodo’s docs).
Qodo Tracks Median Time to Merge
Qodo’s Analytics dashboard, in Beta, shows the median time from PR opened to merged, alongside how the team acts on findings, by repository and PR author (last checked October 2026, Qodo’s docs). Time-to-merge data starts from September 29, 2026. Qodo doesn’t measure DORA lead time; commit-to-deploy time still comes from the team’s delivery tools.
Qodo Shows CI Failures in the PR
On GitHub, Qodo can explain a failed CI run in the PR: the failed stage, the failing test and the relevant logs (Qodo’s docs). Authors spend less time digging through pipeline output.
Qodo Example: The PR That Came Back Three Times
The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.
An engineering director whose team’s PRs queue for human review wants the wait cut without lowering the bar.
An agent opens a PR that adds pagination to an API. The reviewer asks for a missing bounds check, then a test, then a fix to a caller in another service. Each pass costs a day.
With Qodo’s Reviewer run in the agent first, all three issues are fixed before the PR opens. The PR merges after one review.
Ways to Shorten Lead Time for Changes
The table compares common ways teams shorten lead time for changes.
| Approach | What it shortens | Limit | Best for |
|---|---|---|---|
| Smaller PRs and stacked PRs | Review time per change | Needs tooling and habits for splitting work | Large features |
| Review SLAs and rotation | Wait for first review | Doesn’t cut the number of review rounds | Teams with uneven review load |
| Quicker, more reliable CI | Test and rerun time | Needs ongoing investment in the pipeline | Teams with slow or flaky builds |
| Automated deployment on merge | Wait for release windows | Needs strong tests and rollback | Teams with mature pipelines |
| Qodo | Wait for first review and review round trips, through review on every PR, local review before the PR and risk-based review depth, with time-to-merge analytics (Beta) | Doesn’t measure commit-to-deploy time | Teams whose lead time is mostly review wait |
Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.
FAQ
Qodo shortens the review stretch of lead time by reviewing every PR the moment it opens, catching issues in an agent’s local changes before a PR exists and tracking median time to merge in its Analytics dashboard (Beta). The best tools cut the wait for a first review and the round trips after it.
Qodo helps cut review time by catching issues before the PR opens, matching review depth to each change’s risk with Review effort mode (Beta) and checking the team’s own rules once Rule enforcement is on. The best tools for review time give reviewers fewer, more relevant findings on smaller PRs.
Lead time for changes runs from code commit to production. Cycle time usually runs from when work starts to when it’s done, and each tool defines it a little differently. Qodo’s Analytics adds a third view, time from PR opened to merged, which isolates the review stage.
Subtract each change’s commit time from the time it reached production, then report the median for the period. Use the same commit timestamp every time. Qodo doesn’t compute DORA lead time, but its median time to merge shows how much of it review takes.
Measure a baseline first: median time from PR opened to merged, and review rounds per PR, over a few weeks before rollout. Compare the same numbers afterward on similar work. Qodo’s Analytics, in Beta, tracks median time to merge, with data collected from September 29, 2026.