One of the common themes to emerge from the Impact Ops Fellowship is the need to round up relevant news from the web and convert it into a monthly intelligence brief.
I thought this would be a great use case for Claude Code, and so I recorded myself building a working app from scratch in 90 minutes (the video is edited down to 30). From my experience, when it comes to developing your AI know-how, nothing beats watching over someone’s shoulder. So I’ve attempted to give you that experience here.
As a result, this is not a polished tutorial. There are wrong turns, unexpected blips, and a stretch where the agent spins out and I have to nudge it. That’s the point. If you’re new to Claude Code, I hope you come away with three things: more confidence that you can do this, a working mental model of how apps get built, and a few habits that make building with an agent go well.
The AI-generated notes below are meant to highlight key moments in the video for future reference.
How the ninety minutes break down
- About twenty minutes writing the brief. In a word processor, in plain English. I list the components, name what’s out of scope, and keep an Open Questions section for things I don’t know how to handle yet. Then I export to Markdown, drop it into Claude Code, and say “build this.”
- About an hour while the agent builds. It asks a few questions up front (I take its recommendations), writes a plan, runs subagents, codes, and debugs itself. My job is to grant permissions when asked, give it one nudge when it gets stuck, and briefly open a code editor to add an API key.
- Ten or fifteen minutes of testing. I run the pipeline for a single source first, check the console for errors, and screenshot a formatting bug straight into the chat. Then I package everything else I want into one V2 request: four features at once.
The basics, if app development is new to you
The video narrates the fundamentals as they come up. The short version:
- An app is a folder. A piece of software is files nested in folders on someone’s computer. You build and run it locally first; deploying just means putting those folders somewhere public — GitHub stores the code, a host like Vercel serves it.
- Local and production are two instances. Locally you have your own server, database, and settings; production has its own. Local testing is fast — you refresh the page — which is why developers work there, even though it means managing two copies of everything.
- Version control is a must-have. Git is the tool on your computer that records every change; GitHub is where the project lives online. You don’t need to master either on day one, but you do need to have them.
- Environment variables hold your secrets. API keys grant access to your accounts and your money, so they never go in chat and never go in GitHub — the tools increasingly refuse to let you. They live in a local configuration file, which is why you still need a code editor once in a while.
- Debugging starts with looking. When something silently fails, check the browser console for errors and tell the agent what you see — even “no errors in console” is useful information.
- Agentic apps need observability. When the interface is chat, you need a place to see what the agent actually did: the runs, the tools it called, what each one cost. That’s where debugging happens. This app’s agent runs totaled 64 cents.
Habits worth internalizing
- Write the spec before you open the tool. Breaking a project into small components is the most transferable skill here. Include what you’re not building — and when you don’t know how something should work, say so in an Open Questions section instead of guessing.
- Name the tools you know; accept recommendations when you don’t. I specified the Resend API and the Vercel AI SDK because I happened to know them. Everywhere else I took Claude’s picks. It recommends the tools it’s best at, so going with its grain tends to work.
- Let it cook. Give the agent a large task and step away. It’s like baking: you don’t keep opening the oven door to check for doneness. In my experience, the more you trust these systems with long, complex work, the better the results.
- But keep your discernment. When it churned too long on a CSS problem, I told it plainly: “it seems like you’re spinning out.” Models are like gears — I started in overdrive (Fable) and downshifted to Opus when the work no longer needed it.
- Watch the context window. As it fills, the agent gets slower and more forgetful, and it isn’t always good at diagnosing that itself. Keep an eye on the percentage.
- Turn on notifications. You don’t want to stare at an agent for an hour. Do other work and let it interrupt you when it needs a permission.
- Batch your fixes. Collect what you find in testing and hand it over as one request, not a drip of one-offs.
On confidence
Notice how much I don’t know in this video. I don’t use the Claude Code app interface often. I couldn’t tell you what “ESM seed retest” means. At one point I forget to save a file and the agent catches it. None of that stops the work, because the tool meets you where your mental model is: I say “prepare the newsletter for August and September,” it translates that into its pipelines and configuration, and the app gets better at speaking my language with every request. Your journey will have wrong turns too. Build anyway!
All resources →