The 403 recovery via user-agent modification is exactly the kind of thing that separates a demo from a real pipeline. Claude handling that without intervention is more interesting to me than the headline capability. The data sampling approach - scanning structure rather than processing every row - is the kind of optimization you normally have to tell it explicitly.
Turns out it often figures that out on its own once the file gets large enough. The Cowork versus local execution distinction matters more than most tutorials make clear. For anything that hits real network endpoints or needs actual filesystem access, local is still the only path. Cowork's sandbox cuts off too much.
Thanks for the interesting example, Paul. I followed along on my own computer and was able to use Claude Code in a VM (Ubuntu) to download the data and create the graph. First time user of Claude, so quite happy about that.
This is the one that made it click for me. The FRED dead end, the 403 error, the user-agent workaround — that sequence is exactly what real data work looks like, and seeing Claude navigate it without hand-holding is genuinely different from anything I've seen in a browser-based workflow.
The Kieran Healy tip is something I'm stealing immediately. Referencing a concrete visual style instead of specifying parameters one by one is such a cleaner way to work. That kind of shortcut only comes from someone who's actually put hours into this.
What you're describing here — from empty folder to reproducible figure in a single session — is the exact workflow gap we're trying to close with a course we're building called "Master Claude in the Real World." Most people using Claude are still copy-pasting between tabs. This series is proof of what's actually possible on the other side. We just launched on Kickstarter for anyone who wants a structured path to get here faster: https://shorturl.at/ZrG8p
The scraping post can't come soon enough. SEC EDGAR is going to be a good one.
Hey Paul, this is a great series, thank you so much for making it! I wonder if you can help me resolve a concern for IRB issues.
For context, I'm an experimental and development economist, usually using primary data. One of my coauthor's IRBs now says the following: "Do you plan to use Generative AI tools to analyse or otherwise interact with the information about or provided by participants? If yes, please reflect here on any ethical risks this may give rise to. Note that if you plan to use any personal data in a Generative AI tool and/or share the data with third parties via the tool or use it to train models this should be explained in the Participants Information Sheet and consent obtained, and you should also complete a Data Management Plan. Please refer to the School’s Guidance on the use of Generative AI for Research."
Obviously no one should put any datafile with identifying information (name, phone number, etc.) in a folder that AI could access. I'm wondering about working with deidentified data. My understanding from this video is that Claude Code might read enough of a deidentified dataset into its context window to understand the structure of the data, then it would write an analysis script in the cloud, then execute that script on your local machine. Do we know how much of the data it reads into its context in the cloud? I expect that IRBs will be lagging behind researchers in their understanding of how agentic AIs like Claude Code actually work, so researchers like me should get ready to explain it.
What do you think I could or should say to my coauthor's IRB? Thanks for any advice you're able to offer!
If you interact with a service like FRED or EDGAR a lot, MCPs can save you (and Claude) the trouble of figuring out 403 errors etc. You can even let Claude simply build whatever MCP server you need, especially if there's already an API (see e.g. https://github.com/floriancaro/fred-mcp-server using the FRED API)
The 403 recovery via user-agent modification is exactly the kind of thing that separates a demo from a real pipeline. Claude handling that without intervention is more interesting to me than the headline capability. The data sampling approach - scanning structure rather than processing every row - is the kind of optimization you normally have to tell it explicitly.
Turns out it often figures that out on its own once the file gets large enough. The Cowork versus local execution distinction matters more than most tutorials make clear. For anything that hits real network endpoints or needs actual filesystem access, local is still the only path. Cowork's sandbox cuts off too much.
Thanks for the interesting example, Paul. I followed along on my own computer and was able to use Claude Code in a VM (Ubuntu) to download the data and create the graph. First time user of Claude, so quite happy about that.
This is the one that made it click for me. The FRED dead end, the 403 error, the user-agent workaround — that sequence is exactly what real data work looks like, and seeing Claude navigate it without hand-holding is genuinely different from anything I've seen in a browser-based workflow.
The Kieran Healy tip is something I'm stealing immediately. Referencing a concrete visual style instead of specifying parameters one by one is such a cleaner way to work. That kind of shortcut only comes from someone who's actually put hours into this.
What you're describing here — from empty folder to reproducible figure in a single session — is the exact workflow gap we're trying to close with a course we're building called "Master Claude in the Real World." Most people using Claude are still copy-pasting between tabs. This series is proof of what's actually possible on the other side. We just launched on Kickstarter for anyone who wants a structured path to get here faster: https://shorturl.at/ZrG8p
The scraping post can't come soon enough. SEC EDGAR is going to be a good one.
Hey Paul, this is a great series, thank you so much for making it! I wonder if you can help me resolve a concern for IRB issues.
For context, I'm an experimental and development economist, usually using primary data. One of my coauthor's IRBs now says the following: "Do you plan to use Generative AI tools to analyse or otherwise interact with the information about or provided by participants? If yes, please reflect here on any ethical risks this may give rise to. Note that if you plan to use any personal data in a Generative AI tool and/or share the data with third parties via the tool or use it to train models this should be explained in the Participants Information Sheet and consent obtained, and you should also complete a Data Management Plan. Please refer to the School’s Guidance on the use of Generative AI for Research."
Obviously no one should put any datafile with identifying information (name, phone number, etc.) in a folder that AI could access. I'm wondering about working with deidentified data. My understanding from this video is that Claude Code might read enough of a deidentified dataset into its context window to understand the structure of the data, then it would write an analysis script in the cloud, then execute that script on your local machine. Do we know how much of the data it reads into its context in the cloud? I expect that IRBs will be lagging behind researchers in their understanding of how agentic AIs like Claude Code actually work, so researchers like me should get ready to explain it.
What do you think I could or should say to my coauthor's IRB? Thanks for any advice you're able to offer!
If you interact with a service like FRED or EDGAR a lot, MCPs can save you (and Claude) the trouble of figuring out 403 errors etc. You can even let Claude simply build whatever MCP server you need, especially if there's already an API (see e.g. https://github.com/floriancaro/fred-mcp-server using the FRED API)