惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Security Archives - TechRepublic
Security Archives - TechRepublic
Project Zero
Project Zero
K
Kaspersky official blog
G
Google Developers Blog
T
Threat Research - Cisco Blogs
T
The Blog of Author Tim Ferriss
Cyberwarzone
Cyberwarzone
Y
Y Combinator Blog
Recorded Future
Recorded Future
Blog — PlanetScale
Blog — PlanetScale
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Cisco Talos Blog
Cisco Talos Blog
Latest news
Latest news
Microsoft Security Blog
Microsoft Security Blog
H
Help Net Security
S
Schneier on Security
P
Palo Alto Networks Blog
H
Hacker News: Front Page
N
News and Events Feed by Topic
N
Netflix TechBlog - Medium
博客园 - Franky
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
SecWiki News
SecWiki News
Cloudbric
Cloudbric
TaoSecurity Blog
TaoSecurity Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
The Hacker News
The Hacker News
C
Check Point Blog
L
LangChain Blog
腾讯CDC
小众软件
小众软件
T
Tenable Blog
Google DeepMind News
Google DeepMind News
GbyAI
GbyAI
L
LINUX DO - 最新话题
A
About on SuperTechFans
Google Online Security Blog
Google Online Security Blog
C
Cisco Blogs
Recent Announcements
Recent Announcements
Hacker News: Ask HN
Hacker News: Ask HN
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Vercel News
Vercel News
雷峰网
雷峰网
美团技术团队
D
DataBreaches.Net
Martin Fowler
Martin Fowler
Help Net Security
Help Net Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
F
Full Disclosure
博客园_首页

METR

Summary of METR's predeployment evaluation of GPT-5.6 Sol Frontier AI Safety Policies Frontier Risk Report (February to March 2026) 前沿 AI 风险报告(2026 年 2–3 月) Informe de riesgos de la IA de frontera (febrero–marzo de 2026) Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity Task Substitution and Uplift Review of the "Risks from automated R&D" section in the Anthropic Risk Report (February 2026) Evidence on AI R&D Progress from NanoGPT MirrorCode: Evidence that AI can already do some weeks-long coding tasks Fine-tuning experiments on CoT controllability Red-Teaming Anthropic's Internal Agent Monitoring Systems Impact of modelling assumptions on time horizon results We spent 2 hours working in the future Review of the Anthropic Sabotage Risk Report: Claude Opus 4.6 Many SWE-bench-Passing PRs Would Not Be Merged into Main Observations from two CLI game reimplementation runs with Opus 4.6 We are Changing our Developer Productivity Experiment Design Five lessons from having helped run an AI-Biology RCT How We Protect Confidential Information Analyzing coding agent transcripts to upper bound productivity gains from AI agents Measuring Time Horizon using Claude Code and Codex A simpler AI timelines model predicts 99% AI R&D automation in ~2032 Frontier AI safety regulations: A reference for lab staff 前沿 AI 安全法规:AI 公司员工参考指南 Regulación de seguridad de IA de frontera: una referencia para el personal de laboratorios Time Horizon 1.1 Clarifying limitations of time horizon Early work on monitorability evaluations Common Elements of Frontier AI Safety Policies (December 2025 Update) Details about METR's evaluation of OpenAI GPT-5.1-Codex-Max Review of the Anthropic Summer 2025 Pilot Sabotage Risk Report Summary of our gpt-oss methodology review MALT: A Dataset of Natural and Prompted Behaviors That Threaten Eval Integrity Early Results on Monitorability in QA Settings Claude, GPT, and Gemini All Struggle to Evade Monitors Forecasting the Impacts of AI R&D Acceleration: Results of a Pilot Study Research Update: Algorithmic vs. Holistic Evaluation Notes on Scientific Communication at METR CoT May Be Highly Informative Despite “Unfaithfulness” Details about METR's evaluation of OpenAI GPT-5 How Does Time Horizon Vary Across Domains? Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity What should companies share about risks from frontier AI models? Details about METR's preliminary evaluation of DeepSeek and Qwen models Recent Frontier Models Are Reward Hacking Details about METR's preliminary evaluation of OpenAI's o3 and o4-mini Details about METR's preliminary evaluation of Claude 3.7 HCAST: Human-Calibrated Autonomy Software Tasks Measuring AI Ability to Complete Long Tasks Response to OSTP on AI Action Plan Why it’s good for AI reasoning to be legible and faithful 为什么 AI 推理应当可读,并如实反映模型的实际决策过程 Por qué conviene que el razonamiento de la IA sea comprensible y fiel Details about METR's preliminary evaluation of DeepSeek-R1 METR’s GPT-4.5 pre-deployment evaluations Measuring Automated Kernel Engineering Details about METR's preliminary evaluation of DeepSeek-V3 An update on our preliminary evaluations of Claude 3.5 Sonnet and o1 AI models can be dangerous before public deployment Evaluating frontier AI R&D capabilities of language model agents against human experts The Rogue Replication Threat Model Response to Bureau of Industry and Security’s proposed AI reporting requirements New Support Through The Audacious Project Details about METR's preliminary evaluation of OpenAI o1-preview Response to U.S. AISI Draft “Managing Misuse Risk for Dual-Use Foundation Models” Vivaria Details about METR's preliminary evaluation of GPT-4o An update on our general capability evaluations Response to NIST Draft Generative AI Profile ML Engineers Needed for New AI R&D Evals Project Emma Abele is METR’s new Executive Director Autonomy Evaluation Resources Example autonomy evaluation protocol Guidelines for capability elicitation Measuring the impact of post-training enhancements GitHub - METR/public-tasks Portable Evaluation Tasks via the METR Task Standard 2023 Year In Review Bounty: Diverse hard tasks for LLM agents ARC Evals is now METR Responsible Scaling Policies (RSPs) 负责任扩展政策(RSP) Políticas de escalamiento responsable (RSP) ARC Evals is spinning out from ARC New report: Evaluating Language-Model Agents on Realistic Autonomous Tasks Response to RfC on AI Accountability Policy Update on ARC's recent eval efforts
Because 8 ≈ e², Anthropic's researcher uplift is plausibly >2x
METR · 2026-07-08 · via METR

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 uplift2?

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 \(\beta=50\%\) and code output increases by a factor \(M=8\), then researcher uplift is \(M^\beta = 2.83\).
  • CES (constant elasticity of substitution) production functions, due to a fun mathematical coincidence, infer a narrow range of about \([2.75, 2.91]\) 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 \([2.33, 2.66]\), 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: \(M\) 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 researcher3 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 \(Y\) as:

\[Y = q_n^\beta q_o^{1-\beta}\]

where:

  • \(\beta\) is the time share on coding4
  • \(q_n\) and \(q_o\) are the quantities of code and non-code produced.

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

\[U = M^\beta\]

If researchers spend roughly half their time coding (\(\beta = 0.5\)), then \(U = \sqrt{8} \approx 2.83\). (\(\beta=0.5\) is roughly the median of what people I ask find reasonable. I have substantial uncertainty about \(\beta\), 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 \(T\) across two task types: coding and non-coding. We assume the output \(Y\) follows the CES function:

\[Y = [\beta \, q_n^{\,\rho} + (1-\beta) \, q_o^{\,\rho}]^{1/\rho}, \quad \rho = \frac{\sigma - 1}{\sigma}\]

where:

  • \(\beta\) is the pre-AI time share on coding4 (in CES, it is possible for time shares to change between the pre-AI and post-AI periods);
  • \(q_n\) and \(q_o\) are the quantities of code and non-code produced.
  • \(\sigma\) is the elasticity of substitution between coding and non-coding output.

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

\[U = [\beta \, g_n^{\,\sigma-1} + (1-\beta)]^{1/(\sigma-1)}\]

where \(g_n\) is the per-hour speedup AI provides on coding, which we will refer to as the coding uplift.5

We don’t directly observe \(g_n\). We observe \(M = 8\), the mean code output increase of Anthropic contributors.6 (These differ because researchers reallocate time when AI makes coding cheaper.) It turns out that \(M\), \(U\), \(\sigma\), and \(g_n\) are related by a fairly simple equation \(M = \frac{g_n^\sigma}{U^{\sigma-1}}\),5 and observing \(M\) gives a fairly robust estimate for \(U\).

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

In Cobb-Douglas, we assumed that code and non-code have unit substitutability (\(\sigma=1\)). What if they’re complements (\(\sigma < 1\)) or substitutes (\(\sigma > 1\))? 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 \(g_n\) and marginal value of code (which is increasing in \(\sigma\)). 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 \(g_n\) and \(\sigma\) were both small, then output \(M\) 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 \(\sigma < 0.5\)). 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 \(U=2.75\).

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

In both cases, \(U\) remains fairly close to \(M^\beta = 2.83\).

Why is \(U\) relatively unaffected by \(\sigma\) after observing \(M\)? If we obtain an expression for \(\ln U\) and perturb it around \(\sigma = 1\):7

\[\Delta \ln U \approx \beta(1-\beta)\left[-\ln M + \frac{(\ln M)^2}{2}\right](\sigma - 1)\]

The bracketed term — which drives the percent difference between \(U\) and \(M^\beta\) — equals zero at \(M = e^2 \approx 7.39\). At \(M = 8\), it equals \(-2.08 + 2.16 = 0.08\) — almost zero. So the first-order sensitivity of \(\ln U\) to \(\sigma\) is only \(0.25 \times 0.08 = 0.02\) per unit \(\sigma\). The upshot: \(U\) stays within ±3% of 2.83 for \(\sigma \in [0.5, 2]\).

\(\sigma\) implied \(g_n\) post-AI coding share \(U\)
0.0 impossible (\(M \leq 2\))
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 \(M = 8\) gives a \(\sigma\)-robust estimate of uplift, but it also constrains \(\sigma\).

Recall that \(M = g_n \cdot \frac{t_n^{\text{postAI}}}{t_n^{\text{preAI}}}\) where

  • \(g_n\) is the coding uplift/speedup
  • \(t_n\) is the quantity of time spent on coding

When \(\sigma < 1\), researchers shift time away from coding (\(\frac{t_n^{\text{postAI}}}{t_n^{\text{preAI}}} < 1\)), so the per-hour speedup \(g_n\) must exceed \(M\) to produce the observed 8× output. The smaller \(\sigma\) is, the larger \(g_n\) must be — at \(\sigma = 0.3\), you need \(g_n \approx 114\). A value of \(\sigma = 0.3\) also implies that Anthropic researchers only spend 3.5% of their time coding in Q2 2026, which is implausibly low.

At \(\sigma = 0\) (Leontief / perfect complements), the production function becomes \(Y = \min(\beta \, q_n, \, (1-\beta) \, q_o)\), so output is bottlenecked by whichever input is scarcer. Even \(g_n \to \infty\) can only produce \(M = 1/(1-\beta) = 2\), so \(M = 8\) is flatly impossible. Intuitively: if non-code is a strict bottleneck, no amount of coding speedup can raise total code output by more than \(1/(1-\beta)\), 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 \(\sigma \geq 0.5\). 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, \(\sigma \approx 1\), whereas if they are higher or lower, the shift away from or towards code would mean lower or higher \(\sigma\) 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 (\(L\)) and high-stakes (\(H\)) 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 \(\alpha\) being the pre-AI time share of low-stakes code as a fraction of all code.

If high-stakes code gets 1/3 the log-uplift: that is, \(g_{\text{high}} = g_{\text{low}}^{1/3}\), and we make other reasonable parameter choices, we get the following table:

\(\alpha\) (low-stakes share) \(g_{\text{low}}\) \(g_{\text{high}}\) \(U\)
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 \(\alpha\) outside \([0.3, 0.9]\) as implausible — low values would require \(g_{\text{low}} > 44.9\), 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 \(\sigma_{LH}\), but not as much as the homogeneous CES model was to \(\sigma\): at \(\alpha = 0.9\), \(U\) varies by ±11% across \(\sigma_{LH} \in [0.5, 2]\) instead of ±3%. (At \(\alpha = 0.5\) it happens to vary by only ±2%, but at \(\alpha = 0.3\) 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 \(8/1.83 \approx 4.4\)x, and the code heterogeneity model with low-stakes share \(\alpha \in [0.3, 0.9]\) gives researcher uplift in the range \([1.84, 2.08]\) — 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 \(\sigma \ll 1\)) 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 \(\sigma\), 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 \(M \approx e^2\), 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 \(g_o = 1\) — 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 \(U \approx M^\beta \approx 2.8\) 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: \(M\) 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 \(\beta=50\%\)), while the inner layer is CES between low- and high-stakes code:

\[Y = V_{\text{code}}^{\,\beta} \cdot q_o^{\,1-\beta}, \qquad V_{\text{code}} = [\alpha \, q_L^{\,\rho} + (1-\alpha) \, q_H^{\,\rho}]^{1/\rho}, \quad \rho = \frac{\sigma_{LH} - 1}{\sigma_{LH}}\]

where:

  • \(V_{\text{code}}\) is the value of code produced.
  • \(q_L\) and \(q_H\) are the quantities of low-stakes and high-stakes code produced. We observe that \(M = (q_L^{\text{postAI}} + q_H^{\text{postAI}}) / (q_L^{\text{preAI}} + q_H^{\text{preAI}}) = 8\).
  • \(\sigma_{LH}\) is the elasticity of substitution between low- and high-stakes code.
  • \(\alpha\) is the fraction of pre-AI coding time on low-stakes tasks.

We make the following assumptions:

  • \(\sigma_{LH} = 0.5\) (complements) because low- and high-stakes code are hard to substitute.
  • High-stakes code gets 1/3 the log-uplift: \(g_{\text{high}} = g_{\text{low}}^{1/3}\).

The observed \(M = 8\) constrains \(g_{\text{low}}\) via total code output (counting all lines equally), but it is the CES-aggregated code value \(V_{\text{code}}\) — not the raw line count — that determines \(U = V_{\text{code}}^{\,\beta}\).

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

\[s_L = \frac{\alpha \, g_{\text{low}}^{\,\sigma_{LH}-1}}{\alpha \, g_{\text{low}}^{\,\sigma_{LH}-1} + (1-\alpha) \, g_{\text{high}}^{\,\sigma_{LH}-1}}\]

For \(\sigma_{LH} = 1\) (Cobb-Douglas inner), \(s_L = \alpha\) (no reallocation within coding).

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

\[M = g_{\text{low}} \cdot s_L + g_{\text{high}} \cdot (1 - s_L)\]

Given \(M = 8\), we solve numerically for \(g_{\text{low}}\).

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

\[V = \frac{[\alpha \, (g_{\text{low}} \cdot s_L)^\rho + (1-\alpha) \, (g_{\text{high}} \cdot (1-s_L))^\rho]^{1/\rho}}{[\alpha^{1+\rho} + (1-\alpha)^{1+\rho}]^{1/\rho}}\]

Value uplift. Since the outer layer is Cobb-Douglas with \(g_o = 1\):

\[U = V^\beta\]

The key distinction from the homogeneous model: \(M = 8\) 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 \(V < M\) and \(U < M^\beta\).


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