Throughput Up 75%, Review Wait Up 105%: Reading the Q3 2026 AI Engineering Data

Three separate 2026 datasets now describe the same shape, which makes it hard to dismiss as one vendor's slide deck. DX measured weekly developer throughput up from 1.43 to 2.51 complexity-weighted pull requests over four quarters, while organisations with the highest share of AI-authored code waited 105% longer for a first review. Faros found work restarts up 66.7%, time in QA up 300.6% and pull requests merged without any review up 76.3%. Harvard's researchers found pull requests up 23% per worker with no statistically significant gain in completed issues. Authoring scaled. Verification did not.

Authoring capacity scaled. Reviewing capacity did not

Three datasets, one shape

The datasets measure different things with different methods, which is what makes the agreement interesting. DX surveys more than 500 engineering organisations and combines source control, CI/CD and AI tooling telemetry with developer sentiment, covering July to September 2026. Faros's AI Engineering Report Q3 2026, published as The Speed Trap, measures workflow transitions across its customer base. The Harvard paper examines firm-level production bottlenecks. All three land on the same asymmetry: the volume of change rose sharply, while the capacity to understand, review and verify it did not rise at the same rate. None of them shows that AI coding tools are not worth using. They show where the new constraint sits, and it is not where teams are used to looking.

# PR size, straight out of git. No vendor dashboard required.
import statistics, subprocess

def pr_sizes(since="6 months ago"):
    log = subprocess.run(
        ["git", "log", "--since=" + since, "--numstat", "--pretty=format:%H|%ad", "--date=short"],
        capture_output=True, text=True, check=True).stdout
    commits, current = [], None
    for line in log.splitlines():
        if "|" in line and line.count("|") == 1:
            if current:
                commits.append(current)
            current = {"sha": line.split("|")[0][:8], "added": 0, "files": set(), "date": line.split("|")[1]}
        elif current and line.strip():
            parts = line.split("\t")
            if len(parts) == 3 and parts[0].isdigit():
                current["added"] += int(parts[0])
                current["files"].add(parts[2])
    if current:
        commits.append(current)
    return commits

rows = pr_sizes()
added = [r["added"] for r in rows]
files = [len(r["files"]) for r in rows]
print("commits:", len(rows))
print("lines added p50/p90:", statistics.median(added), sorted(added)[int(len(added) * 0.9)])
print("files touched p50/p90:", statistics.median(files), sorted(files)[int(len(files) * 0.9)])

# Faros measured average PR size up 71.8% and files edited per PR up 52.0%.
# If your p90 is climbing and your reviewer count is not, the queue is already full.

Faros: throughput up, verification later

The Faros numbers look excellent for a third of the way down the list and progressively worse after that. Task throughput per developer increased 69.0% and epics completed per developer rose 53.7%. Deployment frequency rose 13.8% among the roughly 10% of teams with deployment data. Then work restarts per developer rose 66.7%, average time in QA rose 300.6%, average pull request size rose 71.8%, files edited per PR rose 52.0%, median time to first review rose 114.5% and pull requests merged without any human or agentic review rose 76.3%. Daily task contexts per developer rose 44.6% and daily pull request contexts 24.8%. The pattern is orchestration: developers supervise more units of work and write less of it themselves.

# Review coverage and first-review latency from a saved API export.
# Save the JSON once, then this is a pure calculation, not a live query.
import json, statistics
from datetime import datetime, timezone

def parse(ts):
    return datetime.fromisoformat(ts.replace("Z", "+00:00"))

with open("pulls_export.json") as fh:
    pulls = json.load(fh)

merged = [p for p in pulls if p.get("merged_at")]
no_review = [p for p in merged if not p.get("reviews")]
latencies = []
for p in merged:
    reviews = p.get("reviews") or []
    if reviews:
        first = min(parse(r["submitted_at"]) for r in reviews)
        latencies.append((first - parse(p["created_at"])).total_seconds() / 60)

print("merged PRs:", len(merged))
print("merged with no review: %.1f%%" % (100 * len(no_review) / len(merged)))
if latencies:
    print("first review p50 minutes: %.0f" % statistics.median(latencies))
    print("first review p90 minutes: %.0f" % sorted(latencies)[int(len(latencies) * 0.9)])

# Faros found median time to first review up 114.5% and PRs merged with no
# human or agentic review up 76.3%. Both are visible in this export.

Bigger pull requests are the source of most of these numbers

DX: the review queue is the constraint

DX's median weekly TrueThroughput, a complexity-weighted measure, went from 1.43 pull requests per developer in Q4 2025 to 1.74, then 2.11, then 2.51 in Q3 2026 — growth of 21.7%, 21.3% and 19.0% quarter over quarter. The companion chart is the important one: median time to a first review splits by how much of the code in an organisation is AI-authored, at 40 minutes for the 20-40% band, 56 minutes for 40-60%, 71 minutes for 60-80% and 82 minutes above 80%. That is a 105% difference, and DX is careful to attribute it to capacity rather than to reviewers being more reluctant about AI code. Waydev's reading of the same dataset adds that median PR size roughly doubled, from 46 lines of code to 102.

# Work restarts: a task that moves forward, then comes back. Faros measured +66.7%.
import csv
from collections import Counter, defaultdict

RESTART_STATES = {"in progress", "in development", "reopened"}

rows = list(csv.DictReader(open("issue_transitions.csv")))
history = defaultdict(list)
for row in rows:
    history[row["issue_key"]].append(row)

events, restarts = 0, 0
for key, moves in history.items():
    moves.sort(key=lambda r: r["changed_at"])
    seen_forward = False
    for move in moves:
        events += 1
        state = move["to_state"].strip().lower()
        if state in {"review", "qa", "done"}:
            seen_forward = True
        elif seen_forward and state in RESTART_STATES:
            restarts += 1
            seen_forward = False

print("transitions:", events, "restarts:", restarts)
print("restart rate: %.1f%%" % (100 * restarts / max(1, events)))

# The cost is not the second attempt. It is the context rebuild, plus the
# reviewer or QA pass that has to happen again on work already examined.

Harvard: coding was never the bottleneck

The Harvard paper is the useful corrective to any productivity claim. Coding-agent adoption increased pull requests created per worker by 23%, but the increases in completed Jira issues and epics were small and statistically insignificant. The authors estimate that writing code accounts for about 42% of engineers' time, against 30% in a separate survey. If code authoring is less than half the job, making it faster has a bounded effect on delivery. The same paper found PR submission-to-merge time up 49%, the share of pull requests receiving formal change requests up from roughly 13% to 25%, and the share of workers participating in review up 14%. More people are reviewing, and more work still needs a second pass.

# QA dwell time: how long work sits between "ready for QA" and QA finishing.
import csv, statistics
from datetime import datetime

def ts(value):
    return datetime.fromisoformat(value)

dwell, open_since = [], {}
for row in csv.DictReader(open("stage_events.csv")):
    key, stage = row["issue_key"], row["stage"].strip().lower()
    if stage == "qa":
        open_since[key] = ts(row["entered_at"])
    elif key in open_since:
        dwell.append((ts(row["entered_at"]) - open_since.pop(key)).total_seconds() / 3600)

if dwell:
    print("QA samples:", len(dwell))
    print("median hours in QA: %.1f" % statistics.median(dwell))
    print("p90 hours in QA: %.1f" % sorted(dwell)[int(len(dwell) * 0.9)])

# Faros measured average time in QA up 300.6% as AI adoption deepened.
# Growth here usually means verification moved downstream, not that QA slowed down.

The real constraint starts after the code is written

Four numbers worth computing before you report anything

Four metrics cover most of what these reports describe, and all four are computable from data you already store. First, first-review latency in minutes, reported as a median and a p90. Second, review coverage: the share of merged pull requests that had at least one review. Third, the work-restart rate, defined as tasks that moved into review or QA and then moved backwards. Fourth, the size distribution of changes, as lines and files at the median and the 90th percentile. Together they say whether more output is reaching production faster or simply spending longer in a queue. A fifth number is worth keeping alongside them: how many distinct tasks and pull requests each developer touches in a day.

# Comprehension debt, proxied: AI-authored lines versus reviewed lines per file.
import subprocess
from collections import defaultdict

AI_TRAILERS = ("Co-authored-by: copilot", "Generated-by:", "Assisted-by:")

def ai_share_by_file(since="3 months ago"):
    log = subprocess.run(
        ["git", "log", "--since=" + since, "--pretty=format:%x00%H%n%B%x00", "--numstat"],
        capture_output=True, text=True, check=True).stdout
    stats = defaultdict(lambda: {"ai": 0, "human": 0})
    blocks = log.split("\x00")
    for i in range(1, len(blocks) - 1, 2):
        body = blocks[i].lower()
        is_ai = any(t.lower() in body for t in AI_TRAILERS)
        for line in blocks[i + 1].splitlines():
            parts = line.split("\t")
            if len(parts) == 3 and parts[0].isdigit():
                stats[parts[2]]["ai" if is_ai else "human"] += int(parts[0])
    return stats

rows = ai_share_by_file()
for path, s in sorted(rows.items(), key=lambda kv: -(kv[1]["ai"] + kv[1]["human"]))[:10]:
    total = s["ai"] + s["human"]
    print("%-48s ai=%5.1f%% lines=%d" % (path[:48], 100 * s["ai"] / max(1, total), total))

# Faros calls the deferred understanding "comprehension debt". The files at the
# top of this list are where the next incident will be explained the slowest.

What to change, given the data

The reports push in the same direction. Cap change size, because every downstream cost in this article scales with it. Treat review capacity as a first-class resource: if review throughput is flat while authoring doubles, the queue becomes the delivery system. Make restarts visible, since a task that bounces back is the hidden cost that makes throughput numbers look better than they are. Keep a human in the loop on architecture and interfaces, which is where the Harvard data shows the bottleneck actually lives. And when you report to a board, stop reporting raw commit or pull request counts, because AI inflates exactly that number while leaving the delivery behind it unchanged.