Lesson 2: The Feedback Loop — Help Claude Code Help Itself
The highest-leverage thing you can do with Claude Code is give it a way to verify its own work. When Claude Code can check whether something works — not just whether it "looks right" — everything improves.
Fast-track: Already use tests for verification, know the explore/plan/implement/commit workflow, and use visual tools to check UI? Skip to Lesson 3.
"Looks right" isn't good enough
When Claude Code writes code, it can look at the code and think "that looks correct." But looking correct and being correct are different things.
Consider: Claude Code writes a function that formats dates. The code looks fine. But does formatDate("2024-02-29") actually return "February 29, 2024"? Without running it, Claude Code is guessing.
The fix is simple: give Claude Code something that tells it whether the code works.
There are three ways to give Claude Code feedback so it can catch and fix its own mistakes: tests, error messages, and screenshots. From simplest to most powerful:
Tests as verification
The most reliable feedback loop is tests. A "test" is just code that checks whether other code works correctly — like a spell-checker for your software.
Instead of asking Claude Code to write a feature and hoping it works, tell it to:
- Write a test that defines what "working" means
- Run the test (it should fail — the feature doesn't exist yet)
- Write the code to make the test pass
- Run the test again to confirm
Say this directly to Claude Code in your terminal:
Write a test for the date formatting function first, then implement the function to make the test pass. Run the tests after each change.
When Claude Code can run tests, it catches its own mistakes. It doesn't need you to tell it something's broken — the test output tells it.
Most new projects don't have tests, and that's fine. You don't need a full test setup to use this pattern. Just tell Claude Code:
"Set up a basic test framework for this project, then write a test for [the feature you're building]."
Claude Code will install the right tools (usually Vitest or Jest for a JavaScript project), create the test file, and run it — all from the terminal. You don't need to know how testing frameworks work. Claude Code handles the setup.
Pasting errors with full context
When something breaks, don't paraphrase the error. Copy the entire error message and paste it directly into Claude Code.
Bad:
"It says there's an error somewhere"
Good:
Here's the full error: [paste the complete error from your terminal or browser]
The full error tells Claude Code exactly which file and line number has the problem. A paraphrase makes it guess. When in doubt, paste more rather than less.
Visual verification
For UI work — anything you can see on screen — tests and error messages aren't always enough. A button might work perfectly but look terrible.
You can help Claude Code verify visually by pasting screenshots directly into the terminal. Take a screenshot of what you see (Cmd+Shift+4 on Mac, Win+Shift+S on Windows), then paste it into Claude Code with Cmd+V on Mac (or Ctrl+V on Windows). If Cmd+V doesn't work on your Mac terminal, try Ctrl+V instead. Tell Claude Code what's wrong:
"Here's what the page looks like. The header is overlapping the content. Fix it."
Claude Code can see images you paste — it's not just text. This works directly in the terminal, no browser or chatbot needed.
Claude in Chrome: the visual feedback loop
There's an even more powerful option: the Claude in Chrome extension. Once installed, Claude Code can open your browser, navigate to your app, take screenshots, and check the UI — all by itself, directly from your terminal session.
This turns Claude Code into a full QA loop: write code → open in browser → see the result → fix issues → repeat. All from the terminal. You don't need to switch between apps.
Set it up now
This takes about two minutes and it's worth it — you'll use this constantly for the rest of the course.
1. Install the extension. Open Chrome and go to the Claude in Chrome extension on the Chrome Web Store. Click Add to Chrome. If you use Microsoft Edge, the same extension works there too.
2. Connect it to Claude Code. In your terminal, type /chrome inside a Claude Code session:
/chrome
Claude Code will detect the extension and connect to your browser. If it asks you to restart Chrome, do that — the extension needs Chrome to reload a configuration file the first time.
3. Try it. Once connected, ask Claude Code to check your app:
Open localhost:3000 in Chrome, take a screenshot, and tell me what you see. Does the layout look correct?
Claude Code will open a new tab in your actual browser, navigate to the page, take a screenshot, and analyze it. You'll see it happen in real time.
The Claude in Chrome extension gives Claude Code the ability to control your browser — opening tabs, clicking elements, reading page content, and taking screenshots. It uses something called MCP (Model Context Protocol), which you'll learn about in Module 3. For now, just think of it as a bridge between your terminal and your browser.
Claude Code uses your browser's existing login state, so it can access any site you're already signed into. Browser actions run in a visible Chrome window — nothing happens in the background.
- Extension not detected? Make sure it's enabled at
chrome://extensions. Then restart Chrome and run/chromeagain in Claude Code. - Using Edge? Same extension, same setup — it works in both browsers.
- Still not working? Run
claude --versionand make sure you're on version 2.0.73 or higher. Update with the same installer command from Lesson 2 of Module 0.
The four-phase workflow
The most effective workflow with Claude Code follows four phases:
| Phase | What happens | Mode |
|---|---|---|
| Explore | Claude Code reads the codebase, understands the structure | plan mode |
| Plan | Claude Code proposes a plan, you review and approve | plan mode |
| Implement | Claude Code writes the code, runs tests, iterates | default / auto-accept edits mode |
| Commit | Claude Code commits the changes with a clear message | default mode |
You don't always need all four phases. For a quick bug fix, you might go straight to implement. But for anything non-trivial — new features, refactors, architectural changes — the explore/plan/implement/commit cycle keeps things on track.
Press Shift+Tab to cycle between modes. In plan mode, Claude Code will explore and plan but won't write any code. This is great for:
- Understanding a codebase before making changes
- Getting Claude Code's recommendation before committing to an approach
- Reviewing a plan before letting Claude Code execute it
Once you approve the plan, switch back to default or auto-accept edits mode and tell Claude Code to proceed.
Course-correcting early
Don't wait until Claude Code is done to tell it something's wrong. The earlier you catch a problem, the less context is wasted.
- Escape — Press Escape to stop Claude Code mid-response. Use this when you see it going in the wrong direction.
- "Undo that" — If Claude Code just made a change you don't want, say "undo that" and it will revert.
/rewind— Roll back to before the bad prompt and try again.
The two-correction rule from Lesson 1 applies here too: if you've corrected Claude Code twice and it's still not getting it, /clear and start over. Something in the conversation is misleading it.
Checkpoint
- I understand why "looks right" isn't enough — Claude Code needs to run verification
- I know how to tell Claude Code to write tests before implementing
- I know how to paste errors with full context directly into Claude Code
- I know I can paste screenshots into Claude Code for visual verification
- I understand the four-phase workflow: explore, plan, implement, commit
- I know how to course-correct early (Escape, undo, /rewind)