It's an agent, not a chatbot

Most people arrive at Claude Code from a chat window, and they bring the chat habits with them. They ask a question, get code back, copy it, paste it, run it, and paste the error back. That works — and it wastes almost everything the tool is for.

Claude Code has hands. It reads your files, edits them, runs your tests, greps your codebase, and makes commits. You're not asking it for an answer. You're handing it a job.

The loop

Under the hood it runs the same cycle a competent engineer runs:

• Gather context — read the files, search for the function, look at how things are done here.
• Act — write the change.
• Verify — run the tests, hit the endpoint, check the output.
• Repeat — until the job is done or it's stuck.

That loop is the whole product. Everything in the rest of this course is really about making each step of it go well: giving it the context it can't guess (Chapter 2), agreeing on the plan before it acts (Chapter 3), and insisting it actually verifies (Chapter 4).

What changes about how you ask

Once it has hands, the shape of a good request changes. You stop asking how and start describing the outcome — and where to find the truth.

How do I add a rate limiter to an Express route?

You'll get a textbook answer using a library you don't have, in a style your repo doesn't use, which you then have to adapt yourself.

Add rate limiting to the POST /api/invite route in src/routes/invite.ts.

Match how we do middleware elsewhere in that folder. We already have redis
wired up in src/lib/redis.ts — use it rather than an in-memory store.
Limit: 5 requests per hour per account.

Add a test alongside the existing route tests, and run the suite when you're done.

The second version isn't longer because longer is better. It's longer because it answers the questions the agent would otherwise have to guess at: which file, which conventions, which existing pieces to reuse, and how we'll know it worked.

That last part matters. It doesn't know what your team decided last sprint, which module is deprecated, or that the "obvious" refactor was tried and reverted. Anything that lives only in your head or in a Slack thread is invisible to it — which is exactly why the next chapter is about context.

What it's genuinely good at

Be honest about the shape of the work, and you'll reach for it at the right moments:

• Well-specified changes that touch a lot of files. Renames, migrations, threading a new parameter through six layers. Tedious for you, trivial for it.
• Understanding unfamiliar code. "What does this module do, and who calls it?" is a superpower on a codebase you just inherited.
• Debugging with a reproducible failure. A stack trace and a failing test give it a target it can hit and check.
• The stuff you'd put off. Tests for the untested file, the script you keep meaning to write, the error handling you skipped.

And where it struggles

• Taste and product judgment. It'll happily build the wrong feature beautifully. Deciding what to build is still yours.
• Anything you can't verify. If neither of you can tell whether it worked, you've just generated confident-looking risk.
• Enormous, vague rewrites. "Modernize the codebase" ends in a sprawling diff nobody can review. Small, sharp tasks land; giant ones flail.
• Facts about the last few months. New library versions and fresh APIs may have shifted under its training data. If a detail is load-bearing, point it at the real docs and have it check.

None of this is exotic. It's the same judgement you'd apply to a capable new colleague: give them the context, agree on the plan, check the work. The difference is that this colleague works in twenty-second increments and never gets bored — so the habits pay off many times a day.

Next: the single biggest lever on how well any of this goes.