AI Futures Added Revenue to Its Coder Forecast

AI Futures Project has changed what its short-timelines forecast is trying to explain. Its 16 August update still uses the length of software tasks that frontier systems can complete, but now checks that trajectory against two more observable quantities: the productivity uplift developers receive and the annualised revenue of a leading model developer.

In brief, for the window from 16 August 09:00 to 17 August 09:00 in Tehran:

• The project shortened its central timelines slightly after updating its evidence and model.
• Coding-task duration remains the main anchor; uplift and revenue are new cross-checks, not independent measurements of intelligence.
• The published numbers are scenario outputs built from explicit assumptions, not a prediction that autonomous coding is certain by a particular date.
• For finance and operations teams, the practical advance is the three-signal method. The practical risk is treating correlated commercial and benchmark measures as confirmation.

The update is useful because it exposes more of the bridge between technical progress and economic consequence. It is also easy to overread. Revenue can rise because of price, distribution, inference demand or product mix. Measured uplift can change with the worker, repository and task. A forecast becomes more auditable when it names those assumptions, but not automatically more accurate.

The evidence clock

The only material event in this brief is the new forecast update. The comparison studies below pre-date the reporting window and are included to test its assumptions, not presented as fresh announcements.

AI Futures published “Q2.5 2026 Timelines Update: Uplift and Revenue” on 16 August 2026, inside this brief’s locked window. The authors also linked their current forecast spreadsheet and the wider AI Futures Model, allowing readers to separate stated inputs from narrative conclusions.

What changed in the forecast

Earlier versions concentrated on “time horizon”: how the duration of software tasks that models can complete at a given reliability grows over time. The update retains that spine but adds two checks.

First, an uplift model translates capability into how much faster or more valuable a developer becomes with AI assistance. The post illustrates one author’s median assumptions with present uplift around 2×, a five-month doubling period after an “uplift of one”, and a long-run autonomous-coder uplift of 20×; its fuller model yields 32× under the cited settings. Those are parameters attributed to the forecaster, not measured industry averages.

Second, a revenue model fits annualised revenue for a leading model developer against Epoch’s capability index. The authors assume very rapid present revenue growth—roughly 5× to 7× a year—then ask whether the commercial curve is compatible with the technical one. They explicitly note that inference allocation, margins and a potentially non-exponential relationship can distort the fit.

The authors say the combined update makes their timelines “slightly shorter”. Their scenario examples place autonomous coding around mid-2027 if progress continues at 75% of the pace in their AI 2027 scenario, and around early 2028 at 60%. These dates are conditional extrapolations. They depend on technical feasibility, continued progress, model retraining and the absence of a policy or resource-driven slowdown.

Why three anchors are better than one

A single benchmark family can be internally consistent and still miss the operational question. Adding different observables creates opportunities for contradiction:

• If task horizons expand but controlled worker uplift stays flat, benchmark generalisation may be weak.
• If uplift rises without corresponding customer value, gains may be concentrated in low-value work.
• If revenue accelerates while capability measures stall, distribution, pricing or inference volume may be doing the work.
• If revenue stalls while task and uplift measures improve, supply constraints, adoption friction or falling prices may dominate.
• If all three move together, the model becomes more coherent, though not necessarily independently confirmed.

That is the strongest contribution of the update. It gives forecasters, buyers and investors a common reconciliation problem instead of one seductive curve. The same discipline matters in production evaluation: our guide to blind AI release tests explains why a result should survive a measurement channel the system was not optimised against.

The method also makes disagreements more productive. A critic can challenge the uplift ceiling, the revenue-to-capability mapping or the pace multiplier separately. A board does not need to accept the final date to use the model as an assumption register.

Coding uplift remains a fragile measure

“Twice as productive” sounds precise but can refer to elapsed time, accepted output, economic value or subjective usefulness. Each denominator changes the conclusion.

METR’s 24 February 2026 uplift update is an important caution. Its early-2025 randomised study found experienced open-source developers taking about 20% longer with then-current AI tools. A later experiment was affected by selection and other measurement problems, so METR did not present it as a clean update to the causal estimate. That is evidence about study difficulty, not evidence that today’s tools necessarily slow developers.

METR’s 11 May 2026 AI-usage survey found 349 technical workers reporting roughly 1.4× to 2× value and around 3× speed on selected tasks. METR also stressed the convenience sample, an email response rate near 2%, and the gap between self-report and experimental measurement. Survey respondents who use AI heavily are not a random sample of all work.

An operational uplift estimate therefore needs at least:

• a fixed unit of work and acceptance criterion;
• comparable developers or within-person randomisation;
• time spent reviewing, repairing and integrating output;
• failures, security defects and rework after the initial completion;
• the share of work where the system was not used; and
• a value measure that does not reward producing more low-priority code.

Teams should retain task-level evidence and calibration data rather than compressing every workflow into one multiplier. The controls in our LLM-as-a-judge calibration guide are relevant whenever automated scoring contributes to the claimed uplift.

Revenue is an economic signal, not a capability meter

Revenue has one advantage over a synthetic score: somebody paid. It can reveal that a capability is usable, distributed and valuable enough to clear a budget. For a finance audience, that is a meaningful constraint.

But revenue is a compound output. It equals some mixture of users, usage, prices, product bundles, channel reach, compute availability, contract timing and accounting treatment. Annualised revenue can move before recognised revenue, and neither directly identifies gross margin or cash generation. A developer may also sell several model generations and non-model services at once.

The forecast post acknowledges several of these confounders. Its revenue fit should therefore be read as a consistency check: would the assumed capability path make the observed commercial scale surprising? It should not be read backwards as “revenue proves this capability level”.

This distinction matters most when a forecast enters valuation or capacity planning. A high growth assumption can simultaneously shorten a model’s implied timeline and increase the capital required to serve demand. Prepayments and long-duration infrastructure commitments can make reported growth look operationally secure while creating concentration and execution risk. Our analysis of AI capacity prepayments and deployment gaps sets out those balance-sheet questions.

Apparent convergence is not independence

Three lines can agree because they share the same underlying source. Coding benchmarks affect product claims; product claims affect adoption; adoption affects revenue. Stronger models also help generate benchmark solutions and software output, while customer enthusiasm can influence survey reporting. These are causal links, not statistical independence.

The revenue series in the update is fitted to the Epoch Capabilities Index, which aggregates benchmark evidence. The time-horizon and uplift models also concern coding capability. Agreement among them is informative, but all three remain exposed to model-release cadence, benchmark saturation and the concentration of measured work in software.

A robust forecast review should ask:

• Which observations are direct measurements and which are author-chosen parameters?
• Which signals share models, benchmarks, customers or publication sources?
• How sensitive is the date to one slower quarter or a revised uplift ceiling?
• Does retraining delay the application of software improvements?
• What happens if inference price falls faster than paid usage grows?
• Which result would cause the forecaster to lengthen, rather than shorten, the timeline?

The update itself notes that retraining is required before some software improvements affect the next model. That lag constrains very fast feedback loops and is a useful reminder that a code improvement is not instantly a deployed capability gain.

What operators and finance teams should do now

The publication does not justify buying capacity, changing a valuation or automating a control on its own. It does justify improving the evidence pack used for those decisions.

For a quarterly operating review, keep three separate ledgers:

• Capability: blinded, versioned task results on work resembling the organisation’s real repositories.
• Uplift: accepted output per developer-hour, including review, incidents and downstream rework.
• Economics: paid usage, realised price, gross margin, retention and the capital committed to deliver it.

Reconcile the ledgers, but do not substitute one for another. A task score is not recognised revenue. Revenue is not autonomous execution. Self-reported speed is not defect-adjusted value. If management uses a scenario date, attach the pace, ceiling, retraining and policy assumptions that produced it.

This also creates a better trigger system. A material divergence between the ledgers deserves investigation; ordinary monthly noise does not. Decisions should be bounded by the organisation’s own evidence and reversibility, not by confidence in a single external forecast.

Limits and what to watch next

The update is transparent enough to be challenged, but it remains a forecast by a small group with short timelines. Its estimate that reality is progressing at roughly 70% to 90% of the AI 2027 scenario pace is an author judgement. Other forecasters can reasonably choose different unknowns, bottlenecks and ceilings.

The next useful evidence will not be another point estimate. Watch for:

• a preregistered developer study with representative tasks and post-completion quality checks;
• disclosed revenue definitions that separate annualised run-rate, recognised revenue and inference pass-through;
• forecast revisions after a slower capability or revenue interval;
• evidence on whether autonomous coding performance transfers beyond software benchmarks;
• retraining-cycle measurements that test the assumed improvement loop; and
• sensitivity tables showing which one or two assumptions dominate the output date.

The forecast’s value today is not that it settles when autonomous coding arrives. It is that it makes a technical forecast answer to worker outcomes and commercial evidence. Used carefully, that triangulation can improve planning. Used as three votes for the same conclusion, it can manufacture confidence from correlated signals.