Think in systems, not scripts

Non-programmers usually stall here — at the jump from "I ran this once" to "this runs on its own." The fix is to stop thinking about scripts and start thinking about systems. Every automation has the same four parts: input nodes (where data enters), conveyor belts (how it moves), transformers (what changes it), and output destinations (where it ends up).

If you've played Factorio or Satisfactory, you already know the model. A fetcher pulls posts off a social platform → a transcription stage runs Whisper → a content analysis stage labels them → the labeled output lands in a dashboard. When you describe a workflow to Claude this way, it gets the architecture right the first time instead of building one long script that breaks halfway through.

Describe the workflow, let the LLM build it

Instead of asking your CLI tool to help with one document, you describe an entire workflow — a sequence of steps from input to output — and it builds the script that automates it.

"Fetch this URL, strip out the ads, summarize it in three bullets, save it as a markdown file with today's date in the filename." That's a workflow description. Your CLI tool turns it into a reusable script. You review it, test it on a few real examples, and refine it until the output is what you want.

Plan before you build

Before asking your CLI tool to build anything, ask it to plan first. See the approach before any file is written or any command is run.

# Claude Code: enter plan mode
/plan

# Gemini CLI: be explicit
"Before doing anything, plan this out step by step
and wait for my approval before taking any action."

A misunderstood requirement caught at the planning stage costs you 30 seconds. The same misunderstanding caught after a failed 50-document batch run costs you time and money.

Pipeline stages

The right way to build a pipeline: separate stages, each with a clear input and output. Fetch. Clean. Analyze. Format. When something breaks, you know which stage failed — and you can fix one without touching the others.

Two schedulers: local and cloud

Claude Code has two ways to run a job on a schedule, and they solve different problems.

• > In-session cron.create — schedules a job from inside an active Claude Code session. Runs on your local machine, uses your local tools (Whisper, FFmpeg, YTDLP), and stops when your computer sleeps. Good for anything that needs GPU or long-running local work.
• > Cloud remote triggers — run in Anthropic's cloud on a fixed schedule. They don't need your computer to be on, but they can't touch your local files or tools. Good for detection ("did anything new show up?"), notifications, and anything that fits in pure API calls.
• > Hybrid — the pattern the video uses. A cloud trigger detects new videos every few hours and writes a tiny queue file. When your local machine wakes up, an in-session cron drains the queue and runs transcription on the GPU. You get the always-on detection of the cloud plus the local tools of your workstation.

GitHub Actions and GitHub Pages for the output layer

Once your pipeline produces something worth publishing — a dashboard, a CSV, an interactive page — you need an output destination that's always online. GitHub Pages is free, versioned, and every update is a commit you can audit later.

GitHub Actions is the trigger that fires when new output arrives. The pattern is simple: your local pipeline writes output into a repo, a commit pushes it to GitHub, a workflow in .github/workflows/ rebuilds the site, and GitHub Pages serves the new version. The Module 2 Mamdani dashboard updates this way every time new videos are processed — no server, no deploy script, no hosting bill.

Watch out for self-triggering loops

The Module 3 video debugs a real bug you will hit at some point: a GitHub Actions workflow that opens a PR, which triggers the same workflow, which opens another PR. These loops are easy to create and embarrassingly expensive to leave running. The defense is branch protection rules and a condition at the top of the workflow that filters out self-authored pushes. When the Copilot PR reviewer flags branching or trigger logic, read it carefully — these are exactly the bugs it catches best.

Test small before running large

Real API calls cost money. Before you process 500 documents through a paid API, test on 5. Better yet, validate your inputs with a free local model before sending anything to a paid service. Use cheap tools to catch problems before running expensive operations.

The debugging loop

When something breaks, paste the exact error message into your CLI session and ask what it means. Don't paraphrase. Your tool already knows the code it built for you, so it can read the error in context and usually identify the problem immediately. This is one of the most useful things about working with a CLI LLM: your debugging collaborator is already there, already has context, and can read error messages directly.

API key security

When your CLI tool builds scripts that call external APIs, those scripts often need API keys. Never put keys directly in your source code. Use environment variables instead:

# Bad: key hardcoded in a script (anyone who sees the file has your key)
API_KEY="sk-abc123..."

# Good: key stored in an environment variable
export API_KEY="sk-abc123..."   # set once in your terminal
echo "$API_KEY"                  # scripts read it from the environment

If you ask your CLI tool to build a script that uses an API, tell it to read keys from environment variables. And never commit a file containing a real key to git.

Rate limits and checkpointing

APIs have rate limits for a reason. Building pauses into your scripts (sleep 2 between API calls) keeps your API access alive. For long batch jobs, build in checkpointing — a log of which files have been processed — so the job can restart from where it left off instead of starting over.

Wrangling Messy Documents with Coding Agents

Nick Hagar

The clearest practitioner illustration of stage the pipeline, one job per stage. Hagar built a single skill with three modes — Transcription, Structuring, and Automated OCR — then tested it on three published investigations including a Pulitzer-winning NYT lobbying series and a Marshall Project / NYT Pulitzer finalist on New York prison discipline records. Crosses from Claude Code to Gemini 3 and back when one model's vision isn't good enough. His final line is the editorial argument this course keeps returning to: coding agents are versatile tools for handling labor-intensive tasks under the supervision of an expert human.

Augmented beat reporting: where LLMs excel and where reporters still win

Nick Hagar

A working beat-monitoring pipeline built for about $0.15 a day. The models hit an F1 of 0.94 at extracting relevant use cases from articles but only 31% exact alignment with human newsworthiness judgment. A one-week pilot still surfaced three high-value leads the reporter hadn't found elsewhere. The lesson maps directly onto this module: LLMs are good first-pass filters, but the decision about what's worth pursuing stays with the journalist.

Code proven to work

Simon Willison

Willison's argument that publishing pipeline outputs without personally verifying them shifts the verification burden onto the reader. The principle maps straight onto automated newsroom pipelines: you are responsible for checking that what your script produced is correct, not just that it ran without errors. Read this before you schedule anything on a recurring trigger.