Stock Markets Priced a 32.6% AI Boost to Software Engineers. The GDP Effect Is 3.6%, or Half That

Stock prices say AI made software engineers the equivalent of 32.6% more productive between ChatGPT's launch and the end of 2025, permanently. That figure comes from a new NBER working paper, not from a stopwatch study of programmers, and the method is the whole story. Here is what it measures, what it cannot, and why the GDP number attached to it moves around far more than the headline suggests.

A productivity reading taken from stock returns

The paper is NBER Working Paper 35793, "The Macroeconomic Effect of AI: Sizing the Software Engineering Channel," by Alex Blumenfeld (UC Berkeley), Jonathon Hazell (London School of Economics), Chen Lian and Andreas Schaab (both UC Berkeley and NBER). NBER released it on September 28, 2026.

The logic runs in two steps. [Fact] First, the authors estimate how sensitive each company's weekly stock return is to an AI stock index, the ROBO Global Artificial Intelligence index (ticker THNQ), after stripping out the standard Fama-French market, size and value factors. Second, they ask whether companies that spend more of their payroll on software engineers react more strongly to AI news. Payroll shares come from Revelio Labs' employee-level data for 2021, the year before the stock panel begins.

The design choice that matters most: the sample is companies that use software engineers, not companies that sell software. [Fact] Software producers, semiconductor supply-chain firms, financial firms and the AI index's own holdings are removed. The software-heavy firms left in include eBay, Sonos, Expedia and Airbnb. If AI makes engineering cheaper per unit of output, those firms' costs fall more, investors expect more profit, and their prices move first.

[Fact] That is what the data show. In the baseline specification, a firm whose software engineering payroll share is one percentage point higher gains 1.24 basis points more when the AI index rises one percentage point. A structural model converts that slope into productivity. The result: news about AI from November 2022 to December 2025 raised the market's expected present value of software engineering productivity by the equivalent of a permanent 32.6% increase. The authors note this is in the same range as the 21% to 56% task-level speed-ups found in coding experiments.

From 32.6% to 3.6%: most of the gap is one number

[Fact] The paper puts the GDP effect at 3.6% in the baseline and 6.5% when faster software engineering also speeds up research and development.

Why is the GDP figure roughly a ninth of the productivity figure? One parameter explains nearly all of it. [Fact] The baseline calibration gives software engineering a cost-based weight of about 0.111 in the economy. [Estimate] Multiply 32.6% by 0.111 and you get 3.6%. To a first approximation, the GDP result is the productivity gain times the share of the economy's costs that goes to software engineers. The authors also solve the full nonlinear model, and that nudges the figure only from 3.61% to 3.84%.

The weight is not a fact of nature. [Fact] A footnote reports an alternative calibration based on the Occupational Employment Statistics, where the share is about 0.053. Under it, the productivity gain is 33.6% and GDP rises only about 1.77%. [Estimate] Same stock data, same regression, nearly the same productivity number, and the GDP effect is cut in half depending on how you count who is a software engineer.

Where the estimate is softer than the headline

Three details from inside the paper get less attention than the abstract.

One assumption swings the answer by more than 2x. [Fact] The most influential parameter is σ, how easily firms substitute between software engineers and other workers. The baseline sets it at 1.6, borrowed from a study of Korean firm-level data. At σ = 1, the productivity gain falls to 22.5%; at σ = 0.5, it falls to 14.0%. [Estimate] Applying the same 0.111 weight, those cases imply GDP effects of roughly 2.5% and 1.6%, against 3.6% in the baseline. That is our linear approximation, not a figure from the paper's table.

The statistical band is wide. [Fact] Under a bootstrap that resamples both weeks and firms, the standard error on the 1.24 slope is 0.47, versus 0.26 in the main table. The coefficient still clears conventional thresholds. [Estimate] Because the productivity figure scales directly with the slope, a conventional 95% interval of about 0.32 to 2.16 would put the 32.6% anywhere from roughly 8% to 57%. The point estimate is the middle of a broad range.

The top tail carries the result. [Fact] When firms are split into quintiles of software intensity, the extra AI sensitivity shows up in the top quintile and, to some extent, the fourth. Moving from 2-digit to finer 3-digit industry controls lowers the slope from 1.91 to 1.24. [Estimate] That is a 35% drop from one change of controls. The relationship survives, but a good part of the raw correlation was industry.

What it says about jobs, and what it does not

The paper is about productivity, not employment. That boundary is easy to lose in a headline.

[Fact] In the baseline model, labor endowments are fixed: the number of software engineers does not move. The model cannot tell you whether any given developer keeps a job. In a task-based extension, the authors let AI replace software engineering labor on some digital tasks while software suppliers grow more productive, and the productivity and GDP numbers stay largely unchanged. They also cite separate research (Brynjolfsson et al., 2026; Hosseini Maasoum and Lichtinger, 2026) finding large hiring declines for young and junior workers in exposed occupations.

Now the counter-intuitive part. [Fact] In the exact solution, the productivity gain makes software engineering cheaper in effective terms, firms use more of it, and its cost weight in the economy rises from 0.111 to 0.125. [Claim] When engineering and other work are substitutes, cheaper engineering output pulls more spending toward engineering, not less. [Estimate] Push σ below 1, the complementarity case the paper also reports, and that pull weakens. The hopeful reading for software workers rests on the same parameter that already moves the headline by more than 2x.

The plain limit: [Claim] a stock market expectation is not a measurement of work. The authors write that the market view "is unlikely to be perfectly accurate." A price run-up driven by enthusiasm would register here as expected productivity. And the paper's own literature review cites Demirer et al. (2026): large gains in coding activity translated into smaller increases in projects and releases, and no detectable rise in consumer use of new apps.

The 2026 jump

[Fact] Because it is built from prices, the measure updates weekly. News in the first half of 2026, as coding agents such as Claude Code and Codex spread, produced expected productivity gains larger than the previous three years combined. By mid-2026, the effect on productivity and GDP had more than doubled relative to the end of 2025.

[Estimate] More than double 32.6% means above 65% in present-value terms, and a baseline GDP effect above roughly 7%. The abstract gives no single mid-2026 figure, so we are not inventing one.

For scale, [Fact] Acemoglu (2025) estimated total factor productivity gains of 0.53% to 0.66% over a decade across all AI channels combined, while Aghion and Bunel (2024) estimated 6.8% to 13%. The paper's 3.61%, from the software channel alone and only through end-2025, sits between them. [Estimate] It is about five times Acemoglu's upper figure.

A disclosure: this article was drafted with an Anthropic model, and Claude Code is one of the two tools the paper names alongside the 2026 jump. We have no relationship with the authors.

What this means if you write software

• Investors are pricing a fast rise in output per engineer, and in the first half of 2026 that bet grew faster than in the three years before it. That is pressure on how engineering work is organized. It is not, by itself, a forecast of headcount.
• If you work at a company that uses software rather than sells it (travel, retail, consumer electronics), you are in exactly the population this paper measures. Those employers' valuations are now tied to how much engineering they can get out of AI tools.
• The model leans on engineering and other work being substitutes. Roles where engineering meets product and business judgment sit on the complement side, which is the part this method prices least well. [Claim]

For occupation-level data, see our pages on software developers, computer programmers and web developers.

Sources

• Alex Blumenfeld, Jonathon Hazell, Chen Lian and Andreas Schaab, "The Macroeconomic Effect of AI: Sizing the Software Engineering Channel," NBER Working Paper 35793, September 2026: https://www.nber.org/papers/w35793

About this analysis

This article was written with AI assistance. The abstract figures (32.6%, 3.6%, 6.5% and the mid-2026 doubling) are from NBER's published abstract. Method details, the 1.24 slope, the σ sensitivity, the bootstrap standard error, the 0.111 and 0.053 weights and the 0.125 exact-model weight were read from the authors' posted version of the paper dated September 14, 2026, whose abstract matches NBER's word for word; the NBER PDF itself is gated for non-subscribers and we did not read it. Figures labeled [Estimate] (the 32.6 × 0.111 decomposition, GDP effects under alternative σ, the 8% to 57% band, the 35% slope drop and the mid-2026 lower bound) are our own arithmetic, not the authors'. No figures or charts from the paper are reproduced.