From my talk at NABE TEC EU 2026. Benjamin Tanz summarized one part as:
[…] speaking about the engineering aspects of using AI agents in Econ teams, and in particular which tasks to delegate vs. not to delegate to agents. And yes, identification is with the scientist.
This resonates a lot with the idea of solving the right problem and how your subject matter expertise guides what you delegate and what you don’t.
Some context on my economics team
I lead engineering in a cross-functional team called Economic Decision Science at Amazon, the central economics team in Europe. It’s mostly PhD economists, with a small embedded engineering function. The engineering vision predates AI agents entirely: economists should be able to deliver without engineering bottlenecks. We defined the things economists should be able to do (we called them capabilities) and built reusable building blocks 1 with good UX that they can mix and match to tackle ambiguous problems fast. We called the framework “Factory of Economics” where work goes straight to production, without the sometimes common practice of “producing scrappy code and handing over to devs to scale”.
When we started adopting coding agents in 2025, the fit was immediate. The ways of working we already had (capabilities, building blocks, fast iteration) mapped directly onto how agent skills work. Late 2025, models got noticeably better2. It became easier to advocate internally because the broader community was visibly succeeding with these tools, and our own economists were seeing more success in more tasks, which increased trust and ambition in what to delegate.
Everyone uses them, not just for code
Today, the entire cross-functional team uses coding agents. They help across roughly everything: analysis and research design, data pipelines, operations, writing and communication, troubleshooting. The “coding” in “coding agents” undersells it; a lot of the value is in reasoning through problems conversationally, without directly manipulating the implementation yourself. The agent is effective because it works where the economist works: it has access to their tools, data, and machine.
The talk showed three illustrative patterns:
“Explain this model to me.” You have SQL or a model you wrote months ago. You ask the agent to explain it. It doesn’t matter how long it is. During the explanation you use your judgment and spot something wrong, like “counting the wrong window.” You know what correct looks like and conversationally get it fixed. In fifteen minutes it can be in production.
“Help me analyze this policy.” You start from a policy question with no design yet. You’re basically rubber ducking3 with the agent, externalizing your own thoughts: what methodology? what assumptions? what could go wrong? (e.g. Power analysis, clustering, spillovers). The nice thing is that as you go along, you’re actually proving and validating things. You might try twenty variations in an afternoon and land on a research design you trust.
“Help me respond to this challenge.” Your methodology gets challenged in a meeting. It’s very cheap for stakeholders to challenge and it used to be very hard to produce the right data, come back and respond effectively. Now you can open the agent, pull the data, produce the chart, draft an appropriate response immediately after the meeting, knowing it’s backed by real numbers.
What economists never delegate
With all that delegation, here’s what stays with the economist:
- Methodology selection: “which estimator, which design”
- Causal identification: “how to isolate the effect”
- Economic interpretation: “whether results make sense”
- Stakeholder judgment: “tone, framing, politics”
- Research taste: “what questions matter”
The economists may discuss these things with the agent, but delegation means handing over the decision, and that stays with the economist.
I’ve seen on occasion well-meaning software engineers build tools that pick methodologies for economists: “define your problem and the AI will choose the right approach.” Economists reject these immediately. If you don’t know why you framed the problem a certain way, you can’t validate whether the output is taking you where you need to go, which takes us back to the issue of solving the right problem.
In a follow-up post I’ll cover Part 2: the pain points of working with AI agents, and how to keep control while being bolder on delegation.
Footnotes
Recently Mitchell Hashimoto published The Building Block Economy which fits very well with our mental models.↩︎
Better tool calling, longer autonomous runs, less babysitting, more reliable first-attempt behavior. See METR Task Horizons.↩︎
Rubber duck debugging is the practice of explaining a problem out loud (originally to a rubber duck) to clarify your own thinking before asking for help. Popularised by Hunt and Thomas in The Pragmatic Programmer.↩︎