Because 8 ≈ e², Anthropic’s researcher uplift is plausibly >2x

[Thomas Kwa]

Link post

Note: the modeling assumptions and conclusion are Thomas Kwa’s opinion, and others at METR disagree. ^[1] Also, the math was checked by Claude but not a second human.

Introduction

Anthropic’s RSI blog post reported that in Q2 2026, Anthropic contributors merged 8× as much code per day as in the 2021-2024 period. What does this imply about the factor by which a researcher’s total effective output increased — the (serial) researcher uplift ^[2] ?

Of course, 8× more code doesn’t mean 8× more research, as coding is only part of the job. However, if we assume each line of code (LoC) has equivalent quality and verbosity to pre-2025 code and make standard economic modeling assumptions, we can conclude a surprising amount: all models predict researcher uplift at Anthropic from coding agents alone is >2×. (Researcher uplift could be even higher, because these numbers assume no uplift on non-code tasks.)

• Cobb-Douglas predicts that if pre-AI time spent coding is and code output increases by a factor , then researcher uplift is .

• CES (constant elasticity of substitution) production functions, due to a fun mathematical coincidence, infer a narrow range of about if code is homogeneous.

• If code is CES but non-homogeneous, such that AI speeds up low-stakes code more than high-stakes code, we obtain a range of , lower but still over 2x.

However, there are several reasons new code may not be equivalent to old code, which would be at least partially resolvable with internal Anthropic data.

• Verbosity: substantially overstates true quality-adjusted code output (e.g. perhaps AI code is >2x more verbose than human code for the same functionality).

• Barely-useful code: AIs are speeding up people enormously (>20x) on low-stakes code that would never have been written pre-AI, but is only 5%-20% as valuable as normal code.

• Researcher irrationality: Anthropic researchers are producing code that doesn’t contribute to research value (e.g. because vibe coding is fun).

Anthropic’s Mythos system card claims that their overall R&D uplift is “well short of” 2x, which is consistent with >2x researcher uplift because R&D depends on both labor and compute (and compute increases don’t count towards the number). I’d guess that overall R&D uplift will probably hit 2x somewhere around 3.5x researcher uplift, which could happen in the next year or so. Therefore, it’s important that labs obtain sufficiently high-quality data and models to measure code output beyond just LoC and relate it to researcher uplift.

Economic models

The core question is: if a researcher ^[3] produces 8× more code, how much more research value do they create overall? This depends on how important code is relative to everything else a researcher does (thinking, writing, experiments, communication), and on whether those activities are substitutes or complements — i.e., whether doing more of one makes the others more or less valuable.

A production function is the standard economic tool for this. It takes the quantities of each input (here, code output and non-code output) and returns total value. The most common production function is Cobb-Douglas; we consider both Cobb-Douglas and a slight generalization CES (Constant Elasticity of Substitution).

Cobb-Douglas model

The simplest economic model for predicting how much of a good is produced, if it needs more than one input, is called Cobb-Douglas. This is similar to what the AI Futures Project assumes for labor and compute. The equation for Cobb-Douglas gives research output as:

where:

• is the time share on coding ^[4]

• and are the quantities of code and non-code produced.

We can then define (serial) researcher uplift as the ratio of post-AI to pre-AI output, . Assume pessimistically that there is no non-code uplift, which means is constant. Then it turns out that:

If researchers spend roughly half their time coding (), then . ( is roughly the median of what people I ask find reasonable. I have substantial uncertainty about , but fix it at 0.5 for simplicity throughout. A more thorough analysis should certainly vary it.)

CES model

When we move from Cobb-Douglas to the general CES case, we gain the ability to model substitutability: if code and non-code are strong complements (like left and right shoes), doubling code output without more non-code output barely helps. If they’re substitutes (like butter and margarine), doubling one input nearly doubles total value. We don’t know which is true for AI research, so we test across a range.

Setup

A researcher splits fixed time across two task types: coding and non-coding. We assume the output follows the CES function:

where:

• is the pre-AI time share on coding ^[4:1] (in CES, it is possible for time shares to change between the pre-AI and post-AI periods);

• and are the quantities of code and non-code produced.

• is the elasticity of substitution between coding and non-coding output.

Now, it can be calculated that the researcher uplift (assuming researchers allocate time optimally in both periods) is:

where is the per-hour speedup AI provides on coding, which we will refer to as the coding uplift. ^[5]

We don’t directly observe . We observe , the mean code output increase of Anthropic contributors. ^[6] (These differ because researchers reallocate time when AI makes coding cheaper.) It turns out that , , , and are related by a fairly simple equation , ^[5:1] and observing gives a fairly robust estimate for .

Because 8 ≈ e², the estimate is robust to σ!

In Cobb-Douglas, we assumed that code and non-code have unit substitutability (). What if they’re complements () or substitutes ()? The conclusion actually changes very little.

The key reason is that 8x code output substantially constrains the possible values of our two free parameters: coding uplift and marginal value of code (which is increasing in ). If coding uplift and marginal value of code were both large, then the amount of code produced would be larger than 8x, as code would be both cheap to produce and super valuable. Alternatively, if and were both small, then output would be less than 8x, as code would be expensive to produce and not valuable. Only intermediate choices of the two parameters — (a) high coding uplift and low marginal value of code, or (b) low coding uplift and high marginal value of code — are possible given that code output has increased by 8x.

In world (a), code and non-code are strong complements (roughly ). This means the researchers shift their time away from coding to other bottlenecks, and we only see code output 8× because code speedup is extremely high, at least 23x. This frees up so much time for non-code that researchers still achieve uplift of .

In world (b), code and non-code are near-perfect substitutes (); researchers spend almost all their time coding, because it’s more productive and substitutes for non-code tasks. But then an x code output increase means that researchers must have produced only x code per hour, because they have almost doubled their time spent coding. So uplift is still only .

In both cases, remains fairly close to .

The original post on the METR blog has an interactive version of this figure where you can vary , , and .

Why is relatively unaffected by after observing ? If we obtain an expression for and perturb it around : ^[7]

The bracketed term — which drives the percent difference between and — equals zero at . At , it equals — almost zero. So the first-order sensitivity of to is only per unit . The upshot: stays within ±3% of 2.83 for .

	implied	post-AI coding share
0.0	—	—	impossible ()
0.3	~114	3.5%	2.56
0.5	23.3	17%	2.75
0.7	12.5	32%	2.80
1.0	8.0	50%	2.83
1.5	5.7	70%	2.86
2.0	4.8	83%	2.91
3.0	4.2	95%	3.07

M = 8 also implies a lower bound on σ

Observing gives a -robust estimate of uplift, but it also constrains .

Recall that where

• is the coding uplift/​speedup

• is the quantity of time spent on coding

When , researchers shift time away from coding (), so the per-hour speedup must exceed to produce the observed 8× output. The smaller is, the larger must be — at , you need . A value of also implies that Anthropic researchers only spend 3.5% of their time coding in Q2 2026, which is implausibly low.

At (Leontief /​ perfect complements), the production function becomes , so output is bottlenecked by whichever input is scarcer. Even can only produce , so is flatly impossible. Intuitively: if non-code is a strict bottleneck, no amount of coding speedup can raise total code output by more than , the maximum increase in non-code output.

It is reasonable to believe that the per-hour coding speedup is <23× and Anthropic contributors now spend >17% of their time coding, which implies . This rules out strong complementarity between coding and non-coding research. We could refine this estimate further by measuring Anthropic’s time shares; if they are similar to pre-AI time shares, , whereas if they are higher or lower, the shift away from or towards code would mean lower or higher for the reasons in the previous section.

Code heterogeneity model: What if AI speeds up high-stakes code less?

The above model assumes all code is uniformly sped up. But it is probably true that AI speedup is higher on low-stakes code, which also tends to have lower value per LoC. We can model this by splitting code into low-stakes () and high-stakes () components. ^[8] The full definition of this model is in the appendix, but briefly, the outer layer is Cobb-Douglas between code and non-code, while the inner layer is CES between low- and high-stakes code, with being the pre-AI time share of low-stakes code as a fraction of all code.

If high-stakes code gets ¹⁄₃ the log-uplift: that is, , and we make other reasonable parameter choices, we get the following table:

(low-stakes share)
0.9	9.4	2.1	2.33
0.7	13.8	2.4	2.39
0.5	22.6	2.8	2.49
0.3	44.9	3.6	2.66
0.1	~139	5.2	3.08

We can reject any value of outside as implausible — low values would require , while high values would mean that >90% of researcher coding time pre-AI was spent on low-stakes tasks, which I find implausible given the prevalence of code review, large experiments, etc. in frontier AI research.

This model is still somewhat robust to , but not as much as the homogeneous CES model was to : at , varies by ±11% across instead of ±3%. (At it happens to vary by only ±2%, but at by ±17%.)

Caveats: How could Anthropic’s uplift be less than 2x?

I can think of five data and methodological issues that could meaningfully affect the results, of which three are plausible.

Plausible reasons

Verbosity

What if AI causes contributors to write more lines of code for the same functionality? In METR’s early-2025 uplift RCT, where open-source developers were randomly assigned AI and non-AI issues, developers wrote more lines of code when they were allowed to use AI. Specifically, for the 10 developers with both AI and non-AI issues, the geomean LoC added in completed PRs was somewhere between 1.22x and 2.57x as large (95% CI) for AI-allowed issues. Due to the wide CI and the differences between Claude 3.7 Sonnet/​o1 era AI and modern AI, we can’t prove anything about verbosity without further investigation. But if we assume that Anthropic’s verbosity factor is 1.83x (the sketchy central estimate), code output will still have increased x, and the code heterogeneity model with low-stakes share gives researcher uplift in the range — right around the 2x threshold.

The shape of the increase makes me think verbosity doesn’t affect the code output number by more than ~2x. In Q4 2025 (when Anthropic probably had access to Opus 4.5 and 4.6), LoC/​person was 2.5x baseline, but in Q1 2026 (Mythos Preview), it jumped to 5.8x. At 2.5x, the majority of code is already AI-written, and anecdotally Fable/​Mythos is not much more verbose than Opus, so the increase from 2.5x to 5.8x to 8.0x is mostly not verbosity. If the exponential trend in Anthropic’s per-capita code output continues, we should become less worried about verbosity because almost all code is already AI-written.

I’m not confident in any statement stronger than this, because verbosity is partly a function of coding uplift itself. E.g. if coding uplift is very high, researchers no longer have time to read any code, which could bloat it further.

Barely useful code

Verbosity means more LoC for the same functionality, but what if researchers are also writing more code with new functionality that doesn’t create much research progress? Tom Cunningham calls these Cadillac tasks, and their existence means that uplift on new tasks is always an overestimate of value uplift.

Anecdotally at METR, people generate lots of barely useful code they wouldn’t write by hand. Some examples:

• A project DAG visualizer for all the dependencies between tasks in the project

• A web interface to long-running agent runs backed by a remote dev instance

• Redoing a project’s entire stats methodology for one sanity check

Barely useful code is somewhat accounted for by CES (which has strongly diminishing marginal returns to code when ) so one should only discount uplift estimates further if there is some reason beyond CES that lots of barely-useful code is being produced. One factor could be irrational time allocation; another could be that it’s simply possible to write a larger volume of barely-useful code than CES predicts before the marginal value drops below one’s opportunity cost.

The utility of barely useful code can be bounded below, because most of us get less than 25x speedup on them, and therefore they’re at least 0.04x as valuable per unit time as the marginal core code we’d write by hand. Future modeling efforts could use this to get a more conservative lower bound for uplift.

Irrational time allocation, intrinsic desire to use AI, etc.

All modeling in this post assumed that researchers allocate their time between code and non-code, and between low- and high-stakes code, in a way that rationally maximizes research progress. This is a somewhat dubious assumption, because there are various other factors that determine time allocation: convenience, fun, organizational policy, irrational behavior, etc.

In the same study last year, METR found that open-source developers thought that AI had sped them up ~20%, even when AI had actually slowed them down by an average of ~20%. This particular effect is partially due to inexperience with AI, which does not apply to Anthropic contributors, but I can certainly believe that writing code is often more fun than it used to be, leading people to spend more time on it.

The impact of irrational time allocation on code output probably gets worse the larger uplift is, unlike verbosity, which is closer to a constant factor.

Unlikely reasons

Extreme heterogeneity

What if AIs are speeding up people enormously (>20x) on low-stakes code that makes up less than 25% of pre-AI coding time, and basically not at all on high-stakes code or non-code tasks?

I find this implausible because:

• Very little code is written by hand these days, so there must be some speedup from AI use.

• METR found that self-reported uplift among survey participants, which averaged over a wide range of engineers and researchers, was around 2x, and uplift was large enough that developer preferences to use AI precluded conducting an RCT to measure it.

Changing denominator

Anthropic’s graph says “active contributor” in the denominator means “a distinct author in the trailing twelve months”. This means that if random salespeople started coding, or Anthropic’s average talent level went down, they would bring the average down unless they wrote more code than the average engineer/​researcher. It is possible that the denominator has greatly shrunk over time e.g. if infrequent contributors have stopped coding, but this doesn’t seem likely.

Discussion

Prefer code output over code uplift, for estimating overall uplift

In the CES model, uplift estimates based on code uplift alone are not robust to , but estimates using code output are. The key reason is that code output takes into account marginal value of code, through time allocation changes. (The robustness is highest around output factor , but is always better for code output than code uplift.)

To the extent time allocation accurately reflects marginal value, code output is better than code uplift. It is susceptible to “irrational” changes in coding time allocation such as discussed above (which might make time allocation shift towards AI in the absence of marginal value changes); however, I expect these to be secondary drivers of code output. So overall, code output is probably a better metric than code uplift if we had to pick one. I expect that modeling overall researcher uplift from code uplift would have most of the same data issues as from code output, and not provide much advantage.

Why is Anthropic’s own estimate much lower?

The Mythos Preview system card (April 2026) stated that AI acceleration is “well short of a sustained, AI-attributable doubling of the overall pace of our AI progress. The acceleration is concentrated in engineering execution rather than research judgment.” Anthropic’s methodology for their claim of <<2x R&D speedup is not public, so I am not able to critique it, but the difference is probably just that we’re estimating different quantities.

Specifically, I estimate serial researcher uplift and they estimate overall R&D speedup, which also depends on compute and other resources. Ryan Greenblatt argues that R&D speedup could be roughly (serial labor acceleration)^0.55 × (compute)^0.45, in which case an R&D speedup of 2x would require 3.52x researcher uplift, and the 2.83x uplift consistent with the Cobb-Douglas model would mean 1.77x R&D uplift.

You might think that “only” 1.77x R&D uplift is reassuring. However, I would still find the overall situation rather alarming:

• If Anthropic’s overall R&D speedup is as insensitive to labor acceleration as Ryan’s estimate, Anthropic’s 2x threshold would not trigger unless researcher uplift is ~3.5x, which basically requires coding to be >90% automated.

• Compute is currently tripling every year. Even if AI R&D progress is mainly driven by compute rather than labor, tripling compute grows effective research input by ~1.6x per year (3x raised to compute’s ~0.45 share of research input). Combined with AI labor uplift that rises as models improve, both R&D inputs are growing exponentially, which under standard semi-endogenous production functions sustains exponential research output gains. If compute were to 8x in the next 2 years while researcher uplift reaches 3.52x, AI R&D progress would be 5.1x faster before hitting the threshold.

There are reasons to expect even higher uplift

• This analysis assumes — zero AI speedup on non-coding tasks. If AI also speeds up non-code research by even 1.3×, the Cobb-Douglas estimate rises from 2.83 to 3.22. Anthropic’s own survey put median self-reported output uplift at 4× in March 2026, which (even though we should discount self-report data) suggests AI is helping with more than just code.

• If Anthropic was producing 8x the lines of code during the first ~half of Q2, and lines of code is on an exponential trend, then code output would be even higher now at the end of Q2. Naively fitting an exponential gives over 10x code output for end of Q2.

Conclusion

Under a CES economic model with homogeneous code, the estimate is robust to code and non-code being complements or substitutes. For researcher uplift below 2×, you need at least one of the following:

• Verbosity: substantially overstates true quality-adjusted code output (e.g. perhaps AI code is >2x more verbose than human code for the same functionality).

• Barely-useful code: AIs are speeding up people enormously (>20x) on low-stakes code that would never have been written pre-AI, but is only 5%-20% as valuable as normal code.

• Researcher irrationality: Anthropic researchers are producing code that doesn’t contribute to research value (e.g. because vibe coding is fun).

Each of these is plausible to some extent, but researcher uplift below 2x would require very large effects from one or more of these factors, which I think is unlikely, and for the non-coding uplift from AI to be small. Therefore, my overall take is that researcher uplift at Anthropic from code agents alone is probably over 2×, with a reasonable central estimate being 2.5× or so.

Appendix: Heterogeneous code model

The outer layer is Cobb-Douglas (so total coding time stays at ), while the inner layer is CES between low- and high-stakes code:

where:

• is the value of code produced.

• and are the quantities of low-stakes and high-stakes code produced. We observe that .

• is the elasticity of substitution between low- and high-stakes code.

• is the fraction of pre-AI coding time on low-stakes tasks.

We make the following assumptions:

• (complements) because low- and high-stakes code are hard to substitute.

• High-stakes code gets ¹⁄₃ the log-uplift: .

The observed constrains via total code output (counting all lines equally), but it is the CES-aggregated code value — not the raw line count — that determines .

Inner time allocation. With inner CES, the post-AI fraction of coding time on low-stakes tasks is:

For (Cobb-Douglas inner), (no reallocation within coding).

What M measures. The observed code multiplier counts all lines of code equally:

Given , we solve numerically for .

Code value multiplier. The CES-aggregated value of code (post/​pre ratio) is:

Value uplift. Since the outer layer is Cobb-Douglas with :

The key distinction from the homogeneous model: measures raw code output, but value depends on the CES-weighted mix of low- and high-stakes code. When AI disproportionately speeds up low-stakes code, much of the 8× is low-stakes lines, so the value multiplier and .

---

Thanks to Tom Cunningham, Parker Whitfill, Neev Parikh, Nate Rush, Daniel Kokotajlo, and others for comments.

1. ↩︎

   e.g. Nate Rush commented this on an earlier draft: “I agree with your plausibility of single researcher 2x uplift. Directionally, I disagree with the size of the update you’ve made here based on a single metric—noting the size of the update you’ve made comes through more in our brief conversations than in this post. I have a general take of ‘in the early days of RSI, no single metric is going to tell us what’s going on fully’ position, and I feel like this post doesn’t really reflect that. I’d guess we disagree because I assign more credence to the limitations you post. If AI is 1.5x more verbose, and something like ~2x of the code is super low value (some of which is irrational), and we’re closer to 2.5x more real code—and then the argument falls apart. I also think questions about ‘what population this is defined over’ are more sus and less clearly not a big deal than you make them out to be.”

2. ↩︎

   Serial researcher uplift of X means AI is as useful as having all researchers operate at X times faster speeds for all activities. (Parallel researcher uplift would be that AI is as useful as X times as many researchers.)

3. ↩︎

   I say researchers in a number of places because Anthropic is a research company. If engineers for research infra are sped up by much more than researchers or something, conclusions wouldn’t really change (I would model it similarly to code heterogeneity), but if the uplift were concentrated in jobs that aren’t research at all, Anthropic’s research acceleration would be lower.

4. ↩︎↩︎

   Using the standard result that CES expenditure shares equal time shares at pre-AI prices.

5. ↩︎↩︎

   The relationship between total code output ratio , code uplift , and researcher uplift turns out to be . Derivation: A researcher’s total code output is , where is the time spent coding. The observed multiplier is the ratio of post-AI to pre-AI total code: , where is the post-AI coding time share. CES optimality gives . Substituting: . But from the formula for , we have . So .

6. ↩︎

   8 is the ratio of the total code output per contributor in Q2 2026 to the total code output per contributor in 2021-2024 (notably, this is not a claim about the median contributor’s code output).

7. ↩︎

   Unfortunately there is no closed form for in terms of .

8. ↩︎

   The actual landscape of tasks is continuous in both value and AI uplift, but this is too complicated to model here.

[Maxime Riché]

IMHO LLM verbosity is significantly higher than that of humans. Maybe producing 25-66% more lines of code for the same function. That’s when you include docstrings. If you also include skill files and extra/​low quality tests that would not have been created by humans, I would not be surprised if, for similar functionalities, LLMs produce 50-100% more lines than humans. For production code, humans may clean the AI-generated code to keep maintenance code low, but not nearly as much for research.

[Thomas Kwa]

I very much agree but with even wider uncertainty. Average verbosity could probably be anywhere from 1.25x to 2.5x depending on methodology, setting, etc and it would really narrow down our uncertainty if we knew.

One simple experiment to estimate verbosity would be to get a large sample of AI-written and human-written code, and tell AIs to delete as many useless lines of code in each as possible while preserving functionality. This gives us the average verbosity factor of AI vs human written code. If it’s high one could maybe rule out >3x research uplift already. Then we’d want to split these datasets by production vs research code, and after that use LLM judges to estimate the amount of barely useful code. There’s a huge amount of low hanging fruit here.

[Oliver Sourbut]

I think there’s a bit of a modus ponens/​modus tollens here, where you’re saying “surely they wouldn’t reallocate time suboptimally!” (so the observed allocation constrains parameters to imply meaningful uplift) while another might conclude “surely the substitutability isn’t that high!” (so the observed allocation must be ‘suboptimal’).

For my part, I think a fair bit (most) of the new code is ‘barely useful’ in the sense that it’s product code, stuff like claude code, cowork, etc. That’s actually ‘rational’ in the sense that it grabs market share and improves retention etc. Further, from individual contributors’ POV, code contribution is at least a bit reinforced since it’s such a legible metric (witness the internal and external headlines reporting on this!) but it’s a Goodhart proxy vs actual progress.

I’m still very unsure where it shakes out, but I really appreciate the key contributions from this analysis, which (to me) are to point out that under CES and some reasonable parameter assumptions, certain other parameters are quite constrained by what’s observed.

[Gordon Seidoh Worley]

To give some additional data here from the frontlines of using agents to write code, indeed we are producing a lot more code, but you’re right that overall productivity is up less than you’d expect. Beyond verbosity, which is an issue, there’s lots of changes now that are of marginal value that we wouldn’t have made before but are now cheap to do. Some examples include:

• automation of low-priority bug fixes and security vulnerabilities

• better internal tooling that solves minor annoyances

• gold-plating features that would otherwise have been MVPs

In fact, the main bottleneck I see right now is product ideation, not coding. That is, the main reason we can’t do more faster is we don’t have great product ideas faster. Instead, we can test more product ideas more quickly, but we find good ones about as often as before, we’re just able to validate more of these ideas in code for lower cost than we could have before.

[Oliver Sourbut]

Intuitively: if non-code is a strict bottleneck, no amount of coding speedup can raise total code output by more than

Phrasing confused me for a minute here. I think you mean assuming pre-speedup timeshare of non-coding is half, and assuming optimal reallocation of time toward research progress (which is maybe the same as assuming no wasted code, if code is not literally free), then under Leontief substitution you won’t observe more than double the code output.

[bhalstead]

The original post on the METR blog has an interactive version of this figure where you can vary,, and.

this link does not exist

[Thomas Kwa]

fixed