12. AI-Assisted Research

Data Science for Economists

Julian Hinz

2026-03-01

Learning Objectives

Use LLMs effectively in research workflows
Give AI project context via CLAUDE.md / AGENTS.md
Set up skills and slash commands for recurring tasks
Understand autonomous code review
Practical research life hacks

Session Roadmap

The AI-Assisted Coding Landscape
Project Context Files
Skills & Slash Commands
Autonomous Code Review
Research Life Hacks

The AI-Assisted Coding Landscape

The toolkit has evolved

LLMs are code editors, pair programmers, and research assistants

Conversational

Claude (Opus 4.6 / Sonnet 4.6), GPT-5.2, Gemini 3.5
Chat interfaces for exploration, brainstorming, debugging

IDE-integrated

Cursor, GitHub Copilot
Inline completions, multi-file edits, context-aware suggestions

CLI agents

Claude Code, Codex
Agentic coding: read files, run commands, edit code, iterate

GitHub Copilot in your IDE

Ghost text completions as you type
Write a comment → Copilot generates the code
Particularly effective for:
- ggplot2 from natural language descriptions
- data.table syntax (:=, .SD, by)
- Regex patterns
- Boilerplate (file I/O, API calls, package loading)

# Create a scatter plot of GDP per capita vs life expectancy
# with log scale on x-axis, colored by continent
ggplot(gapminder, aes(x = gdpPercap, y = lifeExp, color = continent)) +
  geom_point(alpha = 0.6) +
  scale_x_log10() +
  theme_minimal()

Claude Code (CLI Agent)

Agentic coding from the terminal — reads, writes, and runs code
Understands your project via CLAUDE.md context files
Powerful for: scaffolding, debugging, refactoring, code review

# Ask Claude Code to fix an error
claude "Fix the merge error in 03-analysis.R — the county
       identifier has missing values causing observation drops"

# Scaffold a new analysis
claude "Create a gravity model estimation script following
       our project conventions in CLAUDE.md"

# Review code
claude "Review the diff on this branch for econometric issues"

When AI helps vs when it misleads

Excels at

Boilerplate and scaffolding
Syntax translation between languages
Regex and string manipulation
ggplot2 from descriptions
Interpreting error messages
Documentation and comments

Struggles with

Econometric assumptions
Identification strategy design
Data quality judgments
Causal reasoning
Domain-specific conventions
Hallucinated packages/functions

Best practices for AI-assisted coding

AI output = first draft, never final output
Always review generated code for correctness
Pin package versions — don’t trust AI’s version assumptions
Write unit tests to catch errors early — especially for AI-generated code
Use AI to accelerate, not to replace understanding

AI adoption: three barriers (Cunningham 2026)

1. AI is an experience good

You can’t imagine what you haven’t seen
No demo, brochure, or testimonial closes the gap
Only direct experience does
Faculty map AI onto familiar categories (“another software”, “better Google”) and miss the revolution

2. AI triggers repugnance

AI “talks to you” — feels personal in a way Excel never did
Taps into genuine ethical concerns mixed with unfamiliarity
Creates enough friction that many faculty avoid AI entirely

3. Frontier models cost money

$200/month for transformative tools (Claude Max)
Free tiers hamstring researchers to the point of uselessness
Cost falls entirely on individual faculty

Overcoming the barriers

Two levers: experience and subsidy

Faculty need to experience AI on a task they already do: lecture slides, research directories
Institutions should provide frontier model licenses — not Copilot, not the free tier

The adoption recipe (Cunningham 2026):

Identify 1–2 tasks all faculty do that are high-value and time-intensive
Give them clear, specific instructions to type in — not vague advice like “try AI”
These tasks should produce a visible change — they see the difference

Once they adopt for one task, everything else follows.

Unit tests: why they matter

AI-generated code can look correct but contain subtle bugs
Unit tests are automated checks that verify your code does what you expect
Write them once, run them every time you change something
Especially valuable for data transformations, merges, and cleaning steps

In R, the standard framework is testthat:

# tests/test-gravity.R
library(testthat)

test_that("merge preserves all observations", {
  dt_left  <- data.table(iso3 = c("DEU", "FRA", "USA"), gdp = c(3.8, 2.7, 21.4))
  dt_right <- data.table(iso3 = c("DEU", "FRA"),        pop = c(83, 67))
  dt_merged <- merge(dt_left, dt_right, by = "iso3", all.x = TRUE)
  expect_equal(nrow(dt_merged), nrow(dt_left))
})

Unit tests: running them

# Run all tests in the tests/ directory
Rscript -e 'testthat::test_dir("tests")'

✔ | F W  S  OK | Context
✔ |          2 | test-gravity
✔ |          3 | test-cleaning

══ Results ═══════════════════════════
[ PASS: 5 | FAIL: 0 | WARN: 0 | SKIP: 0 ]

Put tests in CLAUDE.md build commands so AI agents run them too
Tests document expected behavior — useful for collaborators and your future self
A failing test after an AI edit tells you exactly what broke

Project Context Files

The problem

LLMs start every conversation with zero project context
They don’t know your:
- File structure and naming conventions
- Preferred packages and coding style
- Data sources and variable definitions
- Build system and workflow
- Research question and identification strategy

Result: generic suggestions that don’t match your project

The solution: context files

Place structured text files in your project root
LLM tools read them automatically at the start of each session
Your conventions are applied from the first interaction

This idea is documented and championed by Chris Blattman (UChicago):

claudeblattman.com — AI workflows for researchers and managers
Open-source templates and skills for academic research

Five files, five purposes

File	Audience	Purpose
`README.md`	Humans	Project overview, reproduction instructions
`CLAUDE.md`	LLM assistants	Project-specific context for code generation
`AGENTS.md`	LLM assistants	Specialized agent roles with different rules
`STYLEGUIDE.md`	Both	Generic coding conventions (write once, reuse)
`skills/`	LLM assistants	Reusable slash commands for recurring tasks

CLAUDE.md deep dive

What goes in it:

Project description: one-paragraph summary of the research
Repo structure: key directories and what lives where
Build commands: how to render, run tests, compile
Data sources: where data comes from, what format, what keys
Gotchas: things that break, known issues, edge cases

Start small — 10–20 lines of project description. Add detail as you discover what the LLM gets wrong.

CLAUDE.md: Example

# Project: Gravity Model of Trade

Bilateral trade flows estimated with PPML. Data from CEPII (BACI).

## Structure
- `code/`: R scripts numbered 01-05
- `input/`: raw BACI data (do NOT modify)
- `output/figures/`: all plots saved here
- `temp/`: intermediate files, gitignored

## Build
- Run all: `Rscript code/00-master.R`
- Render paper: `quarto render paper/paper.qmd`

## Conventions
- data.table for all data manipulation
- Native pipe |> (not %>%)
- Figures: ggplot2 + theme_minimal() + ggsave()

## Data notes
- BACI uses HS6 product codes, reporter/partner ISO3
- Distance and contiguity from CEPII GeoDist
- Zeros matter: use PPML, not OLS on log trade

AGENTS.md

Define specialized roles with different rules and context:

## Data Engineer
- Works only in `code/01-*.R` to `code/03-*.R`
- Focus: data cleaning, merges, consistency checks
- Never modifies `input/` files

## Analyst
- Works in `code/04-*.R` and `code/05-*.R`
- Focus: estimation, robustness, visualization
- Must document every regression specification

## Reviewer
- Read-only access to all files
- Checks: code/slide consistency, missing topics
- Flags reproducibility issues

STYLEGUIDE.md

Write once, copy to every project:

## R Style Guide

### Packages
- Use pacman: `p_load(data.table, ggplot2, fixest)`
- Pin versions in renv.lock for reproducibility

### Data
- data.table for all manipulation
- Native pipe |> throughout
- Never use attach() or <<-

### Output
- Figures: 1600x900 PNG, theme_minimal()
- Tables: modelsummary or kableExtra
- File names: YYMMDD_description.ext

Portable across projects
LLM + human readable
Enforces consistency without effort

Practical payoff

Without context files:

LLM suggests tidyverse when you use data.table
Wrong directory structure, wrong file naming
Generic boilerplate that needs heavy editing
Each session starts from scratch

With context files:

Code matches your style from the first interaction
Faster onboarding for new collaborators (human or AI)
Consistency across sessions and tools
Fewer corrections, more productivity

Skills & Slash Commands

What are skills?

Markdown files that add slash commands to Claude Code
Live in .claude/skills/ in your project
Triggered with /skill-name in a Claude Code session

Examples:

/done — wrap up a task, summarize changes, update docs
/review-plan — stress-test a plan with a fresh agent
/commit — stage, write message, commit following conventions

The Prompt → Plan → Review → Revise loop

Blattman’s foundational workflow for AI-assisted research:

Prompt — brain-dump your ideas, goals, constraints
Plan — structure them into a concrete implementation plan
Review — stress-test with a fresh agent (catches blind spots)
Revise — incorporate feedback, capture lessons learned

Each step can be a skill — reusable, consistent, auditable

Building your own skills

A skill is just a markdown file:

---
description: Wrap up the current task
---

# Done

1. Summarize all changes made in this session
2. List any files created or modified
3. Note any open questions or follow-up tasks
4. Update the project TODO if one exists

Save as .claude/skills/done.md → use with /done

Skill library

Chris Blattman’s open-source collection:

github.com/chrisblattman/claudeblattman
skills/ directory with research-oriented commands

Selected skills:

/review-plan — adversarial review of implementation plans
/done — session wrap-up with change summary
/lessons — extract and record lessons learned
/deep-research — structured literature/data investigation

Autonomous Code Review

GitHub Copilot Code Review

Assign Copilot as a PR reviewer — just like any human teammate
Leaves inline comments with suggested fixes
Reads source files, explores directory structure for context
Integrates CodeQL + ESLint for security scanning

Key detail: Copilot always leaves “Comment” reviews, never “Approve”

Does not block merging
Review typically completes in under 30 seconds

Copilot Coding Agent

Works in the background on GitHub — no active session needed
Handles: bug fixes, feature implementation, test coverage, docs
Self-reviews its own changes before opening a PR
Runs security scanning on generated code

Workflow:

Assign an issue to Copilot
Copilot creates a branch, implements changes
Opens a PR with description and test results
You review and merge (or request changes)

Code review: summary

Tool	What it does	When to use
Copilot Review	Inline PR comments	Every PR — fast, free feedback
Copilot Agent	Background implementation	Issues with clear specs
Claude Code	Interactive review	Complex refactoring, research code

Research Life Hacks

Claude Code + Codex for daily research

Use CLI agents as your day-to-day research coding companion:

Paste error messages → get targeted fixes with project context
Scaffold project structures from CLAUDE.md templates
Review scripts before committing

# Debug a specific error
claude "I get 'object dt_merged not found' in code/03-analysis.R
       line 47. The merge on line 32 seems to silently drop rows."

# Scaffold a new project
claude "Create a new gravity model project with our standard
       directory structure and CLAUDE.md template"

Markdown notes in Obsidian

All notes in plain markdown — no proprietary format
Searchable, linkable, version-controllable
Works offline, syncs via Git or cloud storage
No vendor lock-in — your notes are just .md files

Why this matters for research:

Link literature notes to project notes to code
Search across all projects instantly
Version-control your research log

Git for everything remotely like research

Not just code — version control everything:

Papers and manuscripts (.tex, .qmd)
Grant proposals
Teaching materials and slides
Presentation drafts
Data documentation

Version control = safety net + collaboration tool

Never lose work
See exactly what changed and when
Collaborate without emailing files back and forth

Overleaf projects as Git submodules

Overleaf exposes a Git remote for every project:

# Add your Overleaf paper as a submodule
git submodule add https://git.overleaf.com/abc123 paper/

# Pull latest changes from Overleaf
cd paper/ && git pull origin master

# Push local edits to Overleaf
git push origin master

Keep analysis code and paper in sync in one repo
Coauthors who prefer Dropbox? Overleaf ↔︎ Dropbox integration works alongside Git

Wrap Up

Summary

AI-assisted coding is here — conversational, IDE-integrated, and CLI agents
Context files (CLAUDE.md, AGENTS.md, STYLEGUIDE.md) make LLMs project-aware
Skills turn recurring workflows into reusable slash commands
Autonomous code review catches issues before they reach main
Research life hacks: Obsidian for notes, Git for everything, Overleaf as submodule

Start today: create a CLAUDE.md for your current project. 10 lines is enough.

Resources

claudeblattman.com: claudeblattman.com — AI workflows for researchers
Blattman’s skills: github.com/chrisblattman/claudeblattman
Claude Code: docs.anthropic.com/en/docs/claude-code
GitHub Copilot: github.com/features/copilot
Obsidian: obsidian.md
Overleaf Git: overleaf.com/learn/how-to/Git_integration
Cunningham (2026): “How to Encourage Adoption of AI Among Faculty” — experience goods, cost barriers, two use cases (Baylor AI Task Force slides)
Using CLAUDE.md Files: claude.ai/blog/using-claude-md-files

Questions?