AI pull request overview
The AI pull request overview report compares PR flow, review, revert, and work-allocation metrics across AI code percentage bands. Use it to find differences worth investigating and test a rollout, enablement, review, testing, or PR-sizing change.
Note: This report requires AI Code Insights commit attribution and source control data that links commits to PRs. Its comparisons are observational; they do not show that AI caused a difference in speed or quality.

When to use AI pull request overview
AI pull request overview answers the question: How do PR outcomes vary across levels of captured AI-attributed code?
This report helps teams:
- Compare delivery flow — Review PR throughput, cycle time, size, and review turnaround across AI bands.
- Find review and revert signals — Identify differences in review comment density or revert rate that need PR-level inspection.
- Compare work mix — Check whether feature, bug-fix, and maintenance allocation differs across bands.
- Evaluate a change — Compare a documented rollout or guardrail in the same cohort before and after implementation.
What the report shows
The report includes these tiles when an administrator has not hidden them:
| Metric | What it measures |
|---|---|
| PRs opened | Number of PRs opened per period |
| PRs merged | Number of PRs merged per period |
| PR cycle time | Time from PR open to merge |
| PR size | Lines changed per PR |
| Review comment density | Review comments per PR |
| Review turnaround | Time from review request to first review |
| PR revert rate | Percentage of PRs that were reverted |
| Bug fixes | Percentage of PR work allocated to bug fixes |
| Feature development | Percentage of PR work allocated to features |
| Maintenance | Percentage of PR work allocated to maintenance |
Use the date, team or group, attribute, repository, interval, and AI code % filters to keep comparisons within a credible cohort. Open any chart point to inspect the underlying PRs.
How PR AI code percentage is calculated
DX derives each PR’s percentage from AI Code Insights attribution on its commits:
AI-attributed additions ÷ total attributed additions × 100
The source control connection must provide PR commit data. A PR with no calculable additions or no linked percentage appears as Unknown.
Use AI code percentage for the canonical commit-level metric, its version-dependent treatment of deletions, and coverage rules.
Understand AI code percentage bands
| Band | Stored criteria | Interpretation |
|---|---|---|
| 0% AI | pct_ai = 0 |
No captured AI-attributed additions. This is not proof that no AI was used. |
| <33% AI | 0 < pct_ai < 33 |
Some captured AI-attributed code; most additions are not AI-attributed. |
| 33–66% AI | 33 ≤ pct_ai ≤ 66 |
A moderate share of additions is AI-attributed. |
| >66% AI | pct_ai > 66 |
Most captured additions are AI-attributed. |
| Unknown | pct_ai is null |
DX cannot determine the percentage from linked commit data. |
Keep Unknown separate from 0% AI. A large or uneven Unknown band indicates that coverage or commit-to-PR linkage needs attention before comparison.
Interpret differences safely
A difference is a reason to inspect PRs, not a conclusion about AI.
- Faster AI-heavy PRs can reflect work type, team, repository, PR size, seniority, or rollout selection.
- More review comments can mean more problems, more thorough review, or a larger PR.
- A revert is an investigation signal, not a complete quality measure.
- Bug-fix allocation does not mean AI caused bugs. DX classifies the PR’s work type; it does not link a specific defect to AI-attributed code.
- 0% AI can include work where AI usage was outside daemon or supported-tool coverage.
Compare similar teams, repositories, work types, and PR sizes where possible. Record coverage and sample size with the result.
Turn the signal into action
- Choose one outcome and a comparable cohort.
- Compare 0% AI with one AI-attributed band while keeping Unknown visible as a coverage check.
- Open representative PRs from both groups and inspect work type, size, review history, tests, and revert context.
- Change one practice, such as rollout scope, enablement, automated testing, review policy, or PR-size guidance.
- Compare the same filters in the next period and document changes in coverage or work mix.