Skip to content

Reproduce Your Results Table From a Fresh Clone

2026-09-29

A results table that only reproduces on your laptop depends on something you never wrote down: an exported variable, a dataset in your home directory, a package installed by hand six weeks ago. Anyone who tries to run your repo, including someone reviewing it as a work sample, hits that dependency before they see your result.

The check. Clone into a temporary directory and run the documented command with your environment stripped:

bash
git clone <repo-url> /tmp/repro-check && cd /tmp/repro-check
env -i HOME="$HOME" PATH="$PATH" make reproduce-table1
diff results/table1.csv <path-to-committed-table>

env -i starts the command with no exported variables except the two you pass back in. Expected result: the same table, or, for sampled runs, numbers inside the interval you reported. Anything else means the instructions are incomplete.

Whatever breaks is an undeclared dependency. Ask Claude Code to fix it in the repo rather than on your machine:

  • a lockfile (uv sync --locked) instead of a package installed by hand;
  • a setup target that downloads data to a documented path and checks its hash;
  • an early check that names a missing variable, such as an API key, instead of failing three steps later. The check reports that the variable is missing; it never prints a value.

One Claude Code detail from the settings documentation: an env block in .claude/settings.json is an ordinary settings key. It shapes Claude Code sessions. It does nothing for a collaborator who runs make in their own terminal, so the variables an experiment needs belong where the experiment reads them. Keep secrets out of both.

Run the check again after the fixes, from a new temporary directory. Two clean runs in a row is a reasonable bar before you call the table reproducible. The book's reproducibility notes show the same discipline applied to its own code.

Claude Code documentation.