AI Econometrics: Using AI for Code, Not for Identification

The term is still settling. “AI econometrics,” “AI for econometrics,” and “LLM econometrics” all name roughly the same thing, and which one wins is not decided. We use “AI econometrics” here for the workflow itself, and treat the other two as labels for the same practice. The practice matters more than the label, so it is worth defining the practice precisely before the label fixes a looser meaning in place.

The definition we work from:

AI econometrics is the use of an AI assistant as an instrument inside econometric work. The assistant drafts code, reimplements an estimator from its description, and runs specifications on command. We make the judgments that decide whether an estimate means anything: setting the estimand, arguing the identification, and verifying that the code computes what the design claims. The assistant lowers the cost of a first draft. It does not change what makes a result credible.

That block is the whole claim. Everything below is what it rules out, what it looks like when applied, and how the labor divides.

What AI econometrics is not

Two readings of the term need to be set aside before the definition can do any work.

It is not the model doing the econometrics. The assistant produces code; whether that code matches the estimator we meant to use is a separate question the assistant cannot answer about itself. A clean run shows that the code executed, not that the implementation is correct. The judgment about correctness stays with the analyst.

It is not automated causal inference. Identification is an argument about the world: which units are valid controls, what assumption lets a comparison stand in for the missing counterfactual, when that assumption fails. That argument is made by the economist from knowledge of the setting. No assistant supplies it, and a coefficient returned without it is a number, not a causal effect.

These two exclusions are the same point from two directions. The mechanical labor can be delegated. The claim that an estimate is identified and correctly computed cannot.

What it looks like in practice: two worked instances

The definition is easier to hold against concrete work than in the abstract. Two pieces on this site provide article-reported illustrations. Their exact outputs are not publicly reproduced.

Article-reported worked examples, not independently reproduced

Instance	What the assistant produced	The number	The judgment the economist made
Reimplementing a rolling DiD estimator	Article describes runnable Python from the method’s description; source is not public	Article-reported: 2.06 under demeaning vs 1.13 under detrending, against a planted true effect of 1.0	Choosing the transformation that fits the identifying assumption is the economist's judgment
Verifying assistant-written estimator code	Article describes a reimplementation that ran without an error or warning; source and run record are not public here	Article-reported: 0.18 returned where the planted truth was 1.0 and the comparison estimate was 1.13	Reading source against the specification is the verification step illustrated

The first is an article-reported reimplementation of a rolling difference-in-differences estimator in Python.¹ Its source article reports 2.06 under demeaning and 1.13 under unit-specific detrending against a planted effect of 1.0. No public simulation package currently reproduces that contrast. As an illustration, the spread directs attention to an identification question the economist must answer: whether treated and control units were on parallel paths.

The second is an article-reported verification case involving assistant-written estimator code.² The source article reports 0.18 from an input-ordering-error version, a planted effect of 1.0, and 1.13 as the comparison estimate. It also reports that a correct implementation lands near 0.18 on roughly 3% of draws. Those outputs are not publicly reproduced here. The methodological lesson is that a successful execution and a single planted-truth result do not replace reading the source against the specification.

Together, the examples illustrate the proposed division of labor. Their exact values should be treated as article-reported teaching cases until the underlying code, inputs, seeds, and outputs are released.

The division of labor

State the split plainly, because it is the operational content of the definition.

The assistant drafts code from a specification, reimplements an estimator from its description, and runs specifications across the variations we ask for. These are mechanical: search, translation, first-pass implementation, repeated execution. Delegating them is the source of whatever time the workflow saves.

We do three things the assistant cannot. Before any code runs, we fix the estimand: which quantity to estimate, and how to aggregate it. We argue the identification from the setting: the assumption that lets the comparison recover a causal effect. And we verify that the code computes that estimand under that identification, running a planted-truth simulation and reading the source line by line.

The cost structure is what makes this a stable division rather than a temporary one. An assistant lowers the cost of producing a plausible first draft. It does not lower the cost of verification, and by making omissions easier to miss, it raises it. The work therefore shifts toward the part the economist keeps. A faster draft is worth little if the verification it now requires is skipped, because the unchecked code carries the same appearance of precision with less assurance behind it.

Where it goes

The practice is young enough that its hard questions are still open, and naming them honestly is more useful than predicting how they resolve.

How much of verification can itself be delegated without circularity. An assistant can draft a simulation harness, but if the same kind of process that wrote the estimator also writes its test, both can miss the same untested case, letting the same class of error pass twice. Where the independent check has to come from outside the assistant, and where it can be assisted, is unsettled.

What a usable specification looks like for an estimator. A loose instruction leaves the low-visibility choices, weighting, comparison set, transformation window, indexing, to a default the analyst never chose. A precise spec is necessary and still insufficient: in one case we named cohort-size weighting in the spec and the implementation dropped it anyway. The form a spec should take so that verification can check it against the code is an open methodological question, not a solved one.

When a reimplementation is worth its verification cost at all. Rebuilding an estimator outside its maintained package adds the full verification burden, justified only when the workflow needs the open language, a reproducible pipeline, or a specification no package supplies. The assistant moves that calculation in one direction, cheaper drafts, and leaves the verification side where it was.

The label will settle on its own. The division of labor under it is the part worth getting right: the assistant drafts the code and runs the specifications, and the economist keeps the estimand, the identification, and the check that the implementation matches the design we claim to be using.

Notes

1. Cholette, V. (2026, June 13). Rolling difference-in-differences with few units: An article-reported simulation. Too Early To Say. https://tooearlytosay.com/research/methodology/lwdid-rolling-difference-in-differences/ That article reports the 2.06 versus 1.13 contrast; its simulation package is not public.
2. Cholette, V. (2026, June 15). How do we know an AI's estimator does what we meant? Too Early To Say. https://tooearlytosay.com/research/methodology/validate-ai-econometric-code/ That article reports 1.13 and 0.18; the exact outputs are not reproduced on this page.