Economic Scenarios for Transformative AI

Three layers to understand the paper

Open Output

The effects on the economy →

A precomputed grid over the paper's seven scenario dials: 4374 combinations, three levels per dial and six for reinstatement (the new labor tasks that appear for each one automated, carried past the paper's range), with eleven 2030 outcomes that update as you move them.

Open Analysis

The paper's claim and machinery, opened up in two forms: read in full, or taught step by step.

The full reproduction →

The paper's sections in order, every equation explained and recomputed, with the code folded beside each table. All 169 cells of published Tables 3, 5 and 6 reproduce cell by cell; sixteen of them round to a different printed digit (details below).

Teaching materials →

A slide deck designed to teach the paper's main components, to yourself or to others: the claim, the theory, the machinery and the results, walked equation by equation. Cross-linked into the report for the equations it walks through in detail.

Open Materials

Every script, test and CSV →

The model, the 129-test validation suite and every exported CSV. The model is standard library only, no numpy and no scipy; the tests add pytest, and nothing else is needed to check any number on this site.

What the model says

The paper's three scenarios, at the start of 2030. Every figure is a gap against the same US economy without AI, which grows at its ordinary 2 percent a year: "8.3 percent" means 8.3 percent above that path, not 8.3 percent of growth. The workforce is split in two, the AI-sensitive occupations whose tasks AI is assumed to touch and all other occupations.

Those are the paper's numbers, from its Table 3. This reproduction recomputes every one of them from the printed equations, and the four rows above come back as 1.61 / 8.28 / 32.42, 0.69 / 2.14 / 9.65, 2.91 / 4.50 / 17.89 and 59.41 / 56.10 / 45.21. Nothing in the model assigns the three scenarios probabilities, so the spread between them is the result, not any one column. The table is the four rows of the paper's Table 3 that carry the gains and losses (output, pay, joblessness, the split of income), at the paper's own three settings, so its format is the paper's, not this project's. This project did not pre-specify it: there is no timestamped record of the format from before the reproduction ran.

What reproduces

"Within test tolerance" means the reproduced value sits within 0.05 percentage points of the published one for Table 3, widened to 0.10 where the published value is 10 or larger, and within the larger of 0.12 points and 0.4 percent of the published value for Tables 5 and 6; the two Table 3 cells that need it widened get 0.09 points. Rounding to the printed digit is a stricter test, which is why the two are counted separately above.

The repository README lists the sixteen cells that round to a different digit and sets out the readings the paper leaves implicit. A coverage note tracks the paper's reception: press, commentary and any revisions.

How AI was used in this exercise, and what has been verified

This reproduction was a collaboration between the author and Claude Code (Opus and Sonnet models) across many sessions, not an AI working alone. The table records who led the work on each public object, using the CRediT contributor roles, as the author answered them in a questionnaire on 2026-09-23 rather than as inferred from commit history. It groups the 14 roles into three: ideas and direction (conceptualization, methodology, supervision, project administration), doing the work (data curation, formal analysis, investigation, software, validation, visualization) and writing (original draft, review and editing); funding and resources do not apply. Each square in a cell is one role, coloured by who led it (key below the table). The last column, not part of CRediT, is how closely the author has checked the object himself. The role-by-role answers are in CREDIT.md.

Human verification uses three levels: no human review, lightly checked (checked, but the author cannot yet explain it clearly) and understood (he can explain it to others). Separately, the repository contains and runs 129 automated tests: 102 core tests behind Tables 3, 5 and 6, the prose checks and the identities the equations imply, which the report and the slides share because they present the same numbers; 7 that pin the explorer's precomputed grid to the model; 16 that recompute the numbers typed into the explorer and deck prose; and 4 for the slop.py extension, which sits outside the reproduction. Continuous integration runs them on every push to GitHub, on a clean machine, and also rebuilds the explorer's grid and fails if the committed copy differs.

The equations and parameters behind those numbers were transcribed from the paper's PDF by AI into aiscen/. The author reviewed them as they are presented in the report and the deck, not in the code itself; they have not been checked against the paper by a second, independent reader, or confirmed with the paper's authors. Where the paper's text left a modelling choice implicit, the reading adopted here was chosen for internal consistency (see the README).

A separate question, with weaker evidence behind it, is whether the author can explain each object unaided, without relying on the AI's own explanation of it, tracked in a private running record. As of the most recent update he rates himself able to do that for the explorer, for the report's framing, claims and results, and for the slides' month-by-month numerical solution, but not yet for the equation-by-equation derivation behind the report and the slides alike, or for the internal layout of the code in aiscen/. Mechanical verification confirms the numbers match; it does not by itself confirm he has independently worked through why they should.

The automated tests are mechanical checks, not an outside review: no other person has verified any of this, though several independent AI review passes have audited the site for consistency.