Your first lap: turn an orders CSV into a daily report
A data pipeline is a repeatable set of steps that reads data, checks it, transforms it, and writes a useful result. For this first run, take an orders CSV and produce daily sales totals. Keep the original file untouched and write the report to a separate output folder.
Claude Code becomes your programming partner inside the project. You describe the goal, ask it to inspect relevant files, and review its proposed edits. It can help write code and run checks when permitted, but you remain responsible for deciding what the pipeline should do.
Prepare a small Python project and a safe connection
Create a project folder with a Python virtual environment. Start with Python's built-in csv, datetime, decimal, and unittest modules; this exercise does not need a large data framework. Add folders named data, output, and tests, plus a pipeline.py file.
If you need model access, SwiftRelay works with Claude Code and offers pay-as-you-go, per-token billing. Its Claude Code API host is https://api.fastapirelay.com; use the bare host, not a host ending in /v1. Follow its Claude Code setup instructions for authentication and model selection. Claude Sonnet 5.5 is one option for this workflow.
Sign up for SwiftRelay if you want to try this setup with the small gift credit available to new accounts. Keep your API key outside source files and out of version control. Use made-up customer data for the exercise, and avoid sharing production records or credentials in prompts.
Give Claude Code a pipeline contract before requesting code
A contract is simply an agreement about inputs, outputs, and errors. Write it down before asking for implementation. Otherwise, the assistant must guess details that can change your totals.
Try this prompt: “Help me build a Python pipeline for an orders CSV with order_id, order_date, and amount columns. Dates must use YYYY-MM-DD. Amounts must be nonnegative decimal values with at most two decimal places. Produce daily_totals.csv with date and total_amount columns, sorted by date. Reject invalid rows with a clear message. Propose a plan before editing files.”
Then settle the remaining rules together:
- Require all three input columns and reject missing headers.
- Treat repeated order_id values as errors rather than silently counting them twice.
- Stop on invalid input and leave any existing report unchanged.
- For a header-only input, produce a report containing only its header.
Build one readable pipeline stage at a time
Ask Claude Code to separate reading, validation, aggregation, and writing into small functions. This makes the program easier to explain and test. Request plain names such as read_orders and calculate_daily_totals instead of clever abstractions.
Use Decimal for amounts rather than binary floating-point arithmetic. Ask the assistant to explain that choice in everyday language: money should follow explicit decimal rules, not accumulate small representation surprises.
Before accepting an edit, read the diff, which shows exactly what changed. Ask, “Explain this function with one sample row,” whenever a step feels unclear. Review requested terminal commands before approving them, especially commands that install packages, delete files, or access the network.
Check the totals with examples you can verify yourself
Create a tiny fixture with two orders worth 12.50 and 7.25 on the same day, plus one order worth 3.00 on another day. The expected daily totals are 19.75 and 3.00. Calculate those yourself before running the program.
Next prompt: “Write unittest tests for the agreed rules. Include duplicate IDs, impossible dates, negative amounts, missing headers, and empty input. Verify that invalid input does not overwrite an existing output file. Run the tests and show any failures.”
Inspect the assertions, not just the test result. Passing tests only demonstrate the behavior they actually check.
Finish the lap with a repeatable local run
Ask Claude Code to document the exact command for your implemented command-line interface, its input path, and its output path. Run it against the tiny fixture, open the resulting CSV, and compare it with your expected totals.
Before using larger files, confirm that errors identify the offending row and that output is published only after successful validation. Save the reviewed code and tests together. You now have a small, understandable pipeline—and a pairing routine built around clear rules, limited edits, and evidence you can inspect.