Day One With Claude Code in an Inherited Repo: Pick the First Safe Task Without Breaking Things

On my third day at a new job, someone handed me a payments codebase with maybe 150 files. There was almost no documentation. Every person I asked said some version of “it works, so I’d rather not touch it.” So I did the lazy thing and told Claude Code: “Get familiar with this repo and fix anything that looks off.”

Ten minutes later, Claude came back sounding very pleased with itself: “I cleaned up 20 files.” I opened the diff and went pale. It had reformatted a migration SQL file, reordered .env.example, and helpfully “optimized” the payment retry delay by cutting it in half. The code still ran. But if that had shipped to production, the phones would have been ringing off the hook with double-charge complaints.

The problem wasn’t that Claude was dumb. The scope I handed it on day one was just way too wide. To hand someone else’s giant codebase to an AI safely, you don’t need to go hunting for a smarter model first. You spend 30 minutes deciding four things: the read order, the places it must not touch, the first tiny job, and how you’ll confirm it’s done. Get those down and almost all of the day-one accidents disappear. Today I’ll lay out exactly what goes into those 30 minutes, in a form you can copy and paste.

Key takeaways

• “Look at everything and fix it” is the most dangerous thing you can say on day one, because you start running with the scope still fuzzy.
• What you build in the first 30 minutes isn’t a design document. It’s a one-page note for picking the first task safely.
• The note has just four lines: read order, no-touch zones, the first tiny job, and the proof command that tells you it’s done.
• Limit the first job to somewhere “easy to undo” — copy text, a button label, a confusing test name. Those are perfect.
• Hand the AI the “read it and draft it” part. The production DB, billing, deletions, and publish buttons stay with a human.

Why the very first instruction trips you up

Claude Code is fast. And precisely because it’s fast, a broad opening prompt means it will pour full effort into diffs that nobody asked for.

A human new hire asks, “Am I allowed to touch this?” An AI doesn’t ask. Out of helpfulness, it widens the scope on its own. Say “clean this up” and it will genuinely clean up every corner. The migration reformatting and the billing-retry “optimization” were both done in good faith.

So your job on day one is not to read all the code, and not to write an impressive improvement plan. It’s to draw boundaries. How far can it act on its own, and where does it have to stop and ask? Draw that line up front and your requests to Claude shift from “think freely” to “stay inside this box and leave evidence.” Drawing the line takes 30 minutes. You do not need to understand all the code.

The one-page day-one note you build in 30 minutes

Paper or a text file, either works. Fill in just these four items. The order matters too.

1. Decide a narrow read order. Not every file at once — just README and package.json to start. That tells you the language, how to start it, and what tools it uses. Then two or three of the main screens or routes. That’s enough.
2. Write down the no-touch zones. Billing, login/auth, environment variables, database migrations. Say explicitly: “you may read these, but do not rewrite them.” If you don’t write it, Claude treats them as normal edit targets.
3. Pick one small first job. Limit it to somewhere easy to undo: the closing line of an article, a button label, a confusing test name. Something you can revert instantly if it goes wrong.
4. Decide how you’ll confirm it’s done. Does the build pass? Is the diff within the expected range? Is the screen still intact? You judge by the result of a command, not by vibes.

Fill in those four and most of the day-one anxiety evaporates. Because now you know not “what Claude might pull,” but “how far I handed Claude.”

What to delegate to the AI, and what a human decides

Put the line into words once and you stop second-guessing every time. Here’s the split I use.

Task	Delegate to Claude	Human decides
Read the code and summarize the structure	Yes, have it draft	You confirm the final understanding yourself
Suggest the no-touch zones	Yes, have it list candidates	Billing and auth are always confirmed by a human
Fix copy and labels	Yes, fine to delegate	Look at the diff and approve
Writes to the production DB	No	A human runs it by hand
Deletions, publishing, billing	No	A human presses the button

The point is to put every dangerous operation on the “ask a human” side from the start. You only promote an operation to “automatic” after you’ve confirmed it’s safe — never the other way around. Granting wide access up front and tightening it after an accident has the order backwards.

If you want this thinking explained more gently, read the Claude Code getting started guide and the Claude Code first 30 minutes checklist alongside this — together they make day one click into place.

Copy-paste request templates

The trick is to not let it edit anything right away. The first ask is “just read it and put it in a table.”

This is my first time touching this repo. Do not edit anything yet.
Read in the following order and return the results as a table.

1. Read README and package.json; list the language, the start command, and the main dependencies
2. List the risky areas (billing, auth, environment variables, DB migrations) with their file paths
3. Propose 3 candidates for an easy-to-undo "first small job," each with a reason
4. For each candidate, write the command that confirms completion (build, diff check, etc.)

To repeat: do not edit a single character at this stage.

Once the table comes back, check with your own eyes that no “no-touch zone” is missing. If one is, add it — and only then do you finally request a single task.

Of the earlier candidates, proceed with only XX (fixing the closing line of the article).
Do not touch billing, auth, environment variables, or migrations at all.
After editing, run `npm run build` and show me the diff with `git diff --stat`.
If something breaks, explain the cause and the fix in one line, then stop.

If you write the no-touch zones into CLAUDE.md from the start, you can skip pasting this warning every time. How to write it is covered in CLAUDE.md best practices.

A tiny piece of code to let a machine run the check

Relying on your memory for “make sure it’s prepared before handing it over” means you’ll skip it on a busy day, guaranteed. So let a machine decide whether the one-page note has the bare minimum. The following code runs as-is on Node.js.

// Machine-check whether the day-one one-page note is "ready to hand to Claude"
const repoMap = {
  goal: "Pick one easy-to-undo first task",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "Fix the closing line of the article (do not touch payment code)",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("read order too narrow / not set");
  if (map.protectedAreas.length === 0) reasons.push("no-touch zones are empty");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("no build-check command");
  }
  if (!map.firstTask) reasons.push("first task not chosen");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "OK to hand over" : "Not yet: " + result.reasons.join(", "));

Run it and you get this.

node check-repo-map.mjs
# => OK to hand over

Try setting protectedAreas to an empty array and you’ll get “Not yet: no-touch zones are empty.” It’s just this much, but it stops the single most common accident — “running fully automated while having forgotten to write the no-touch zones” — before you ever hand it over. Paste this note straight into CLAUDE.md or an issue, and tomorrow’s you and your teammates can reuse the same judgment.

Three places it actually paid off

1. Blog operations: protecting the links on articles that earn When I only want to fix the call-to-action at the end of a popular post, asking Claude to “improve the copy” tends to make it touch the product link URL too. So I close the box: “You may fix the copy, but do not change the link URL by even one character. After the change, show me the build and the diff.” That way I polish the writing without breaking the link that drives revenue.

2. SaaS: keeping it away from billing When the explanatory text on a settings screen is confusing, the only thing to improve is the displayed text. The billing and plan-change logic stays off-limits. Put billing/ in the note’s no-touch zones and you stop Claude from helpfully reaching into the retry logic.

3. Internal tools: fixing only the output column names Someone asked for help because the column names in a CSV export were confusing. What gets fixed is just the column-name strings; the aggregation logic is a separate matter. Ask for “only the displayed column-name strings; do not touch the formulas; show me the output on sample data,” and confirmation is over in a second.

What all three share isn’t a lack of ability in Claude — it’s the single fact that thin boundaries cause accidents. The clearer you write the boundary, the more safely and quickly the AI moves.

Common pitfalls and how to fix them

Pitfall 1: Reading every file from the start. You burn time and tokens on low-importance formatting, and the change that actually matters ends up thin. The fix: narrow the read target to README and package.json plus two or three main routes. Widen your whole-repo understanding only after you’ve finished one task.

Pitfall 2: Not writing the no-touch zones. Claude treats billing, auth, and deploy config as normal edit targets. The fix: write a protection list with file paths and keep it resident in CLAUDE.md. Spoken warnings get forgotten; written ones stick around.

Pitfall 3: Trusting “done!” without deciding a proof command. You end up guessing every time whether the completion report is true. The fix: build “run the build and show me the diff” into the request from the start. An HTTP 200 or a plausible-sounding reply is not proof of success. Trust only the result of an actual run.

FAQ

Q. Isn’t it safer to understand the whole existing codebase before delegating? Ideally, yes — but you won’t finish understanding the whole thing on day one. Wait for that and nothing moves, so close the no-touch zones first and start from one easy-to-undo task. Understanding actually grows faster while you work.

Q. How small should the first task be? A grain size that finishes in one file, one piece of copy, one command is the rule of thumb. Ask for something big and Claude will helpfully widen the scope. Confirm the build and a screenshot before moving on, and you cut revert time without slowing down.

Q. Where’s the best place to write the no-touch zones? CLAUDE.md is the one that sticks. Pasting them into the prompt every time means you forget to paste on a busy day. Put them in one place as a project rule and they apply automatically even to new work.

Q. I said “don’t touch it” and Claude touched it anyway. Usually your protection target stopped at a filename and didn’t specify the whole directory. Write the range, like billing/, not just billing.js. If it still crosses the line, add one step at the top of the request — “declare the target files before editing, then proceed” — and it’s easier to stop.

Q. Do I have to rebuild this note every time? Build it once per repo and you reuse it after that. Paste it into CLAUDE.md and an issue, and tomorrow’s you and your teammates inherit the same judgment. When you find a new protection target, just append it.

What I confirmed when I actually tried it

After the payment-code incident at the top, I tried the same procedure on a different existing repo. I let it edit nothing first and had it produce only the table with the request above — and it correctly listed billing/ and migrations/ as protection candidates. It did miss the environment-variable file, though, so I added .env myself. It reinforced how important it is to run this with a human in the loop.

I narrowed the first task to a single fix of an article’s closing line, confirmed it all the way through npm run build and git diff --stat, and was done. The diff was just seven lines, and it hadn’t touched the payment code by a single character. I also ran the check code for real and confirmed that emptying protectedAreas makes it stop with “Not yet.” Rather than hunting for a smarter AI, decide a small range you can revert from instantly even if you fall over. On day one of inheriting someone else’s code, that helped more than anything.

If you’re at the stage of wanting your team to decide a shared pattern for how to bring Claude Code into your company’s existing code, training and consultation lets us look at your actual repo and sort out where to draw the boundaries together. It’s also worth confirming the official prerequisites at Anthropic Claude Code getting started.