The first Claude session feels like a shortcut: paste an error, receive an explanation, copy a fix. The second session reveals the real question: what should the assistant be allowed to do, and what evidence should the beginner demand before trusting the result?
Using Claude for coding is not one activity. It can mean asking for a concept explanation, reviewing a diff, generating a focused function, or allowing a coding agent to inspect files and run commands. Those modes have different benefits and different costs of supervision. A productive beginner learns the boundary before handing over more responsibility.
Station one: learn the concept before touching the repository
Our project is a small Python command-line tool that reads a JSON file and prints a report. The first failure is a `KeyError` when a record lacks the optional `department` field. At the learning station, Claude receives only a small example and a clear request:
I am learning Python dictionaries.
Explain why this expression can raise KeyError:
record["department"]
Compare it with record.get("department") using a tiny example.
Do not rewrite my project.The goal is a mental model: square brackets require the key to exist, while `get` can return a default. Claude can explain the difference, but the learner should still run a tiny example and predict the output before viewing it.
| Learning request | Good output contract | Verification |
|---|---|---|
| Explain a traceback. | Identify the exception, failing expression, and one smaller example. | Run the example and explain the observed value. |
| Teach a language feature. | Definition, contrast, and one exercise. | Solve the exercise without copying. |
| Compare two approaches. | Trade-offs under stated requirements. | Choose one and state why. |
| Suggest a fix. | Smallest change plus possible edge case. | Write a test for the edge case. |
This station is low risk because Claude does not need access to the project. You control the context and can ask questions without authorizing file changes or shell commands.
Station two: review a change you already wrote
Next, the learner writes a function that produces the report. Instead of asking Claude to rewrite it, paste the function and the requirement:
Review this function against the requirement “missing department should appear as Unknown.” Identify one behavior that fails, explain how to reproduce it, and suggest a test. Do not provide a rewritten function yet.
The answer becomes useful only when it points to a behavior that can be reproduced. If Claude says the code “may have a bug,” ask for a concrete input. If the input confirms the issue, change the code yourself and run the test. This keeps authorship and understanding aligned.
def department_label(record):
return record.get("department", "Unknown")
assert department_label({"name": "Mina"}) == "Unknown"
assert department_label({"department": "Design"}) == "Design"Claude can suggest another edge case, such as an explicit `None` value or an empty string. The learner decides whether that input belongs to the project’s requirements. A generated test is not automatically a correct requirement.
GitHub’s responsible-use material makes the broader point that AI features have purposes, capabilities, and limitations in its official guidance. The same discipline applies here: ask what the assistant knows, what it inferred, and which parts require independent checking.
Station three: delegate a bounded task
At the third station, Claude may inspect a repository and perform a narrow task: “Add tests for `department_label` without changing production code.” The task has a boundary, a success condition, and an easy review surface.
| Delegated task | Safe boundary | Review before accepting |
|---|---|---|
| Add unit tests for an existing function. | Tests directory only; no production edits. | Inputs, expected values, and test independence. |
| Explain a failing command. | Read-only files and command output. | Whether the explanation matches the actual trace. |
| Refactor repeated formatting. | One module and required tests. | Diff, behavior, and readability. |
| Update dependencies. | Named package and lockfile policy. | Release notes, compatibility, and security review. |
Do not begin by saying, “Improve my entire project.” That request hides scope, definition of done, and permission boundaries. A coding agent can make many locally plausible changes while moving farther from the requirement.
Claude Code’s official permission documentation describes a tiered system in which actions can be allowed, asked about, or denied, and explains that file edits and shell commands can require approval in its permissions guide. Permissions are not a substitute for review. They are a control that limits what can happen before you inspect the result.
The same bug across the three stations
Use the `KeyError` as a test of the modes:
- Learn: ask why dictionary indexing raises the exception and write a miniature example.
- Review: paste your own function and ask for a failing input plus a test, without requesting a rewrite.
- Delegate: allow an agent to add the tests in a sandbox, then inspect the diff and run the suite.
The technology may feel more impressive at station three, but the learning risk is higher. The agent has access to more context and can act more quickly. If the task is vague, that speed amplifies the wrong interpretation.
Context is a budget, not a garbage drawer
Claude cannot infer every project convention from a short command. Context should include the relevant file, the requirement, the command to run, the constraints, and the definition of done. It should not include secrets, unrelated files, or a giant directory dump that makes the important evidence hard to find.
Goal: add coverage for department_label.
Files: tests/test_report.py and src/report.py.
Constraints: do not change src/report.py.
Command: pytest tests/test_report.py -q.
Done when: missing and present department cases pass.Before sharing a repository with any assistant, inspect what is in the context: environment files, access tokens, private customer data, generated build output, and unrelated source. A small task with clean context is easier to review than a large task with invisible assumptions.
Permission is a product decision
There is a meaningful difference between asking Claude to explain a local error and letting it execute a command that can alter files. The command itself may be familiar, but its working directory, arguments, environment variables, and side effects matter.
| Action | Suggested beginner posture | Why |
|---|---|---|
| Read a named file. | Allow when the file contains no secrets. | Creates context without changing state. |
| Run a read-only test. | Allow after checking the command and directory. | Produces useful evidence. |
| Edit one test file. | Ask for approval and inspect the diff. | Changes project state but remains bounded. |
| Install a package. | Pause and review package, version, and lockfile effect. | Changes dependencies and trust boundary. |
| Delete or deploy. | Require explicit human approval. | Side effects may be difficult to reverse. |
Our article on AI agents explains why tool loops need observations and stopping conditions. Our guide to AI coding assistant practices develops the review habit across tools.
When Claude’s answer sounds better than it is
Language models are good at producing explanations that are coherent, specific, and wrong. A proposed fix can use a real Python method but misunderstand the project’s data contract. A refactor can pass a narrow test and break a caller that the prompt omitted.
Use a three-part check:
- Requirement: restate what the program must do.
- Evidence: run a focused test or reproduce the original behavior.
- Diff: inspect exactly what changed and why.
If the answer cannot survive those checks, it is not ready to merge. The right response is not embarrassment; it is a smaller task and a clearer observation.
A five-minute verification protocol
# 1. Inspect the current state
git diff --check
# 2. Run the focused test
pytest tests/test_report.py -q
# 3. Inspect changed files
git diff -- src tests
# 4. Run the broader suite when the focused test passes
pytest -qThe commands depend on the project, but the sequence is portable: check formatting, run the smallest relevant test, inspect the diff, then broaden the test scope. Do not let an assistant’s confident summary replace the terminal’s output.
Questions beginners ask about Claude for coding
Should I paste my whole project into Claude?
No. Share the smallest relevant context that allows the task to be understood, and remove secrets and unrelated private data. More context is not automatically better context.
Is Claude Code safer than copying code from chat?
It can provide clearer permission and tool controls, but access to files and commands increases the need for review. A controlled agent can still make an incorrect change.
When should I ask Claude for a full implementation?
When you understand the requirement, can review the resulting diff, and have tests or checks that can expose a wrong interpretation. For learning, start with a smaller function or hint.
What should I do when Claude repeats the same failed fix?
Stop the loop, record the exact output, reduce the task, and ask for a new hypothesis. Repeating a prompt without changing the evidence rarely creates progress.
Move stations only when the evidence is ready
Using Claude well is a progression of responsibility. Learn a concept without repository access. Review a change you wrote. Delegate a small, reversible task with explicit constraints. Only then consider broader agentic work.
The assistant becomes more useful as your verification becomes more precise. The beginner skill is not making Claude act autonomously; it is knowing what to ask, what to allow, and what to prove before the code becomes someone else’s problem.
Practice the verification loop on a real error →
Protect the boundary between help and exposure
A coding session can contain more than source code. It may include API keys in environment files, customer identifiers in fixtures, internal URLs, or comments that reveal private architecture. Before giving an assistant repository context, search for secrets, replace sensitive values with placeholders, and check which files are actually needed. If the task is about a pure function, a sanitized excerpt is usually better than an entire checkout.
After a delegated task finishes, treat the result like any other contribution: inspect the diff, run the focused test, check the dependency changes, and write a commit message that explains the behavior. Claude can accelerate the cycle, but Git remains the record of what changed and why. Our article on version control shows how a bounded assistant task can remain reversible and reviewable.
Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.