Economists are not being asked to become AI maximalists overnight. They are being asked to notice that the frontier moved. In the VoxDev webinar that accompanies this page, Aniket Panjwani makes a narrower and more practical claim: AI agents are already useful for economics research, the cheapest serious setup is now good enough to matter, and economists who wait too long to build workflows will learn slower in a weak job market.
That makes this less a generic "future of AI" article and more a memo from the talk itself. The webinar answers four questions in sequence: which tool to use, what first exercise to run, which beginner mistakes to avoid, and how to keep learning after the session. This written version follows that same sequence, keeps the strongest recommendations from the webinar, and includes the exact starter prompt from the slides.
Slides and Recording
If you want the full webinar first, watch the video at the top of this page. If you want the deck alongside the written notes, it is embedded below.
AI Agents for Economics Research Slides
Embedded PDF
1. Why Economists Should Care Right Now
The talk does not open with a tool demo. It opens with the feeling that the frontier has already moved.
Aniket starts with Dylan Patel's line that being in San Francisco feels like "Wuhan right before the pandemic" because "something is happening." He then translates that from software to economics by pointing to examples from Paul Novosad, Gauti Eggertsson, Chris Blattman, and even Terence Tao. The point is not that every economist should become a software engineer. The point is that the workflows around research, writing, project management, and even theory are already changing.
The practical argument is:
- agents are already good enough to create real productivity gains
- many economists still do not have a daily workflow with them
- the people who start earlier will compound faster
That is why the talk frames this as an employability issue as much as a tooling issue. If the cost of experimentation is collapsing, the people who can direct and verify these systems become more valuable.
2. Which Tool Should Economists Use?
The recommendation in the webinar is unusually direct: if you are starting today, especially on a tight budget, use Codex rather than Claude Code.
The reasons given in the talk are specific:
| Question | Webinar takeaway |
|----------|------------------|
| Which tools matter right now? | For practical purposes, just Codex and Claude Code |
| What should a beginner on a tight budget pick? | Codex |
| Why Codex? | Better model quality for most tasks, more usable throughput at the $20/month tier, and a better desktop interface for most users |
| What if your peers use Claude Code? | That is fine; the workflows transfer |
One useful nuance from the webinar is that this is not framed as permanent truth. The space changes quickly. Aniket has switched back and forth between Claude Code and Codex over time. But the talk's recommendation for this moment is still clear: if you are an economist starting from scratch and you need the best serious low-budget option, use Codex.
He also makes an important compatibility point: this is not a locked ecosystem decision. Skills transfer cleanly between the two tools, and CLAUDE.md maps closely to AGENTS.md, so you are not cutting yourself off from collaborators who prefer Claude Code.
3. The First Exercise To Run Today
The first practical exercise in the webinar is not "build an app" or "benchmark models." It is much simpler and more economist-specific: use an agent to clean up one of your old projects.
The setup is blunt, and part of why the talk lands: most economists have messy codebases, inconsistent folder structures, and too many files named things like final_v7_really_final.do. A coding agent is unusually good at reorganizing that kind of project, spotting which files are current, and rewriting a messy structure into something safer and more legible.
Prerequisites
Before running the exercise, the talk recommends:
- Install Codex or Claude Code.
- Install Git.
- Create a GitHub account.
- Install
gh, the GitHub CLI, and authenticate it. - If you use Stata, set up a Stata skill first. The linked tutorial is How to Create a Stata Skill.
The Starter Prompt
This is the exact exercise from the slide deck, lightly normalized for formatting:
I want your help cleaning up this project and setting up a git repo. First, copy it all over to a
backup directory.
Next, suggest an initial gitignore and create a first repo.
Then, push the initial repo to a private repo on GitHub.
Then, check out a new branch and suggest how to restructure the repo to have best practices
with data/code/docs/paper organization and lineage.
Then just do it on the new branch.
Finally, actually run any code you've modified/restructured to make sure it lines up with the
prior results.
The power of the prompt is not that it is fancy. It is that each line solves a real beginner problem:
- the backup directory makes the first experiment psychologically safe
- the
gitignoreforces the agent to separate source files from bulky data and generated outputs - the private GitHub repo gives you an off-machine backup and a real history
- the new branch makes the restructuring reversible
- rerunning the code forces the agent to check that the cleanup did not silently break the project
Tip: This is a much better first exercise than asking an agent to "do research for me." It gives you a bounded task with a concrete before-and-after result.
4. Beginner Mistake 1: Treat Git As Optional
The first beginner mistake in the webinar is not using Git.
The memorable line is: you do not need to know Git to use Git. You do, however, need the agent to have Git available if you want the full benefit of these tools.
In the talk, Git matters for three reasons:
- it lets you safely try changes and roll them back
- it gives the coding agent useful project memory through commit history
- it unlocks worktrees and parallel branches once you get more advanced
That "memory" point is especially important. Once your project has real history, the agent can inspect how files evolved and help reason about when a bug or weird output may have been introduced.
If Git still feels abstract, the best companion piece is Why Git Makes Claude Code 10x More Powerful.
5. Beginner Mistake 2: Underutilize Skills
The second beginner mistake is underusing skills.
The talk's definition is the right simple one: skills are reusable instructions that teach Codex or Claude Code how to do a task your way. They are saved playbooks. Instead of re-explaining the same workflow every time, you make the workflow reusable.
That matters because economists tend to have repeatable tasks:
- review a paper
- run a data-analysis workflow
- prepare a proposal
- summarize meetings
- work with Beamer or Stata in a project-specific way
The webinar walks through concrete economist-made examples:
- Pedro Sant'Anna's data-analysis skill
- Chris Blattman's proposal-write skill
The recommendation is not just to install other people's skills blindly. It is to treat them as patterns you can adapt. If you know your own workflow, you should expect to customize it.
If you want help creating your own, the webinar points to Anthropic's skill-creator skill. A good follow-on tutorial is The Only Claude Code Skill You Need.
6. Beginner Mistake 3: Do Everything In One Giant Thread
The third beginner mistake is not making plans first.
This is one of the most important workflow points in the webinar. A long agent thread tries to do planning, implementation, debugging, and revision in one place. That feels convenient at first, but it fills the context window with intermediate thoughts that are no longer relevant once the real build starts.
The better workflow from the talk is:
- Plan in one session.
- Write the plan to a file such as
plan.md. - Start a fresh session and execute only that plan.
That preserves the context window for execution rather than wasting it on stale back-and-forth from the planning stage.
Warning: When people say "Codex got dumber" or "Claude Code got dumber" in a long session, a lot of the time the real problem is context pollution, not model collapse.
7. How To Keep Learning After The Webinar
The webinar's advice here is blunt and probably correct: if you want to stay close to what is actually happening in agentic coding, get on X.
The reasoning is not ideological. It is practical. The developers pushing workflows forward are on X, and the economists who are early to agentic coding are mostly downstream of those developer conversations. LinkedIn has some useful discussion. But if you want the frontier, the talk argues that X is where you should spend attention.
The economist list in the slides includes names like:
- Alex Imas
- Chris Blattman
- David Yanagizawa-Drott
- Ethan Mollick
- Pedro H. C. Sant'Anna
- Scott Cunningham
- Antonio Mele
If you want a lower-noise path than living on social media all day, the talk also points people to the Economics of AI newsletter and the AI MBA economist cohort.
8. The Budget Question
One of the sharper claims in the webinar is that $20/month is enough to start but not enough to ignore.
You can do real work at that tier. In fact, the talk is specifically trying to help people start there. But the downside is not just that you will wait longer. It is that you will learn slower, hit limits sooner, and fall behind peers who are able to run more experiments and spend more time in the tools every week.
That is why the webinar treats a larger AI budget as a human-capital question, not just a software question. If you can rationally reallocate toward a $200/month setup, the argument is that you should think seriously about doing it.
9. The Job Market Frame
The talk ends with a labor-market argument rather than a tooling argument.
Using a slide on JOE postings, Aniket notes that 2025-26 postings were down 31% at the same point in the cycle and argues that economists should not assume the old demand structure will simply return. His claim is that the kinds of semi-technical white-collar work often done by economics undergrads are exactly the kinds of tasks AI is beginning to compress.
You do not have to buy the strongest version of that argument to take the practical lesson seriously. If research, analysis, and writing workflows are shifting, you want to be the person who can direct these systems responsibly rather than the person encountering them too late.
Two Useful Q&A Takeaways
The webinar Q&A added two useful practical points that are worth preserving here.
Sensitive or proprietary data
If you cannot expose raw data to an external model, the talk suggests a few ways to keep moving:
- ask the agent to write profiling or analysis scripts, then run them yourself and paste back only the safe results
- create mock or anonymized data with similar structure
- use local models or private enterprise instances where your institution can support them
The important point is that "I have sensitive data" is not the same as "I cannot use agents at all." It usually means you need a different architecture.
Coauthors who refuse to use Git
If your coauthors insist on Dropbox or Google Drive, the recommendation is not to give up on Git. It is to keep Git on your side anyway and tell the agent explicitly that some incoming file changes may come from collaborators outside the version-control workflow.
That lets the agent help you identify likely collaborator edits and clean up the Git history around them, instead of forcing you to manage the entire mess manually.
Closing Takeaways
If you want the shortest faithful summary of the webinar, it is this:
- Start now.
- If you are on a tight budget, start with Codex.
- Use the old-project cleanup exercise as your first real workflow.
- Do not treat Git, skills, or planning as optional.
- Think of better tooling not as luxury software, but as compounding human capital.
That is the real throughline of the talk. The goal is not to sound futuristic. The goal is to become useful with these systems before usefulness itself gets repriced.