Coding agents can now write much of the code behind an empirical project. It’s tempting to “vibe code”, but I firmly believe human judgement will remain instrumental to framing research questions, choosing appropriate methods, and interpreting the results. Here, you’ll find practical tips for working with coding agents, useful datasets, and people worth following to learn more about using these tools in economics research.

A curated collection of data sources for empirical research in economics and finance.

Monetary Policy

Asset Pricing

Macroeconomic & Market Data

  • India

    Database on Indian Economy

    Access RBI statistics for research on Indian monetary conditions, banking and the wider economy.

  • Economic history

    Macrohistory Database

    Study long-run relationships between credit, financial crises and macroeconomic outcomes.

  • India · High-frequency data

    Indian Stock Market Data

    An unofficial Python client for retrieving NSE market data; useful for exploratory downloads that require validation.

  • International

    BIS Data Portal

    Compare credit, banking, exchange rates and property prices across economies.

  • India · Daily market data

    NSE Historical Reports and Bhavcopies

    Use official daily market reports and bhavcopies to examine Indian trading activity and check downloaded observations.

A few habits that you should follow when using coding agents for empirical research.

  1. Take time over the plan

    Have the agent propose a plan before it writes any code, then question it the way a referee would. Which data will we use? What assumptions are we making? What are the constraints? Make sure these choices to be clear enough to question before they become part of the code.

  2. Write down what you intend to test

    Write down the main specification and robustness checks before looking at the results. There’s still room to explore, but keep track of what changed and why. When writing up, distinguish the analysis you planned from ideas that emerged along the way.

  3. Make the agent prove its work

    Before an agent refactors anything, have it write tests that pin down known results, such as a replicated table or a key coefficient, and read every diff yourself. The agent writes the code; you own the results.

  4. Get a separate review

    Ask a fresh session to review the code, providing the research question and relevant assumptions. Have it look for mistakes and explain its concerns. Then work through those concerns yourself; the reviewer can get things wrong too.

  5. Replicate in a second language

    For results that matter, have the agent rebuild the analysis in a second language, such as Stata alongside R, and match the estimates to six decimal places. If the answers differ, investigate. Matching answers are reassuring, though two implementations can still share the same mistaken assumption.

  6. Maintain high reproducibility standards

    Generate tables and figures from the analysis and keep track of where the reported numbers come from. Document the data, software, and steps needed to rerun the project. The AEA Data Editor’s reproducibility guidance is a useful reference when preparing the work for someone else to reproduce.