Year over year, performance per engineer rose 130%.
Quarter over quarter, the change can’t be told apart from zero.
Cloudflare · Vercel · OpenAI · Google · Meta · Microsoft
Two notes before the data.
We sell a measurement layer for engineering work, so we have a commercial interest in the conclusion that such work can be measured at all. This report makes only descriptive and correlational claims: it reports what moved, not why. Sample boundaries and known limitations are in Section 7 and Appendix A.
Every quarter is recomputed. Re-scoring, contributor-role reclassification, and late-arriving commit attribution move historical quarters between snapshots, so this edition recomputes the whole window rather than carrying figures forward. On this snapshot the Q1 2025 → Q1 2026 open-cohort change reads +113%, where No. 01 printed +116%. A closed quarter is not a settled quarter: on two panels built thirteen days apart, both more than eight weeks after Q2 2026 closed, ETV per engineer for that quarter moved +11% pooled and +36% at Google, on identical cohorts. Read the tables here as one internally consistent series; comparisons should be drawn within a snapshot, not line by line across editions.
What one more quarter of data did to the previous reading.
The two figures sit on different baselines — No. 01 measured Q1 2025 to Q1 2026, this edition measures Q2 2025 to Q2 2026 — and on different snapshots. They are not a quarter’s worth of change, and subtracting them would not produce one. What did change is the shape: the level shift that arrived in Q1 2026 held, and the quarter that followed it is flat enough that its confidence interval contains zero.
The horizon you pick decides the answer you get.
Mean ETV per qualifying engineer moved +17.5% between Q1 2026 and Q2 2026 on the open cohort, with a 95% interval of [−0.7%, +38.8%]. That interval contains zero. On the fixed panel of the same 388 engineers the same quarter moved +3.5%.
The year-over-year reading is not ambiguous in the same way: +130% open and +82% fixed, both intervals clear of zero. That distinction is load-bearing for everything below — the data supports a year-over-year statement about scored output per engineer, and does not support a quarter-over-quarter one.
If you are reading this to benchmark a team, the annual figure is the one to quote. A single quarter of deceleration in a series this noisy is not yet evidence of a plateau.
The Shape
A level shift in Q1 2026, then a flat quarter on top of it.
The open cohort takes every engineer qualifying in the quarter; the fixed panel takes the 388 present in all six, which removes cohort composition as a source of trend at the cost of survivorship bias. Across the first four quarters the two series track each other closely and both stay near flat. The level shift arrives in Q1 2026 and is present in both — the pattern that rules out pure composition, because it survives holding the population constant.
Q2 2026 is where the two separate. The open cohort adds +17.5% while the fixed panel adds +3.5%, so roughly a fifth of the quarterly move survives once the population is held fixed. Over the year the correspondence is much stronger, +130% open against +82% fixed.
The bootstrap intervals behind these lines are wide enough that single-quarter jumps should be read cautiously; the multi-quarter slope is the signal of interest. It matters particularly here, because the headline quarter-over-quarter interval contains zero.
The Composition
The mix rotates out of maintenance and into tests.
Output splits across the five categories the scorer emits. Classification is file-scoped, so a commit that adds a feature, extends its test suite, and updates a README splits across Features, Tests, and Docs rather than booking whole to one category.
Over the full window Maintenance falls from 28.4% of scored output to 17.5% and Tests rises from 19.5% to 27.5%, now the second-largest category. In the last quarter alone Tests moves +3.7pp against Features at −3.2pp; the other three each move by at most 1.4pp.
| Share of output | Q1 '25 | Q2 '25 | Q3 '25 | Q4 '25 | Q1 '26 | Q2 '26 | Window Δ | QoQ Δ |
|---|---|---|---|---|---|---|---|---|
| Features | 30.5% | 31.9% | 33.7% | 32.6% | 38.0% | 34.9% | +4.4pp | −3.2pp |
| Maintenance | 28.4% | 27.3% | 25.2% | 22.9% | 18.5% | 17.5% | −10.9pp | −1.0pp |
| Tests | 19.5% | 20.7% | 19.9% | 24.3% | 23.8% | 27.5% | +8.0pp | +3.7pp |
| Docs | 5.8% | 5.6% | 5.7% | 4.9% | 4.3% | 5.6% | −0.2pp | +1.3pp |
| Fixes | 15.8% | 14.4% | 15.5% | 15.2% | 15.3% | 14.5% | −1.3pp | −0.9pp |
These are shifts in composition, not statements about intent, and a falling share is not falling output. Maintenance is the clearest case: its share fell 10.9pp across the window while total output per engineer rose 150%, so absolute maintenance output per engineer per month rose +54%, from 0.26 to 0.40 ETV. Less of a larger total, not less maintenance.
The Spread
Every organization is positive on both horizons. Only one of the two orders is reproducible.
Mean ETV per qualifying engineer · % Δ
Because this dataset re-scores closed quarters, an ordering can be tested directly: rank the same organizations on two panels built thirteen days apart, then count how much of the order survives. Measured over the full window it survives well — 13 of 15 pairs hold, a rank correlation of +0.73 at p = 0.028.
Year over year the same test is weaker. 8 of 10 pairs hold at +0.60, which across five organizations is p = 0.117 — short of conventional significance on its own. What sharpens it is that both failures are the same organization. Set Microsoft aside and all 6 orderings among the remaining four reproduce exactly, at p = 0.042. The annual order is stable except in Microsoft’s position, rather than uniformly noisy.
The quarterly ordering does not survive at all: 8 of 15 pairs hold, a rank correlation of +0.07 at p = 0.500 — chance exactly, not as a figure of speech. Cloudflare moves from last (+3.6%) to first (+22.5%) on the same closed quarter. So the quarterly column below is printed for completeness and is not a ranking.
What that means in practice. A single quarter of movement will not tell you where an organization stands against its peers: re-scoring the same closed quarter thirteen days later can reverse the order. The annual figure carries that weight. The quarterly one does not. That is the organization-level counterpart of the aggregate finding above.
OpenAI · held out of the scale above
Its Q2 2025 cohort of 18 SWEs sits below the 20-SWE sample floor, so the year-over-year change is measured from a baseline this report does not consider reportable on its own. Rebased to Q3 2025, its first at-floor quarter, the change to Q2 2026 is +230%.
Quarter over quarter, on a baseline at floor: +22.1%
Cohort size fell at all six organizations between Q1 2026 and Q2 2026, from 802 qualifying engineers to 705. Where a cohort contracts and mean output per remaining engineer rises, the aggregate can move without any individual engineer changing output — the fixed panel above is the control for exactly that.
Those are per-organization totals, and they are not deduplicated: an engineer committing to two organizations’ repositories is counted in each. That is why they run above the 699 distinct engineers in the Q2 2026 aggregate — the count reported at the top of this page.
Read that contraction as an upper bound. Across the two panels thirteen days apart, every quarter’s cohort gained members except the most recent — Q3 2025 +11, Q4 2025 +11, Q1 2026 +12, Q2 2026 +0. Quarters keep accruing members for a year or more after they close, and Q2 2026 has not begun to. Both quarters the contraction spans are still moving, and they move it in opposite directions, so the bound holds only if Q2 2026 accrues more from here than Q1 2026 has left. This snapshot cannot confirm it; a later edition can.
Per-organization work-mix panels, the quarter-by-quarter trajectories, and the reason Cloudflare’s documentation share runs several times the aggregate are in the white paper (Sections 5 and 5.1, Figures 4a and 4b).
Capacity
The same gain counted in engineers rather than percent — capacity nobody had to hire.
Each organization against its own opening reading · engineers
Every figure above measures each organization against its own first quarter. That answers whether it improved — not how much engineering the sample now holds. This section reads the same distance as capacity: the number of opening-era engineers it would take to ship what each organization ships today. Every subject divides by its own opening reading — the 90 days ending 2025-04-01, the earliest window the index publishes, and one that closes before the adoption period this report covers. Each starts at 1.00× on that same window, so the figures below are what each has added since.
These are the published index’s own figures. This section reports what 500.navigara.com serves for each organization rather than recomputing capacity on this report’s own basis, so the two cannot print different numbers for the same organization. The cohorts are not a difference between them: the index applies the same two tests, so every headcount below is the same qualifying cohort as the matching Q2 2026 column above.
Capacity added is the quarter’s cohort multiplied by (multiple − 1), where the multiple is that organization’s Q2 2026 ETV per engineer per month over its own opening reading. Ships like is the cohort plus that. It is measured from shipped output, not from AI usage: nothing here counts tools, licences, or assistant sessions.
* OpenAI — its opening window holds 6 engineers, below this report's 20-engineer floor. A divisor drawn from a small window moves further between syncs than the rest, which makes it the least stable figure here and gives it the widest multiple in the study by construction. It supplies +265 of the +1,031, or 26%; without it the other five come to +766, which is the figure to quote if that divisor is not one you want to rest on. It is printed rather than dropped so the figure stays visible, and held out rather than moved to a later window so every organization sits on one opening.
Every row is a point estimate. The bootstrap intervals quoted elsewhere in this edition are computed on the panel, and the index publishes none on a rolling window, so none are carried here.
What differs from the sections above is the divisor, and only the divisor. This section divides by a rolling 90-day window; the sections above divide by a quarter. So a multiple here is not the percentage change there: holding the sample fixed at the same six organizations, this report’s pooled Q1 2025 quarter of 0.911 gives +1,056 engineers against the +1,031 above. Neither is a correction of the other. Per-organization detail and Figure 4c are in the white paper (Section 5.2).
Fewer commits, each carrying more.
The aggregate decomposes into frequency and intensity: commits per engineer and performance per commit. Quarter over quarter they move in opposite directions — commits per engineer −11.2% against performance per commit +32.4%. Year over year both rise, by +14.9% and +100.4%.
Engineers in the qualifying cohort landed fewer merged commits than in Q1 2026. Consistent with larger units of work, and equally consistent with a shift in commit-granularity practice such as heavier squashing before merge.
Each commit carried more scored complexity. Over the full window per-commit intensity is up +128% — the component that accounts for most of the headline.
Note: unlike No. 01, the two components multiply to the headline exactly, because the decomposition is an identity rather than an approximation — all three statistics are pooled quarterly ratios over the same commit set, so the commit count cancels. Falling frequency times rising intensity gives 0.888 × 1.324 = 1.175, the +17.5% above. What the identity cannot do is attribute the movement: both factors are cohort-level ratios, so either can move because the cohort changed rather than because any individual engineer did.
Nor can this edition rule the squashing explanation in or out. The commit records carry author, timestamp, repository, the five sub-scores and the merge and exclusion flags — no diff size and no pull-request linkage — so files or lines per commit, and commits per pull request, cannot be computed at any layer. Separating the two readings needs those fields at ingestion. Until then the decomposition says which component moved and cannot say why.
Same engine as No. 01, reported on five categories instead of three.
Five sub-scores, one scalar. For each merged commit the engine produces one sub-score per work category — Features, Maintenance, Tests, Docs, Fixes. Each is assembled per file and summed across the commit, so classification is file-scoped. Their sum is the Engineering Throughput Value. The scalar is unchanged from No. 01; only the reported breakdown moved from three categories to the scorer’s native five.
Sample. 137,592 qualifying commits to 65 public repositories across six organizations over a 78-week window. A contributor is an engineer when the role classifier assigns Software Engineer and they have commit activity in at least 10 of those 78 weeks; they join a given quarter’s cohort by authoring at least one scored commit in it. Bots are excluded by pattern match on email and display name.
Organization selection. Not a random sample. Cloudflare, Vercel, and OpenAI were chosen because each makes frequent public claims about AI productivity gains in its engineering organization; Google, Meta, and Microsoft as incumbents of substantially larger scale with strong public reputations for engineering talent density. Cross-organization comparisons reflect that.
Sample floor. Per-organization results are reported only where that organization’s qualifying cohort in a quarter reaches 20 engineers. Quarters below the floor are suppressed; where a below-floor quarter is nonetheless used as a comparison baseline, as with OpenAI above, it is marked in place.
Uncertainty. 95% intervals by bootstrap over 1,000 seeded iterations, resampling within each quarter. Quoted percentage-change intervals are endpoint intervals: they reflect sampling error in the endpoint quarter only and understate total uncertainty in the change, since the baseline quarter carries its own.
Temporal alignment. Calendar quarters. Commits are attributed to the quarter in which they were authored, not the quarter they merged, so long-lived branches distribute across the window rather than concentrating at merge. Q2 2026 closed 2026-07-01, ten weeks before this snapshot. Late-arriving ingestion is small at that remove; re-scoring is not, which is why every figure here is recomputed on one snapshot. Q3 2026 was still open at publication and is excluded rather than reported as a partial quarter.
Subject-matter confound. 21 of the 65 repositories in the sample are AI or agent SDKs, and they are not spread evenly — OpenAI 8 of 8, Microsoft 5 of 12, Vercel 3 of 9, Google 3 of 12, Cloudflare 2 of 14. Demand for that category grew over the same window this report measures, so for those repositories output per engineer and market growth are not separable here. It bears most on OpenAI, whose sample is entirely of that kind and whose cohort went from 6 engineers to 38 and back to 32 across the window — a shape as consistent with staffing a launch as with any change in productivity.
Sensitivity to the weights. ETV sums the five sub-scores with equal weight, which is a modelling choice, so the headline is recomputed under perturbations of it. The year-over-year finding does not depend on the weighting: it ranges +111% to +161% across every variant, including dropping any one category and counting Fixes against output, and no variant changes its sign or order of magnitude. The quarter-over-quarter figure ranges +11.8% to +23.5%, a factor of two between the extremes — a further reason it is not reported as a finding. What this cannot reach is the scorer’s internal coefficients, which are applied upstream of anything the report observes.
Limitations. Public repositories only. No view into private work, code review depth, incident response, planning, or mentorship — anything not captured as a merged commit to an in-scope repository. Monorepo versus polyrepo workflow, squash-merge policy, and public-versus-private code mix are not controlled.
Interpretation. The window coincides with broad production adoption of AI coding assistants across these organizations. The study does not quantify what share of the level shift, if any, is attributable to that adoption, and a single quarter of deceleration in a noisy series is not yet evidence of a plateau.
13 pages · five-way work classification · per-org detail in Section 5.1 · engineering capacity in Section 5.2 · weight sensitivity in Section 7.2 · 65 repositories enumerated in Appendix A
Key findings
Year over year, scored output per engineer is up 130% and the finding survives holding the engineer population constant. Quarter over quarter, the change cannot be told apart from zero — and neither can the quarterly ordering of the six organizations, which re-scoring the same closed quarters reshuffles to chance. The annual ordering mostly holds. The mix rotated into tests, the quarter’s movement came entirely from per-commit intensity, and whether Q1 2026’s level shift was a step or the start of a slope still needs another quarter to answer.
Whether any of this output was aimed at the right things is a separate question that commit history cannot answer. Navigara’s Alignment concept handles it by connecting to Jira or Linear. That’s outside this study.
Cloudflare · Vercel · OpenAI · Google · Meta · Microsoft
The series
Older edition
No. 01 · Q1 2026
Engineering performance measured at scale
+116% · 30 April 2026
Read the editionNext edition
Published quarterly. The next edition revisits the same cohort one quarter on.