Claude · Module 02 of 8

Coding

Generate, debug, refactor, and architect software with Claude — from a single function to a multi-file codebase.

9 lessons36 exercises
Topics & techniques

Code generation

Turn specs and requirements into working code.

4 cards →
Knowledge card
Generate a Full Module From a Written Spec
Instead of asking Claude for a single function, you give it a short written specification — inputs, outputs, constraints, and file layout — and it returns a complete, coherent module.
L3 · Workflows
Workflow
Generate One Layer at a Time, Not the Whole Feature
A workflow where you ask Claude to build a feature one layer or slice at a time — data model, then business logic, then the endpoint, then the UI — verifying each before moving on, rather than requesting the entire feature in a single generation.
L3 · Workflows
Best practice
Give Claude the Types Before the Logic
A code-generation pattern where you (or Claude, with your approval) fix the types and function signatures first — the data shapes, inputs, and return types — and only then ask for the implementation that satisfies them.
L2 · Context engineering
Knowledge card
Point Claude at a File to Copy the Style
A code-generation pattern where, instead of describing your conventions, you hand Claude one existing file that already does something similar and ask it to write the new code in the same shape.
L2 · Context engineering

Debugging

Find and fix bugs with Claude instead of guessing.

4 cards →
Knowledge card
Add Logging Before You Let Claude Guess
A debugging pattern for bugs with no error — wrong output, silent misbehaviour — where you ask Claude to add temporary, targeted logging around the suspect path first, run it, and paste the output back before any fix is attempted.
L2 · Context engineering
Workflow
Make Claude Give Two Hypotheses and a Deciding Test
A debugging move that asks Claude to propose two competing explanations for a bug and then name the single observation, log line, or test that would distinguish them — turning debugging into an experiment instead of a guess.
L3 · Workflows
Knowledge card
Pair the Error With the Last Thing You Changed
A debugging pattern where you give Claude two things together — the complete error with its stack trace, and the diff or description of the most recent change — and ask it to explain how the change could produce that error.
L2 · Context engineering
Knowledge card
Make Claude Reproduce the Bug Before It Fixes It
A debugging pattern where you force Claude to first explain and reproduce the failure — in words or a failing test — before proposing any fix.
L2 · Context engineering

Architecture

Design systems and evaluate trade-offs before writing code.

4 cards →
Knowledge card
Write the Decision Record Before the Code
A pattern where, before implementing a significant choice, you have Claude draft a short Architecture Decision Record — the context, the decision, the alternatives rejected, and the consequences — so the reasoning is written down and durable.
L3 · Workflows
Knowledge card
Design the Interface With Claude Before Writing Any Code
A planning move: use Claude to nail down the public interface, data shapes, and boundaries of a component before a single line of implementation is written.
L3 · Workflows
Knowledge card
Make Claude Name the Trade-offs, Not Just the Winner
A decision pattern where you make Claude lay out the trade-offs of a design as an explicit table — options as rows, the criteria you care about as columns — instead of just handing you a recommendation.
L3 · Workflows
Knowledge card
Ask for Three Designs Before You Pick One
A design pattern where you ask Claude to propose three distinct approaches to a problem — with their trade-offs — before it writes any code or commits to one, then you choose and only then build.
L3 · Workflows

Refactoring

Restructure existing code safely without changing behaviour.

4 cards →
Knowledge card
Rename for Clarity Before You Restructure
A refactoring sequence where the first pass only improves names — variables, functions, parameters — with no structural change, and only after the code reads clearly do you move or split anything.
L2 · Context engineering
Knowledge card
Extract One Seam at a Time
A refactoring pattern for oversized functions or modules where you have Claude identify the natural seams — self-contained chunks of responsibility — and extract them one at a time, testing after each, rather than rewriting the whole thing in one move.
L3 · Workflows
Knowledge card
Pin the Behaviour With Tests Before You Refactor
A refactoring pattern where, before changing any structure, you have Claude write characterization tests that capture what the code currently does — including its quirks — so you can restructure with a green suite proving you changed nothing observable.
L3 · Workflows
Workflow
Refactor With Claude in Named, Behaviour-Preserving Steps
Refactoring by asking Claude for one named, behaviour-preserving move at a time — extract this function, rename that concept, inline this variable — each verifiable on its own.
L3 · Workflows

Multi-file workflows

Work across a whole repository, not one snippet.

4 cards →
Knowledge card
Batch Edits by Concern to Keep Diffs Reviewable
A pattern where you have Claude group a large change into separate batches by concern — pure refactor, behaviour change, formatting, dependency bump — and produce them as distinct commits or steps rather than one entangled diff.
L3 · Workflows
Knowledge card
Change the Contract First, Then the Callers
A multi-file editing pattern where, to change something used in many places, you have Claude change the definition — the type, signature, or interface — first, then work through the call sites the change surfaces, rather than editing scattered usages by hand.
L3 · Workflows
Knowledge card
Give Claude the Map Before a Multi-File Edit
Before asking Claude to change something that spans files, giving it a short map — which files are involved, how they relate, and where the edit should and shouldn't reach.
L3 · Workflows
Knowledge card
Agree the Edit Manifest Before the First Change
A pattern where, before Claude touches anything, it produces a manifest — the list of files it will change and, in one line each, what changes in them — and you approve or trim that list before a single edit happens.
L3 · Workflows

Claude Code

Anthropic's agentic CLI for working in a real codebase.

4 cards →
Best practice
Keep a CLAUDE.md That Actually Changes the Output
A discipline for the CLAUDE.md file that Claude Code reads at the start of every task: keep it to rules that actually change behaviour — real commands, real conventions, real boundaries — and ruthlessly cut anything the model would do correctly anyway.
L3 · Workflows
Knowledge card
Let Claude Code Run the Tests and Close the Loop
A Claude Code practice where you let the agent run the project's tests, type checker, or build itself after making a change, and require it to iterate until they pass before reporting the work done.
L3 · Workflows
Best practice
Let Claude Code Explore the Repo Before It Edits
Working with Claude Code — Anthropic's agentic CLI — by letting it read and understand the codebase first, agree a plan, then make edits and run the tests itself, rather than demanding a change blind.
L4 · Multi-AI systems
Workflow
Have Claude Code Plan First, Then Approve the Plan
A workflow where you ask Claude Code to produce a written plan — the files it will change and the approach — and get your sign-off before it edits anything. You review the intent, which is cheap, rather than the diff, which is expensive to unwind.
L3 · Workflows

Testing

Get Claude to write tests that actually protect you, not tests that just pass.

4 cards →
Knowledge card
Mine Claude for the Edge Cases You Missed
A testing pattern where, rather than asking Claude to write tests, you first ask it to enumerate the edge cases and failure modes of a function — then decide which deserve tests. It's using Claude as an adversary against your code, not a scribe.
L2 · Context engineering
Best practice
Make Claude Test Behaviour, Not Implementation
A prompting discipline that tells Claude to assert what a unit does from the outside — given these inputs, expect these outputs or effects — rather than how it does it internally. The test describes a contract, not a call sequence.
L3 · Workflows
Knowledge card
Turn Your Examples Into Table-Driven Tests
A testing pattern where you give Claude a set of concrete input-to-output examples and ask it to generate a single table-driven (parameterized) test that runs each example as a row, rather than a separate test function per case.
L2 · Context engineering
Best practice
Ask for the Test That Would Have Caught the Bug
A rule for bug fixes: before Claude changes any code, have it write the single test that fails today because of the bug and will pass once the bug is gone. The test, not the patch, is the deliverable you review first.
L2 · Context engineering

Code review

Use Claude as a fast, tireless first-pass reviewer — then keep the judgement calls for yourself.

4 cards →
Workflow
Ask Claude 'What Would Break This?' Before You Ship
An adversarial review move: instead of asking Claude if the code is correct, ask it to actively try to break the code — enumerate the inputs, timings, and conditions under which it fails. You're recruiting the model as a red team, not a rubber stamp.
L2 · Context engineering
Knowledge card
Ask Claude to Rank Findings by Severity
A review pattern where you require Claude to label every finding with a severity — blocking, should-fix, nitpick — and order them worst-first, so a flat list of comments becomes a triaged one.
L2 · Context engineering
Best practice
Give Claude a Review Checklist, Not 'Review This'
A pattern where you hand Claude an explicit checklist of what to look for — correctness, edge cases, security, readability — and ask it to go category by category, instead of an open-ended 'review this code'. The checklist is the spec for the review.
L2 · Context engineering
Knowledge card
Have Claude Review the Diff, Not the Whole File
A review pattern where you give Claude the diff — the lines that actually changed — plus enough surrounding context to judge them, and ask it to review only the change, not to critique the whole file.
L2 · Context engineering

API integration

Wire your code to third-party and model APIs without the guesswork and the silent failures.

4 cards →
Knowledge card
Design for the Error Responses First
An integration pattern where you have Claude map out and handle the failure responses of an API — timeouts, rate limits, 5xx, partial or malformed bodies — before wiring up the happy path, so resilience is designed in rather than bolted on after an incident.
L3 · Workflows
Knowledge card
Generate a Typed Client From the Schema
An integration pattern where you give Claude the API's schema — an OpenAPI spec, a GraphQL schema, or even a few real response payloads — and have it generate typed models plus a thin client, instead of hand-writing untyped fetch calls scattered through your code.
L3 · Workflows
Best practice
Tell Claude to Make API Failures Loud, Not Swallowed
An instruction to Claude that every external call must handle timeouts, non-2xx statuses, and malformed responses explicitly — surfacing typed errors — rather than the default happy-path client that assumes the network always works and JSON always parses.
L2 · Context engineering
Best practice
Paste the Real API Docs Before Claude Writes the Client
A grounding step: paste the actual endpoint reference — routes, request/response shapes, auth, error codes — into the context before asking Claude to write the integration, instead of relying on what it remembers about the API.
L2 · Context engineering
Claude for coding

Why Claude is a developer favourite

Claude has a strong reputation among engineers for a reason: it writes disciplined code, reasons well over large amounts of it, and tends to stay faithful to the constraints you set rather than inventing its own. Its large context window means you can give it the real surroundings — the types, the related files, the error, the spec — instead of a lonely snippet, and get answers that respect your actual system. The rule of thumb is to give Claude the map before the edit.

A reliable loop for real code

The developers who get the most from Claude follow a loop rather than one-shotting. Design before you code so the plan is agreed before a line is written. Generate one layer at a time so each piece is reviewable. Reproduce a bug before fixing it so Claude commits to a real theory of the failure, not a plausible patch. For anything spanning files, give it the map of the codebase first. And if you work in the terminal, Claude Code turns these habits into an agentic workflow — explore, plan, then edit.

The coding topics to explore

This section is the deepest in the hub, covering code generation, debugging, architecture, refactoring, multi-file workflows, Claude Code, testing, code review, and API integration. Start with whichever card matches the problem in front of you right now.

Frequently asked
Is Claude good for coding?

Yes — it is widely preferred for coding discipline, faithful adherence to constraints, and reasoning over large amounts of code. Its large context window lets it work with the real surrounding files rather than isolated snippets, which improves the quality of what it produces.

What is the best way to debug with Claude?

Have Claude reproduce the bug before fixing it — give it the error and the failing code and ask it to explain the exact cause first. That forces a real theory of the failure instead of a plausible patch, which the debugging cards below cover in detail.

Can Claude work across multiple files?

Yes. Give it a map of the relevant files and how they connect before asking for edits, and use Claude Code for agentic, multi-file changes in your terminal. Providing structure up front is what keeps multi-file work coherent.

What is Claude Code?

Claude Code is Anthropic's agentic coding tool that works in your terminal and codebase — reading files, planning, and editing across a project. It works best when you let it explore before editing and make it plan then wait for approval.

Test yourself

How well do you code with Claude?

Six questions on getting production-grade code out of Claude — from framing a request to reviewing what comes back. No sign-up, instant score, and you can share how you did.

  1. Q1 You want Claude to fix a bug. What gives you the best shot at a real fix rather than a plausible-looking patch?
  2. Q2 Before Claude writes a non-trivial feature, the highest-leverage move is to…
  3. Q3 Which context actually improves a code-generation prompt the most?
  4. Q4 Claude returns code that runs and looks clean. What should you do?
  5. Q5 What's the reliable way to use Claude Code in a real codebase?
  6. Q6 You need Claude to review a pull request. The best use of it is as…
0 / 6 answered