A few days ago I wrote about analyzing a new budgeting API and doing the pre-work for a possible migration. That "possible" lasted exactly one afternoon. The build happened, the reviews happened, and then it went live — all in a single long working session, with a second session for decommissioning the old system afterward. This post is about the part everyone skips: the reviews in the middle.
Building it boring on purpose
The importer itself was built the way I now build anything that touches real data: strict test-driven development, standard library only, no framework, no cleverness. Small modules with one job each — a mail reader, a parser, an API client, a runner — and a CLI to poke at each layer independently. The rule that shaped everything: fail closed. An email that looks ambiguous is not a transaction; it stays unread and gets treated as an alert, not a guess. By the end the test suite was around fifty cases, most of them about the ugly edges: duplicate delivery, malformed amounts, a message that is a charge and a warning at the same time.
Writing it was the easy part. What made the session long was the review loop.
The review that always finds something
The setup: after I finished the implementation, a series of independent review passes ran against it — fresh agents, each with the full requirement list and instructions to review security, parser behavior, API semantics, and whether the docs matched reality. Not me grading my own homework. Four rounds of them.
Every round found something real. The first caught a parser that would have classified a generic security-warning email containing a dollar figure as a card charge — a fail-open bug in a system whose whole point was to fail closed. A later one caught documentation that confidently described a state the code no longer had. Another flagged that the runbook's pause-and-resume procedure could leave two automation jobs consuming the same unread mailbox if one command failed silently — fixed by chaining them so a half-applied transition is impossible.
What I've come to believe after these loops: the value of a reviewer is almost perfectly correlated with how independent it is of the thing being built. Every one of these agents had no stake in declaring the code ready, and each came back with a list. If your review process has never once made you change the code, the review is decorative.
The cutover, and the retirement
The test that finally mattered wasn't fifty unit tests — it was importing a handful of real charges from real alert emails into the live budget, then reading them back and confirming the source mailbox hit zero unread. That passed on the first production tick, and the new hourly job went live. The old system's automation got a proper send-off: final clean import, the old cron job removed and verified gone, everything pushed to the remote git host, and the old repository archived so nobody accidentally builds on the corpse. The rollback runbook survives in the new project's docs — deliberately. Decommissioning should be reversible for a while; permanent is a decision, not a default.
Watch Later, the stubborn playlist
Smaller win from the same stretch: the YouTube Watch Later dilemma. The official API flat-out refuses to read that playlist — there's a specific error code for it — but a local tool with signed-in browser cookies handles it fine, read-only. So the workflow became: pull the playlist locally, then fan the transcripts out to parallel subagents for summarization. Watching four agents chew through long transcripts simultaneously and hand back structured summaries is the closest thing I have to a staff meeting. Nobody interrupts anyone. It's lovely.
What the week taught
The migration itself was maybe a third of the effort. The rest was verification: finding reviewers who would actually push back, making failure modes explicit, rehearsing the cutover in a controlled test before pointing the cron at production, and then cleaning up after the old system like it might come back. Code gets written once; trust gets built in review rounds. Worth every one of the four.