Watch by chapter
Executive summary
GitMe's anonymized snapshot points to one central conclusion: AI leverage is already substantial, but faster output does not automatically create a healthier engineering system.
| Signal | Result | Interpretation | Important limit |
|---|---|---|---|
| Modeled AI leverage | 2.22× | AI has materially changed the modeled composition of work. | Not a measured speedup. |
| AI concentration | Tests 69.5% | AI is moving into verification and maintainability. | Modeled category share, not authorship. |
| Contributor concentration | Top 20% carry 80.8% | Speed may depend on a small knowledge core. | Load proxy, not burnout diagnosis. |
| Twelve-month effort loss | 30.8% | Shipping does not guarantee durable contribution. | Cohorts decline from n=76 to n=4. |
| Durability warnings | +6.0 pp / +8.3 pp loss | Test deficit and AI overload deserve review. | Association, not causation. |
What 2.22× modeled AI leverage actually means
The 2.22× figure is a composition ratio: total modeled engineering effort divided by developer-led modeled effort. A 1.00× baseline represents developer-led effort. The additional 1.22× represents modeled engineering effort made possible through AI assistance.
It should not be interpreted as “developers work 2.22 times faster,” “AI wrote 55% of the code,” or “AI saved 55% of engineering time.” GitMe is describing modeled effort composition, not running a controlled productivity experiment.
This distinction matters. Adoption metrics show whether AI tools are present. Leverage metrics help leaders ask where AI meaningfully participates in the work. Durable-delivery metrics then ask what happens after that work ships.
AI is moving beyond feature work
The highest modeled AI-assisted shares appeared in tests at 69.5%, security at 64.6%, documentation at 62.2%, and features at 56.5%.
The strategic signal is not that AI belongs only in one category. It is that AI is entering verification, security, and maintainability work—not merely accelerating new feature drafts.
That creates an opportunity and a responsibility. AI can help teams broaden test cases, surface security concerns, and reduce documentation friction. But generated verification still needs execution feedback, behavioral assertions, and human judgment. More automated output is useful only when it produces stronger evidence.
Nearly half builds the new. The rest determines whether it lasts.
The modeled work portfolio allocates 48.5% to features, 14.8% to refactoring, 10.1% to bug fixes, 5.3% to documentation, and 5.1% to tests. Configuration, style, security, and other work make up the remaining share.
A feature-heavy portfolio is not inherently unhealthy. The risk begins when maintenance, testing, refactoring, and documentation are treated as optional overhead. These categories are part of the delivery system that allows new code to remain understandable, changeable, and useful.
Leaders should therefore evaluate the portfolio as a balance rather than ranking categories by visible output. Feature work creates new capability. Supporting work protects the organization's ability to keep that capability.
The top-20% concentration risk
In the median organization, the top 20% of contributors carried 80.8% of modeled effort. That concentration can make a team appear fast while knowledge, review responsibility, and delivery continuity depend on a small core.
This is not a burnout diagnosis and should not become an individual performance leaderboard. Modeled load is a proxy that should trigger a management conversation: Who understands the critical systems? Who is repeatedly pulled into high-effort changes? Where would delivery stall if one contributor became unavailable?
AI can scale a strong contributor's output faster than it spreads their context. Management must deliberately scale review participation, documentation, pairing, ownership rotation, and succession depth alongside AI adoption.
Shipping is not the finish line
Across the twelve-month cohort window, modeled-effort loss reached 30.8%. Loss is defined as 100 minus cohort effort retention: the share of earlier modeled engineering effort that no longer remains active after later changes.
This is not employee retention. It is a durability view of engineering contribution. Work may disappear because it is replaced, rewritten, removed, or otherwise ceases to remain active in the evolving codebase.
The later values must also be treated cautiously. Available cohorts decline from n=76 at the beginning to n=4 at the end. The curve is useful as a directional signal, not as a universal benchmark or a guarantee about what will happen in another organization.
Two durability warnings: test deficit and AI overload
When organization-months were compared with each organization's own normal level, two relationships stood out across 28 anonymized cohorts:
- Test-deficit months were associated with 6.0 percentage points more six-month modeled-effort loss.
- More AI-intensive months were associated with 8.3 percentage points more six-month modeled-effort loss.
These are observational associations, not causal findings. The data does not prove that AI caused the later loss or that adding tests alone would prevent it. Work type, project stage, system complexity, team composition, deadlines, and other factors may influence both the initial engineering pattern and later durability.
The management implication is still valuable: leverage needs a durability loop. When AI participation rises, verification and review discipline should rise with it. When test investment falls below a team's own normal level, leaders should inspect the downstream consequences rather than celebrating short-term throughput in isolation.
A management playbook for durable AI leverage
- Protect test investment. Track whether test work falls when feature pressure rises, and review which critical behaviors remain unverified.
- Strengthen review around AI-heavy changes. Treat generated code as a candidate contribution that must earn trust through execution, context, and downstream evidence.
- Distribute critical knowledge. Use contributor concentration to guide pairing, review rotation, documentation, and ownership depth—not individual scoring.
- Measure after shipping. Follow rework and effort survival so that initial output is connected to what remains valuable through later development.
The operating model is simple: AI leverage × durable code × distributed knowledge. Removing any one factor makes the engineering system more fragile.
Methodology and interpretation
- The report uses a frozen, anonymized September 2026 aggregate snapshot; demo data is excluded.
- Modeled AI leverage equals total modeled engineering effort divided by developer-led modeled effort.
- Category percentages allocate each contribution's modeled AI ratio across its modeled work categories.
- Contributor concentration is calculated independently per organization; the report shows the median organization's top-20% share.
- Modeled-effort loss equals 100 minus cohort effort retention and does not measure employee retention.
- Test- and AI-intensity comparisons are normalized against each organization's own average across 28 anonymous organization-month cohorts.
This is an observational engineering snapshot. It supports investigation and better questions; it does not establish causality or claim to represent every software organization.
Video transcript
- 0:00–0:07: The New Shape of Engineering Work. What GitMe's anonymized engineering data reveals about AI, teams, and durable delivery.
- 0:07–0:17: AI is changing the shape of effort. Total modeled engineering effort is 2.22× developer-led modeled effort: 1.00× developer-led plus 1.22× made possible by AI. This is a modeled-effort composition ratio, not a measured speed increase.
- 0:17–0:28: AI is moving beyond feature work. Modeled AI-assisted category shares are 69.5% for tests, 64.6% for security, 62.2% for documentation, and 56.5% for features.
- 0:28–0:39: Nearly half builds the new. The rest determines whether it lasts. The portfolio includes features 48.5%, refactoring 14.8%, bug fixes 10.1%, documentation 5.3%, and tests 5.1%.
- 0:39–0:51: Speed can hide a concentration risk. In the median organization, the top 20% of contributors carry 80.8% of modeled effort. Modeled load is a proxy, not a burnout diagnosis.
- 0:51–1:02: Shipping is not the finish line. Modeled-effort loss reaches 30.8% across the twelve-month cohort window. This is not employee retention, and available cohorts decline from n=76 to n=4.
- 1:02–1:09: Two warning signs weaken the durability loop. Test-deficit months are associated with 6.0 percentage points more six-month loss. More AI-intensive months are associated with 8.3 percentage points more loss. The sample contains 28 anonymized organization-month cohorts; the relationship is observational, not causal.
- 1:09–1:15: Engineering intelligence is a system: AI leverage × durable code × distributed knowledge. Code is moving faster. Is the organization learning faster?
Frequently asked questions
What does 2.22× modeled AI leverage mean?
It is total modeled engineering effort divided by developer-led modeled effort. It describes work composition; it is not a measured 2.22× speed increase or time-saved claim.
Does this snapshot prove that AI reduces code durability?
No. More AI-intensive months were associated with 8.3 percentage points more six-month modeled-effort loss in this cohort sample, but the relationship does not establish causation.
What is modeled-effort loss?
It is 100 minus cohort effort retention: an estimate of how much previously modeled engineering effort no longer remains active after later code changes. It is not employee retention.
Why does contributor concentration matter?
A small core carrying most modeled effort may create review, continuity, and knowledge-distribution risk. The signal is a management prompt, not a burnout diagnosis or individual performance score.
How should engineering leaders use these signals?
Protect test investment, review AI-heavy work through stronger verification loops, distribute critical knowledge, and track whether engineering effort remains durable after delivery.