Practice — Claude Code Fundamentals (12 questions)

A developer runs Claude Code in a Node.js project and types:

"The /api/orders endpoint returns a 500 error when a user has no shipping address on file. Fix it."

They are in Manual permission mode.

1. Describe, phase by phase (gather context → take action → verify results), a plausible sequence of tool calls Claude Code would make to handle this request. Name at least one specific built-in tool per phase and what it would be used for.
2. At which points in your trace would Claude Code stop and prompt the developer for approval, and why exactly those points and not others?
3. Suppose the first fix Claude applies still fails the verification step (the test still fails, or a new error appears). Explain, in terms of the loop, why this doesn't mean Claude Code is "broken" — what should happen next mechanically?

Your team is onboarding a new engineer to Claude Code. They will spend their first week doing two kinds of work: (a) exploring an unfamiliar, business-critical billing service they've never touched, and (b) writing unit tests for a small, well-understood internal CLI tool they already know well.

1. Which permission mode would you recommend for task (a), and which for task (b)? Justify each choice in terms of what the mode does and doesn't auto-approve.
2. A teammate suggests just starting everyone in Bypass Permissions mode "to save time during onboarding." Explain concretely what could go wrong with this suggestion, using the reversibility concept.
3. The new engineer notices Claude Code keeps prompting them to approve npm run test every single time while they work on the CLI tool (task b). What's the appropriate fix, and where would they make it?

A developer asks Claude Code to change a configuration default in config.py. Claude attempts an Edit call, and it fails with an error to the effect of "the string to replace appears 3 times in this file and no replace_all was set; please provide more context or set replace_all."

1. Explain, in terms of how the Edit tool actually works, exactly why this error occurred and why Claude Code doesn't just guess which of the three occurrences was meant.
2. Contrast this with what would happen if the developer had instead asked Claude to use sed via the Bash tool to make the same change. What safety property does Edit have that a raw sed command run through Bash does not?
3. A colleague argues: "This is a UX flaw — the tool should just use AI judgment to figure out which occurrence I meant." Do you agree or disagree, and why, connecting your answer to how Claude Code treats reversibility and predictability elsewhere in its design?

A team's repository has the following requirements:

• Every contributor should be able to run the project's linter and test suite without being prompted, since these are safe, frequently run commands.
• Nobody's Claude Code session — regardless of mode — should ever be able to read or edit the secrets/ directory, which holds locally-decrypted credentials for local development.
• One senior engineer personally wants Claude Code to also auto-approve a private local script she uses for smoke-testing deploys, but this shouldn't be forced on the rest of the team.

1. For each of the three requirements, specify which settings file (and roughly what rule) should hold it, and explain why that scope is the correct one.
2. Suppose the senior engineer accidentally puts her personal smoke-test rule in the project-level settings file and commits it. What concretely goes wrong, and for whom?
3. Explain why the secrets/ rule needs to be a deny rule rather than simply "don't add an allow rule for it and trust the default behavior."

Two developers separately ask Claude Code to help with the same underlying problem: a slow API endpoint.

• Developer A types: "Make the API faster."
• Developer B types: "The GET /api/reports endpoint takes over 8 seconds for accounts with more than 10,000 records. I suspect it's the report-aggregation query in src/reports/service.ts — it looks like it's N+1 querying per record. Investigate and fix if that's the cause; if not, profile and find the actual bottleneck."

1. Both prompts are grammatically valid English. Explain, in terms of the agentic loop's "gather context" phase specifically, why Developer B's prompt is likely to produce a faster and more accurate fix.
2. Does Developer A's vague prompt make Claude Code unable to help, or does it just change how the loop proceeds? Explain the difference.
3. Developer A's request still eventually converges on a reasonable fix after several extra loop iterations. Where, mechanically, did those extra iterations go, compared to Developer B's request?

A developer runs Claude Code in Accept Edits mode for an afternoon, asking it to make a series of small refactors across a codebase: renaming a widely-used utility function, updating its call sites, and adjusting a few related type definitions. They don't look at any diffs during the session — they just keep issuing new requests and trust that "the tests passed, so it must be fine."

1. Explain specifically what the agentic loop's "verify results" phase does and does not guarantee about a change, using this scenario.
2. Give a concrete example of a plausible mistake that could survive an entire session like this — passing tests, no prompts triggered — and only surface later. Explain why the loop wouldn't have caught it.
3. What's the minimal habit change that would have caught this kind of issue, and why does it not require abandoning Accept Edits mode?

A developer, working in Accept Edits mode, asks Claude Code to "clean up the src/utils/ folder — remove dead code and anything that's no longer imported anywhere." Claude investigates, then:

1. Uses Edit to remove a handful of unused functions from three files.
2. Runs Bash: rm -rf src/utils/legacy to delete an entire subdirectory it determined was unreferenced.
3. Reports the cleanup is done.

The developer later realizes src/utils/legacy actually contained a script a teammate relies on for a quarterly data export, and it was only "unreferenced" because nothing in the main codebase imports it — it's invoked manually. The directory had never been committed to git (it was added recently and is still untracked).

1. Can the developer use /rewind → "Restore code" to bring back src/utils/legacy? Explain why or why not, tracing your answer to the specific mechanic of how checkpointing tracks changes.
2. Given that the directory was never committed, what are the developer's actual recovery options at this point, and how good are they realistically?
3. What habit, if adopted before this session, would have prevented this from being a real loss — and why does it not require avoiding Accept Edits mode or distrusting Claude Code's cleanup ability?

An engineering lead has two requests for Claude Code this week:

• Request A: Every Friday, they want Claude Code to produce a short, non-technical "what shipped this week" summary for stakeholders who don't read code — friendlier tone, no jargon, no diffs — without changing how Claude actually approaches writing or reviewing code the rest of the week.
• Request B: A teammate is traveling with only a phone this week and wants to kick off a small, low-risk documentation fix, expecting to pick the session back up on their laptop once they're back.

1. Which mechanism addresses Request A, and why is editing CLAUDE.md the wrong tool for this job even though CLAUDE.md also "changes Claude's behavior"?
2. Which mechanism addresses Request B, and what does the teammate give up by using it instead of working locally on their laptop?
3. Would adopting either of these change the underlying gather → act → verify loop described earlier in this subject? Justify your answer.

A developer asks Claude Code to change a single default value in config.py. Claude calls the Edit tool, and it comes back with an error instead of applying the change.

Which of the following is the actual reason Claude Code's Edit tool fails and reports an error, rather than applying some version of the requested change?

While working in Accept Edits mode, Claude Code runs rm old-script.sh through the Bash tool to remove a file it determined was unused. The file was never committed to git — it was new and still untracked.

The developer wants that file back. Which of the following correctly describes their actual recovery options?

A developer on a Claude Code Pro plan opens a brand-new terminal session in a project they've never used Claude Code in before, and hasn't changed any settings.

Which permission mode does that session start in by default, and how does it handle risky actions?

A developer wants Claude Code to sound more casual and narrate more of its reasoning during today's session, without changing anything about what Claude knows about the project's conventions or architecture, and without affecting sessions after this one.

Which mechanism should they use?