13.8 What the first week should not do
The false starts are as regular as the successes.
Starting from a tool. The most common first week begins with seats — a purchase, a rollout, a training session on the chat window — and no process. It feels productive, and the feeling is the problem. METR’s 2025 trial is the cleanest evidence that people are poor judges of their own gains: the developers in it believed they were faster and were slower. The alternative is the try-out in Chapter 11 — one real workflow, read-only access, a week, and an artifact a specialist can review — and it is the reason the week above ends with a handoff instead of a satisfaction survey.
Running where production is reachable. Replit’s July 2025 incident, examined in Chapter 14, is the case to remember when somebody proposes skipping the test environment because the task is small: Jason Lemkin reported that his application’s development, preview, and production shared one database, and eleven capital-letter instructions not to change anything did not hold.28 Dana’s drafts folder and Lena’s documentation branch are the same control at the scale of a first week. If the place the system writes is also the place customers read from, the week is not small enough to finish.
Connecting the first system to everything you can reach. The instinct is generous — give it the whole mailbox, the whole drive, every repository, so it has context — and the Invariant Labs demonstration against GitHub’s MCP server in May 2025 is what the instinct produces: private data in reach, an issue anyone could write, and a pull request to write the results into, with the user clicking Always Allow.29 The week above scopes the credential to one mailbox or two repositories, and Anthropic’s reported observation that users approved 93 percent of Claude Code permission prompts is why Day 4 asks for the boundary in a permission rather than in a prompt you will confirm forty times before lunch.30
Pricing the demo. A first week may cost a few dollars, and the temptation is to multiply by fifty-two and call it a budget. Cursor’s June 2025 repricing, examined in Chapter 15, is what happens when the unit of account is the wrong shape: a request that once meant one question came to mean a long-horizon task consuming ten times its neighbor’s tokens, and the surprise bills were the variance in customers’ own workloads becoming visible.31 Dana’s three hundred messages make the bill easy to inspect. The same design on every mailbox in the company, including retries and runs that fail to stop, needs a different budget. The per-key cap in Section 13.3 makes that limit hold.
None of these is an argument against beginning. Each is an argument for beginning with the eight things in Section 13.3 in place, and for reading Chapters 14 and 15 before the second week rather than after the first incident.
Two questions remain after Lena and Dana’s first week. Who can write content their systems will read? And what will these designs cost across every mailbox and repository, including a run that does not stop? Their records make those questions answerable; they do not settle them. But the first week has produced something concrete: a real workflow inside limits you set, another person who can explain what it did, and your name on the arrangement.