Measuring AI R&D Automation Beyond Coding: Analysis and Communication Evals

In this [https://epoch.ai/gradient-updates/toward-an-onet-for-ai-rnd] post, Epoch tries to define a O*NET for AI R&D by specifying various types of tasks and subtasks in the AI R&D cycle. We aim to use these tasks to build evaluations that directly inform us of AI R&D progress. They define 6 broad categories of work that researchers/engineers do at frontier AI companies:

1. Decide: what to work on, what to continue, where to allocate
2. Design: research ideas and engineering specs
3. Build: code and datasets
4. Run: training/eval runs, hardware, serving
5. Analyze: experiments, models, deployment, external work
6. Communicate: findings, feedback, status, decisions

In this project, we’re mainly going to focus on building tasks for the Analyze and Communicate categories. This is because: There exist a lot of evaluations for Build that cover software development and research engineering capabilities (SWE-bench, RE-Bench, METR Time Horizon) and the Decide and Design categories are heavily dependent on research taste, which is hard to measure and build tasks around Models currently seem to be quite bad at Analyze and Communicate, and these capabilities might bottleneck automated AI R&D. Currently, there doesn’t exist a good benchmark for this and it seems important to measure how fast models are improving here, and how exactly they fail As we move from a regime with majority human researchers to one with a majority of AI researchers, humans will likely remain in the loop (reviewing, approving, steering models), so the rate of safe AI progress is bottlenecked by the AI’s ability to effectively and truthfully communicate findings to humans. This is especially relevant for automated alignment research. Faithful communication based on ground-truth is closely related to oversight and trust. An AI R&D pipeline where the reports consistently overclaim or cherry-pick is one we cannot trust, which in itself is an important safety-relevant capability (effective communication) and propensity (willingness to be less faithful) to track.

Analyze Example task: We will take recent papers with released code and logs, and give models the experiment design and raw results (metrics, training logs, transcripts) and ask them to do the analysis: write up the key findings, make the plots that best answer the research question, or judge whether a surprising result is real. These can be scored against the known takeaways and plots from the paper and graded by human researchers or an LLM judge. We can also plant a realistic bug in the experiment (test-set contamination, a broken eval script, seed noise that looks like an improvement) and ask the model whether the headline result should be trusted. This is relevant for making better black-box monitors for research sabotage [https://www.lesswrong.com/posts/LByP4qsF8a4g7Pz3p/research-sabotage-in-ml-codebases]. Communicate Example task: Given a codebase and full experiment results, can models write a good report or paper? Does the report recover the key claims of the original writeup, whether it makes claims the data don't actually support, and whether blinded human experts prefer it to the original version. We can also measure communication abilities between teams of AI agents. For example: give the model a week of project output (commits, logs, partial results) and have it write a status update for another agent who will build on the work. Measure how well the second agent does as a proxy for the first agent’s communication skills

Measuring AI capabilities allows us to see how capable current AIs are at different tasks and allows us to forecast how capable they might be in the future which enables labs, policymakers, and the public to prepare in advance instead of reacting post-hoc, or not having enough time to react. We’re interested in measuring how different capabilities are improving at different rates [https://metr.org/blog/2025-07-14-how-does-time-horizon-vary-across-domains/], especially those relevant to AI R&D progress. By mapping how good AIs are at different tasks (SWE, more research based tasks, automating algorithmic improvements, etc) we can model how fast takeoff will be once we exceed a certain level of capability or forecast which capabilities might bottleneck progress.

Mentees will be the primary authors and drive the project's implementation. We expect them to work autonomously, which includes scoping and designing experiments, making their own implementation choices, and presenting results.

Our role will be to help them get unstuck and to give opinionated feedback (which directions are worth pursuing, which experiments are worth running, and how to interpret and write up results). We'll meet once a week and be responsive async.

Must haves: Proficiency with Python Has driven at least one LLM research project end-to-end Comfortable with rapid experimental iteration Familiar with popular AI Safety threat models and research agendas (can articulate a concrete threat model for a given scenario and reason about mitigations)

Nice to haves: Prior research experience (not necessarily ML research) Experience with Inspect Working knowledge of post-training and evaluations (RL environments, judging/rubrics, reward models)

You don’t need to meet all of these requirements to do good research. In general we value the willingness and ability to learn things fast more than prior knowledge and experience. Err on the side of applying, even if you don’t meet all requirements!