Coding with AI tools cheat sheet (Claude Code)

1. 1What AI coding tools are good and bad atHow the models behind these tools work, the three ways you use them, and where they help or hurt, so you know when to reach for one and when to think first.8 concepts

   1. 1Large language modelThe model behind every AI coding tool: a program trained on huge amounts of text and public code that predicts the most likely next piece of text, called a…
   2. 2HallucinationA confident answer that is simply wrong: a function, option, file path or package that does not exist, or a version detail from before the model was trained.
   3. 3Context windowEverything the model can see at once: your messages, its replies, the files it read, command output and the tool's own instructions.
   4. 4Completion, chat and agentThe three ways you use these tools: completions suggest the next lines as you type, chat answers questions about code, and an agent reads files, edits several…
   5. 5Where AI helps mostWell-trodden work with a clear check: boilerplate, syntax you half remember, explaining unfamiliar code, first drafts of tests, mechanical refactors covered by…
   6. 6Where AI strugglesWork that depends on facts the model cannot see or rarely saw: your business rules, subtle concurrency, security decisions, new library versions, performance…
   7. 7Automation biasThe human habit of trusting output from a confident machine more than we should, and approving it with less care than we would give a colleague's code.
   8. 8Claude CodeAnthropic's coding agent.

   8 in this chapterOpen this chapter
2. 2Setup and project contextInstalling your tool, the instruction files that tell it how your project works, scoped rules, keeping secrets out of its view, and pointing it at exactly the files that matter.8 concepts

   1. 1Installing and starting your toolGetting the tool running inside a real project, signed in with your own account.
   2. 2Project instructions fileA Markdown file in the repository that the tool loads into every session: how to build and test, conventions that differ from the defaults, and gotchas.
   3. 3AGENTS.mdA plain Markdown instructions file at the repository root that many coding agents read.
   4. 4Generating a starter fileA built-in command that reads your codebase and drafts the instructions file for you, which you then edit down.
   5. 5Path-scoped rulesExtra instruction files that load only when the tool works on matching files, such as test files or one folder, so specialised guidance does not fill every…
   6. 6Keeping files out of contextSettings that stop the tool reading certain files, such as .env files, keys and customer data.
   7. 7What belongs in instructionsCommands the tool cannot guess, conventions that differ from the defaults, architecture decisions, environment quirks and known traps.
   8. 8Pointing at exact contextNaming the specific files, folders, terminal output or diffs the tool should read, instead of describing where code lives and hoping it searches well.

   8 in this chapterOpen this chapter
3. 3Prompting for codeTurning a task into something a tool can do well: small steps, a clear spec with a definition of done, a plan before code, reusable prompts and a fresh context for each task.7 concepts

   1. 1Small, checkable tasksBreaking work into steps small enough that you can describe the change in a sentence or two and check it in a few minutes, then giving the tool one step at a…
   2. 2A task specA short, structured prompt: the goal, the files involved, the constraints and what is out of scope, and how to prove it is done.
   3. 3Pointing at an existing patternNaming a file in your codebase that already does something similar well and asking the tool to follow it.
   4. 4Plan before codeAsking the tool to read the code and propose a plan, the files to change and the approach, without editing anything, then correcting the plan before any code is…
   5. 5Prompt templates for common tasksReusable shapes for the prompts you write every week: explain, fix a bug, add a feature and refactor, each ending with how to verify.
   6. 6Saved prompts and skillsPrompts saved as files in the repository and run by name with a slash, so a team shares the same review checklist, test workflow or release steps.
   7. 7Fresh context per taskStarting a new conversation for each unrelated task, and compacting or summarising a long one, so old detail does not confuse new work.

   7 in this chapterOpen this chapter
4. 4Reading and reviewing AI codeHow to review code you did not type: read every diff, run a checklist, explain it back, catch invented APIs and scope creep, and use AI review as a second pass, never the only one.7 concepts

   1. 1Read every diffLooking at exactly what changed, file by file and line by line, before you accept, commit or push it.
   2. 2Review checklist for AI codeA short, fixed list you run on every AI change, so review does not depend on how tired you are.
   3. 3Explain it backBefore you commit, explaining in your own words what the change does and why it works, without reading the tool's summary.
   4. 4Checking invented APIsVerifying that every function, method, option and configuration key in the change exists in the version you actually use.
   5. 5Unrequested changesEdits you did not ask for: renamed variables, reformatted files, new abstractions, extra features, deleted comments or tests, and code that is never called.
   6. 6Commit before each AI taskCommitting your working state before asking the tool for a change, then committing its reviewed change on its own with a clear message.
   7. 7AI review as a second passAsking a separate AI review, ideally in a fresh context, to look for bugs and security issues in a diff after you have reviewed it yourself.

   7 in this chapterOpen this chapter
5. 5Tests first, so AI output is checkedUsing tests as the specification and the judge: writing the first test yourself, spotting tests that cannot fail, listing edge cases and giving the agent a check it must pass.8 concepts

   1. 1Tests as the specWriting down the expected behaviour as tests before the code exists, so "done" means the tests pass rather than "the tool said it is done".
   2. 2Red, green, refactorThe test-driven loop: write a failing test (red), write the smallest code that passes it (green), then clean up with the tests still passing (refactor).
   3. 3Write the first test yourselfWriting at least the first, most important test by hand, then letting the tool suggest more cases that you review.
   4. 4Tests that cannot failTests that pass whatever the code does: asserting that a mock was called with what you gave it, snapshotting output nobody checks, or no assertions at all.
   5. 5Edge case listA list of the inputs most likely to break code: empty, one item, very large, negative, zero, null or missing, duplicates, unicode, time zones, concurrent calls…
   6. 6Give the agent a check to runTelling the agent exactly which command proves the work, the tests, type checker, linter or build, and asking it to run it and show you the output.
   7. 7Do not let it edit tests to passA rule that the agent may not change, skip or delete existing tests to make its change pass, unless you explicitly agree the test was wrong.
   8. 8Mutation testingA tool makes small deliberate bugs in your code, such as flipping a condition, and reruns the tests.

   8 in this chapterOpen this chapter
6. 6Debugging with AIUsing AI to find causes rather than paper over symptoms: reproduce first, give evidence, work through hypotheses, fix the root cause with a regression test and keep using the real debugger.7 concepts

   1. 1Reproduce before you askFinding the exact steps, input and environment that make the bug happen every time, before asking anyone, human or AI, to fix it.
   2. 2Minimal reproductionThe smallest piece of code and data that still shows the bug, with everything unrelated removed.
   3. 3Hypotheses, not fixesAsking for a ranked list of possible causes and how to test each one, then running the tests, instead of asking for a fix straight away.
   4. 4Paste the evidenceGiving the tool the full error, stack trace, logs, input and what you already tried, instead of a summary in your words.
   5. 5Symptom patchesChanges that hide a bug instead of fixing it: an empty catch block, a null check that skips the work, a retry loop, a disabled lint rule or a longer timeout.
   6. 6Root cause and regression testFixing the cause you proved, then keeping the failing test from your repro so the same bug cannot return unnoticed.
   7. 7Use the real debuggerSetting breakpoints, stepping through code and inspecting variables in your editor's debugger, or adding targeted log lines, to see what the program actually…

   7 in this chapterOpen this chapter
7. 7Agents: multi-file changes, permissions and safetyHow agents work, the permission modes and rules that decide what runs without asking, undo with checkpoints and Git, sandboxing, prompt injection, MCP and background agents.9 concepts

   1. 1The agent loopAn agent repeats a cycle: read the task, choose a tool (read a file, search, edit, run a command), look at the result, and decide the next step, until it thinks…
   2. 2Permission modesThe setting that decides which actions the agent may take without asking you: reading only, editing files, running commands, or everything.
   3. 3Allow and deny rulesSpecific rules that let trusted, repeated actions run without a prompt and block dangerous ones in every mode, such as pushing to Git or reading key files.
   4. 4Checkpoints and undoSnapshots the tool takes of files it edits, so you can roll its changes back to an earlier point in the conversation.
   5. 5Git as the safety netDoing every agent task on its own branch from a clean commit, so any change can be inspected, reverted or thrown away.
   6. 6SandboxingRunning the agent's commands with limited access to the file system and network, or inside a container or cloud machine, so a mistake cannot reach the rest of…
   7. 7Prompt injectionInstructions hidden in content the agent reads, such as a web page, an issue, a README or a dependency's docs, that try to make it do something you did not ask…
   8. 8MCP serversThe Model Context Protocol is an open standard for connecting agents to outside tools and data, such as a database, an issue tracker or a browser.
   9. 9Background and cloud agentsAgents that work without you watching: in a script or CI job, or on a cloud machine that returns a branch or pull request for review.

   9 in this chapterOpen this chapter
8. 8Security and licencesWhat never goes into a prompt, secrets, hallucinated packages, insecure patterns AI repeats, scanning, licences of copied code, data settings and your employer's or university's AI policy.9 concepts

   1. 1Never paste thisThe list of things that never go into a prompt, a file the tool can read or a screenshot you attach, whatever the tool's privacy settings say.
   2. 2Secrets out of code and contextKeeping secrets in environment variables or a secrets manager, listing .env in .gitignore, blocking it from the tool and scanning commits for leaks.
   3. 3Hallucinated packagesPackage names a model invents that do not exist, or that attackers have since registered with malicious code because models keep suggesting the same fake names.
   4. 4Checking a new dependencyConfirming a package is real, maintained, widely used and needed, and auditing known vulnerabilities, before adding it.
   5. 5Insecure patterns AI repeatsClassic flaws that appear often in generated code: SQL built by string concatenation, unescaped HTML, eval, disabled TLS verification, CORS set to allow…
   6. 6Static analysis on AI codeAutomated tools that scan source code for bug and security patterns without running it, run locally and in CI on every pull request.
   7. 7Licences and copied codeGenerated code can occasionally match public code closely, and that code may carry a licence with conditions such as attribution or sharing your changes.
   8. 8Data use and privacy settingsAccount and organisation settings that control whether your prompts and code may be kept or used to train models.
   9. 9Employer and university AI policyThe written rules on which AI tools you may use, on what code and data, and whether you must disclose it, set by your employer, client or course.

   9 in this chapterOpen this chapter
9. 9Keeping your skillsDeliberate practice with the AI switched off, attempting before comparing, using the tool as a tutor rather than an answer machine, and the fundamentals no tool replaces.7 concepts

   1. 1Deliberate practiceRegular, focused practice slightly beyond what you can already do, with feedback, done without AI completions so the struggle is yours.
   2. 2AI-off sessionsBlocks of time where suggestions and agents are switched off on purpose, for practice, exams or learning a new language.
   3. 3Attempt first, then compareWriting your own solution, or at least your own plan, before asking the tool, then comparing the two and noting what it did differently and why.
   4. 4Tutor mode promptsPrompts that make the tool ask you questions, give hints and review your reasoning, instead of writing the answer.
   5. 5Read the docs firstGoing to the official documentation of a language, library or tool before asking a model about it, especially for anything version-specific.
   6. 6Fundamentals AI does not replaceData structures and algorithms, how HTTP and databases work, reading unfamiliar code, debugging, Git, testing and writing clear explanations.
   7. 7Explain without notesExplaining a concept or a piece of your own code out loud or in writing, without looking anything up, as if to a classmate.

   7 in this chapterOpen this chapter
10. 10Shipping a real project with an agentTaking a small real project from spec to deployment with an agent: scope, a written spec, vertical slices, CI as the gate, one pull request per slice, honest disclosure and a write-up.7 concepts

    1. 1Scoping a project for an agentChoosing a project small enough to finish in a few weeks, with a real user, clear features and a way to test each one.
    2. 2A written specA short document in the repository listing users, features, data, out-of-scope items and how each feature will be verified, which you and the agent both work…
    3. 3Vertical slicesBuilding one feature at a time through every layer, database, API, UI and tests, so each slice works end to end before the next begins.
    4. 4CI as the gateAutomated checks that run on every push or pull request, tests, type check, lint and security scans, and must pass before anything merges.
    5. 5One pull request per sliceOpening a separate, small pull request for each slice, with a description of what changed, how it was tested and what the agent did.
    6. 6Disclosing AI useStating honestly where and how you used AI tools, in the README, pull request descriptions or commit trailers, and following any required format.
    7. 7The project write-upA short document explaining the problem, your design, what the agent did, what you changed or rejected and why, bugs you caught, and what you would do…

    7 in this chapterOpen this chapter
11. 11Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.124 terms

Claude Code, Cursor, Copilot, used well.