Lesson 15: Checkpoint — Core Workflows Review

Day 15 of 50 · ~10 min reflection · Phase 2: Core Workflows

How This Works

This checkpoint tests your understanding of Lessons 1–14 — everything from Phase 1 (foundational concepts) and Phase 2 (core workflows).

You'll see 12 questions. Some test Phase 1 concepts; others test Phase 2. For each question, try to answer from memory first. Then expand the answer to check yourself.

Scoring:

10–12 correct: You've got it. Move forward.
8–9 correct: Solid understanding. Skim the weak areas and continue.
6–7 correct: Review the relevant lessons before moving on.
Below 6: Revisit Lessons 9–13 carefully. This foundation matters.

This is not a test to fail. It's a check for your own understanding. Answer honestly.

Recall Questions

Phase 1 (Lessons 1–8)

Question 1: What's the core difference between a chatbot and an agent?

A chatbot responds to individual requests. An agent is agentic — it understands a task, breaks it down, executes steps, checks results, and adjusts if something goes wrong. Agents can read files, run code, iterate autonomously. Chatbots wait for the next message.

Did you mention: The agentic loop (read → reason → act → check)?

Question 2: Name the four main tools Claude Code uses, and what each one does.

Not a complete list, but the main ones:

Read: Open and view file contents
Write: Create new files or overwrite existing files
Edit: Make precise replacements using old_string/new_string
Bash: Execute shell commands to run tests, compile code, check git status

Others include Glob (find files), Grep (search file contents), and NotebookEdit (edit Jupyter notebooks).

Did you mention: That Edit is precise (with old_string/new_string) while Write is blunt (entire file replacement)?

Question 3: What does it mean to "read code"? What's Claude looking for when it opens a file?

Reading code means Claude opens a file and looks for:

Function definitions and signatures
How functions call each other
Data structures and object shapes
Error handling patterns
Where variables are assigned and used

The goal is to understand intent — not just syntax, but what the code is trying to do and how it fits into the bigger picture.

Did you mention: That reading code is different from just parsing it — Claude has to understand context and dependencies?

Question 4: Describe the agentic loop in your own words.

Read: Claude opens files, understands the current state
Reason: Claude thinks about the problem, makes a plan
Act: Claude makes an edit, runs a command, creates a file
Check: Claude verifies the result (tests pass? error message? did it work?)
Loop: If the check reveals a problem, Claude reads the error, reasons about what went wrong, and acts again

Did you mention: That you stay in the loop by providing feedback when something goes wrong?

Phase 2 (Lessons 9–13)

Question 5: What's the difference between the Edit tool and the Write tool? When would you use each?

Edit tool: Precise replacements using old_string/new_string. Use for: modifying existing code in specific places without changing the whole file. Safe because if the old_string doesn't match, the edit fails.
Write tool: Replace entire file contents, or create new files. Use for: creating new files from scratch, or when you want to rewrite a file completely.

For existing code, Edit is safer because you're being surgical. For new files or complete rewrites, Write is appropriate.

Did you mention: That Edit protects against accidentally editing the wrong code?

Question 6: What's a context window, and why does it matter for Claude Code?

A context window is Claude's working memory — the maximum amount of information Claude can hold at once. Claude's context window is 200,000 tokens (roughly 800,000 characters).

Why it matters: Large projects have hundreds of files. Claude can't read everything at once. It has to strategically choose which files to read, in what order. A big file read, a large test output, or a long conversation history all consume tokens.

Did you mention: That your job is to help Claude focus on the right information, not all information?

Question 7: Give an example of a vague prompt and a specific prompt. Why is the specific one better?

Vague: "Add error handling to the login function"

Specific: "In auth.js, the login function calls authenticate() but doesn't catch errors. If it throws, the app crashes. Add try-catch, log the error to logger.error(), and return a 401 response with 'Invalid credentials' message."

The specific prompt is better because Claude knows:

Which file to edit (auth.js)
What the problem is (no error catching)
What outcome you want (catch, log, return 401)
What style to use (look at how logger.error is used elsewhere)

Vague prompts force Claude to guess, waste context on wrong choices, and produce code that needs revision.

Did you mention: That specificity is about the goal, not micromanagement of steps?

Question 8: You ask Claude to refactor a function. The function is used in 7 other files. What should Claude do before editing?

Claude should:

Use Grep to search for all places where the function is called
Read all 7 files that call the function
Understand how each one uses it
Plan coordinated edits that update both the definition and all callers
Make all the edits together (atomic change)
Run tests once at the end

Claude should NOT edit the function first and then hope the callers still work.

Did you mention: The importance of searching first to discover the full scope before making any changes?

Question 9: What's an "atomic change"? Why does it matter?

An atomic change is a set of coordinated edits across multiple files that either all succeed or are all rejected. Either the refactoring is complete and works, or none of it happened.

Why it matters: If you rename a function in file A but only update 3 of 7 callers in other files, you've broken the code. It's better to do all the edits together, test once, and ensure consistency.

Did you mention: That atomic changes prevent broken intermediate states?

Question 10: Claude edits 5 files, runs tests, and tests fail. What should Claude do next?

Claude should:

Read the test error message
Understand which file the error is in and what went wrong
Reason about whether it's Claude's fault or a pre-existing issue
If it's Claude's fault, find and fix the problem (might be in any of the 5 files)
Run tests again
Repeat until tests pass

This is the agentic loop in action. Claude doesn't just barrel forward — it checks its work and adjusts.

Did you mention: That you should provide the error message to Claude, and let Claude diagnose?

Question 11: When Claude creates a pull request, what should you check before merging?

You should check:

The commit message(s) — Do they explain why the change exists, not just what it is?
The PR description — Does it clearly explain the refactoring and why it's needed?
The diffs — Do the code changes match the description? Are they correct?
Test results — Did the test suite pass?
Manual verification — If it's a user-facing feature, does it actually work?

Automated tests catch behavioral bugs, but they won't catch style inconsistencies or architectural concerns. That's your review's job.

Did you mention: That Claude handles the mechanics (staging, committing, pushing) but you handle the critical decisions (should this ship)?

Question 12: You're in a Claude Code session working on a large refactoring. After 20 minutes of conversation, Claude seems to be forgetting details from earlier files. What's happening, and what should you do?

What's happening: The context window is filling up. The conversation history, files Claude read early on, and command outputs are consuming tokens. Claude's older memory is fading as the limit approaches.

What you should do:

Recognize that the task is getting too big for one conversation
Ask Claude to commit what's been done so far
Start a new conversation and reference the commit/files already changed
Break the work into logical phases and tackle them one at a time

Alternatively: Help Claude focus by asking specific questions ("Look at file X and make change Y") rather than vague ones.

Did you mention: That breaking work into phases or smaller conversations is the right move?

Your Score

Count your correct answers: ___ / 12

Interpretation:

10–12: Excellent. You've internalized the concepts. Ready to move forward.
8–9: Strong understanding. Review any weak areas, then continue.
6–7: Solid foundation. Consider re-reading Lessons 9–13 before Phase 3.
Below 6: Spend time with the lessons again. These concepts are essential.

Key Takeaways

After this checkpoint, you should understand:

What Claude Code is: An agentic tool that reads code, reasons about tasks, acts (edits, runs commands), and checks results — all in a loop.
How to trust edits: The Edit tool is precise; you review before accepting; you stay in the loop if something goes wrong.
Context is finite: Your job is to help Claude focus on what matters, not load everything.
Specificity wins: Vague prompts produce garbage; specific prompts (with file names, reasoning, outcomes) produce better code faster.
Multi-file work requires coordination: Search for all dependencies first; edit everything together; test once; iterate if needed.
Version control is your partner: Claude handles git mechanics; you handle review and merge decisions.
The agentic loop is everything: Read → Reason → Act → Check, and when Check reveals a problem, loop back.

Moving Forward

You've completed Phase 2: Core Workflows. You now understand:

How Claude edits code (Lesson 9)
How it manages memory (Lesson 10)
How to ask clearly (Lesson 11)
How it handles complex multi-file tasks (Lesson 12)
How it works with version control (Lesson 13)
How to apply all this to a real project (Lesson 14)

Phase 3 will explore advanced topics: working in teams, handling real-world complexity, and troubleshooting when things go wrong.

But first, the next lesson: troubleshooting. When does Claude get confused? What are the common failure modes? And how do you fix them?

← Back to Curriculum · Lesson 16 →