home
›
cheatsheets
›
ai_assisted_development
›
ai_coding_assistants
Free to read Every card and diagram, and Quiz me
2
Free account Star cards. Your Quiz me marks are kept, so next time you drill just what you missed
3
Pro All 51 answers on this sheet, My sheet across every topic, and PDFs
A free account keeps your stars and Quiz me marks. Pro adds all 51 answers on this sheet, My sheet across every topic, and PDFs.
/
Read
Quiz me
Comfortable
Compact
My misses 0
Click any code to copy it
Done 0 /0
To review 0
On this sheet
The model
01 How assistants work02 Choose tools & models03 Context & prompts04 Coding workflows05 Review & verify06 Secrets, IP & policy07 Rollout & metrics
The model An assistant predicts likely code from what it can see. Nothing in that process proves the code is right, so every answer is a draft. Context sets the quality. The model sees only the code, files and rules the tool sends. Missing context makes it guess, and unrelated files hide the details that matter.The four modes are autocomplete, chat, edit and agent. Each step up gives the tool more freedom and more risk, so pick the lowest step that can do the job. Delegate as far as you can check. Hand off work that a compiler or tests can verify. Keep design and costly decisions with people.You own every line you commit. If you can't explain a line or show how you checked it, it isn't ready to merge.The model sees only what the tool sends it. In agent mode the tool runs the checks and feeds failures back. You review the diff before anything ships.
How assistants work what they do, and what to hand them Completion and fill-in-the-middle prefix middle suffix at the cursor The model reads the code on both sides of the cursor, then writes the middle.prefix suffix middle in training Training moves the middle to the end, so the model learns to read both sides first.Tell AI completion from IDE autocomplete Autocomplete offers real symbols. AI drafts new, unchecked code.
Explain fill-in-the-middle The model reads code on both sides of the cursor and fills the gap.
Say why completion has its own model Chat models misplace inserts. Completion models keep up with typing.
Trap Ghost text looks like autocomplete, but nothing checked it. It can call an API that doesn't exist.
Pick a mode Type code you already have in mind Inline autocomplete. Press Tab to accept.
Explain an error or compare designs Chat. It changes no files unless you ask.
Make one focused change you can see as a diff Edit mode, on selected code or a few files.
Hand off a clear task that tests can check Agent mode. It searches, edits files, runs commands and retries.
Tip Use autocomplete when you know what to write, and chat when you still need to think it through.
Use agent mode safely Spot a good task for an agent Clear, follows existing patterns and has reliable automated checks.
Spot a risky one A vague ask, weak tests, or access to production or credentials.
Give the agent its own branch and folder git worktree add -b agent-task ../agent-task
Tip Review its plan, limit its files and commands, and approve risky actions yourself.
Trap Passing tests can hide a wrong guess about the business. Read the diff, not only the test result.
What to hand off Pick work to hand off Well-known patterns a test can check, like boilerplate and config.
Spot work to keep for yourself New architecture, business rules, concurrency, performance tuning.
Tip On novel work, decide the design yourself. Then ask it to list failure modes or compare options.
Trap On unfamiliar problems it sounds confident and can ignore a key constraint.
Context & prompts what the model sees, and what you ask for What the model sees List what an assistant usually sees Your file, selection, open tabs, attached files and search results.
Choose exactly what it reads Mention or attach files, symbols, folders or docs.
Pick what to attach The interface, one close example, the test, and current library docs.
Trap More context isn't always better. A whole folder costs tokens and buries what matters.
Work in a big codebase Find code by meaning A semantic index. It scales, but may return a related, stale snippet.
Find an exact name or string Text search. It works only when you know the term.
Get a compact outline of files and symbols A repository map. It leaves out the implementation.
Read the code as it is now Agent exploration. Current, but costs time and tokens.
Keep a long task on track Start fresh when it gets confused. Keep a handoff document.
Tip Start from a map, not a dump. Find the owning module, its tests and one current example.
Trap A bigger context window doesn't fix a repo dump. Relevant, ordered evidence still works better.
Rules files Give Claude Code, Cursor or Copilot standing rules CLAUDE.md .cursor/rules/ .github/copilot-instructions.md
Decide what goes in one Commands, layout, required helpers and the definition of done.
Give one subsystem its own rules Put a scoped rules file next to it, if the tool supports that.
Enforce a limit the agent can't skip In Claude Code, add a hook or a permission deny rule.
Tip Write direct actions like "use the shared HTTP client", not advice like "write clean code".
Trap A rules file is guidance, not enforcement. The model reads it as context and can still ignore it.
Write a code prompt Goal and exact signature Add parseCsvLine(line: string): string[] Constraints Node 22. No new dependencies. An input and its output a,"b,c" -> ["a", "b,c"] Edge cases An unclosed quote throws ParseError. Non-goals Don't change any existing export. A check you can run Add unit tests for each rule above.
Name the parts of a good code prompt Goal, constraints, an example, edge cases, non-goals and a check.
Show the project's style Paste one existing handler or test for it to copy.
Narrow the possible solutions Allowed files, the runtime, dependencies, and what must not change.
Tip Write it like a ticket for someone new to the codebase.
Trap "Write a CSV parser" leaves it guessing about quotes, errors and dependencies.
Prompt a tightly scoped edit Fence in an edit Allowed files, fixed behavior, required tests and forbidden actions.
Order the steps Inspect, explain, plan, then edit. Stop if context is missing.
Prompt a bug fix Give a failing test or an exact repro, and ask for the smallest fix.
Tip Ask for a summary of changed files and checks run. Tight limits make any drift easy to see.
Coding workflows test-first, refactors, reading code and commits Test-first with an assistant Start the loop One failing test for one behavior. Check its edge cases yourself.
Get it to pass Ask for the smallest code that passes. Run it and read the diff.
Clean up the code Refactor while the suite stays green.
Tip For important code, review the tests apart from the code, so one wrong assumption can't shape both.
Trap An agent may weaken or delete a failing test just to finish. Read every test change.
Refactor safely Protect behavior before you start Add characterization tests that record what the code does today.
Ask for one change at a time One named change, like extracting a function. Same behavior.
Save a checkpoint after each step git add -A && git commit -m "checkpoint"
Tip Have it list the bugs it spots instead of fixing them inside the refactor.
Trap Unit tests alone can miss a broken boundary. Finish with integration checks.
Learn an unfamiliar codebase Get a map of a new repo Major modules first, then one request traced from entry to storage.
Find where a rule is enforced Ask where it lives, with the files and symbols behind each claim.
Trap Models sometimes describe the design they expect, not the code that exists. Open the files and check.
Commit messages and PRs Draft a commit message git diff --staged Give it this output and your team's format.
Add what the diff can't show The reason, issue links, rejected options and breaking changes.
Trap It can invent evidence, like tests that never ran. Cut every claim you can't back up.
Big multi-file agent changes Set limits before the agent starts Allowed files, invariants, public interfaces and acceptance tests.
Spot files it shouldn't have touched git diff --stat main
See every change it made to tests git diff main -- '*test*'
Tip Work in batches a person can review, each checked against one approved example.
Trap Agents make failures vanish by weakening tests, adding packages or changing config. Check all three.
Autocomplete etiquette when pairing Start a pairing session Agree whether suggestions stay on. Ghost text distracts some people.
Take a big suggestion while driving Pause, read it aloud and say why it fits.
Tip In an interview or assessment, ask if AI is allowed and say when you use it.
Trap A suggestion is only a proposal. It shouldn't settle a disagreement.
Your own skills and interviews Keep doing the thinking yourself Sketch the design first, and do small tasks without AI now and then.
Probe a candidate who says AI writes their code Ask how they specified, reviewed and tested it, and caught mistakes.
Describe your own AI use in an interview Where it helps, where you keep control, and one failure you caught.
Tip Mature use shows as clear ownership, not a share of generated lines.
Trap If you can't rebuild, change or run what it produced, you delegated too far.
Review & verify catch what the model got wrong Review a generated change Know what to look for in the diff Unrelated edits, invented APIs, duplicate helpers, changed tests.
Trace more than the happy path Empty or bad input, permission errors, a failing external service.
Run the machine checks Formatter, compiler and static checks, then focused tests.
Trap A green suite isn't proof. Generated tests can pass while checking the wrong behavior.
Catch invented APIs and packages Explain a hallucinated API A method, option or package the model made up to fit a pattern.
Catch an invented method Compile, type-check, run tests, and check the docs for your version.
Check a package before you install it npm view <pkg> Check its repo, maintainers, release history and downloads.
Explain slopsquatting Attackers register package names that models often invent.
Tip Make package installs need human approval, and use lockfiles and an approved registry.
Trap Telling the model to check packages isn't a security boundary. Registry controls must block them.
Test generated code Write tests from the requirement Not from the code. Cover empty, boundary, bad and failing cases.
Try many inputs at once Property-based tests.
Find assertions that never catch a bug Mutation testing.
Test a change that crosses a service or database Integration or contract tests.
Tip For critical work, have a person write some tests, so one model can't shape code and checks.
Trap Run every test the model says it ran. Read failures yourself instead of letting it explain them away.
Security holes it repeats Name the flaws AI code repeats Unsafe queries, weak validation, missing authorization, weak crypto.
Prevent them at scale Secure templates and approved wrappers for auth, storage and network.
Catch them in CI Static analysis, dependency scanning and targeted security tests.
Tip Give agents least privilege, with approval for network, credential and production commands.
Trap Models copy outdated examples and often write only the happy path, with no safe failure handling.
CI when AI writes most of the code Add checks for mistakes AI makes often Duplicated blocks, unsafe APIs and unexpected test changes.
Send sensitive paths to stronger review Path rules like CODEOWNERS for auth, payments and infrastructure.
Stop an agent weakening CI Require approval before it changes CI rules or snapshots.
Trap Piling on weak checks causes alert fatigue. Give every gate an owner and a clear response.
Review norms and accountability Review a pull request full of generated code Judge evidence, not confidence. Ask for a spec, tests and risk notes.
Name who's accountable for an AI-caused outage The engineering org. Author, reviewers and leaders share it.
Run the postmortem Find which spec, permission, test, review or rollout control failed.
Tip Split a huge generated diff, or redo it as a deterministic codemod.
Trap "The AI wrote it" is no defense. Whoever submits the code must be able to explain every line.
Secrets, IP & policy what may enter a prompt, and who decides Keep secrets out of prompts Say where a pasted secret ends up On another system, in logs, chat history or backups.
Know what never to paste Keys, tokens, env files or real customer data. Use placeholders.
Catch a secret before it leaves Run secret scanning in local hooks and in CI.
Tip Exclude sensitive paths in the tool's settings, and keep credentials in a secret manager.
Trap A secret that reached a prompt is compromised. Rotate it, then record the incident.
Licensing and IP Name the licensing risk Output can match licensed code, with attribution or copyleft duties.
Block matches to public code Turn on the public-code filter, and run your usual license scans.
Check the vendor's terms Output ownership, training use, retention and any indemnity.
Tip Some customer or regulated projects require you to disclose AI code, or ban it. Check the contract.
Vet a vendor before it sees your code Check the data terms No training on your code, retention, data location, subprocessors.
Check the admin controls SSO, account removal, role policies, audit logs, model controls.
Check the agent features They need their own command permissions and sandboxing.
Trap Test each control per feature. Copilot's content exclusion hasn't covered Chat's Edit and Agent modes.
Write an AI usage policy Decide what the policy approves Tools, accounts, models, and which data classes may enter a prompt.
Cover agents on their own Allowed commands, network and production access, approval gates.
Set expectations for people Human ownership, review, testing, disclosure and incident reporting.
Trap A document alone won't stop an unsafe extension or an overpowered agent. Add technical controls.
Controls across a large org Decide who owns the controls A central layer owns vendors, identity, data policy and logging.
Match tools to data sensitivity Classify repos, and map each class to allowed models and features.
Enforce the rules Managed settings, endpoint controls and CI, not only a document.
Trap Block normal work without a safe path, and engineers route around you. Pair controls with support.
Rollout & metrics adopt it, measure it, keep the codebase healthy Measure impact with DORA Name DORA's throughput metrics Change lead time, deployment frequency and failed deployment recovery time.
Name its instability metrics Change fail rate and deployment rework rate.
Say why you track both DORA 2025 linked AI adoption to more throughput but less stability.
Tip Record a baseline, compare similar work, and look at distributions. Gains are rarely uniform.
Trap Don't credit the tool for every change in a broad metric. Teams, projects and release processes differ.
Avoid vanity metrics Spot a vanity metric Lines of code, commits, PR and suggestion counts. AI inflates them.
Measure outcomes instead Lead time, review delay, rework, change failures and incidents.
Use suggestion acceptance rate Only as a tool-health signal. A low rate can mean poor context.
Trap Never rank engineers or set acceptance targets. People game the number and trust drops.
Roll out to fifty engineers Prepare before anyone gets a seat Classify repos, approve vendors, and set up identity and audit.
Run a pilot A small, mixed group. Record a baseline, then train them.
Decide whether to expand Check defects, rework, lead time and feedback, then grow in stages.
Tip Remove inactive seats and publish what you learn. Keep usage visible without watching individuals.
Trap Stop or narrow the rollout if the quality or security evidence gets worse.
Run a bake-off Pick the test tasks Real, repeatable work, including a multi-file and a security task.
Keep it fair Same repo state, prompts and model tier. Define success up front.
Score each run Success, defects, review time, latency, cost, developer experience.
Tip Review the enterprise controls apart from the task runs. A good demo doesn't prove they're safe.
Trap One developer's taste skews the result. Use several, and record where each tool failed.
Show ROI to an executive Show the outcomes A pilot against a baseline on lead time, rework and incidents.
Count every cost Licenses, premium usage, training, admin and extra verification.
Tip Give a decision with expected value, risks and review dates. Say where the tool didn't help.
Trap Don't turn correlation into a causal claim. State your confidence limits.
Keep the codebase healthy Name the long-term risks Duplicate logic, extra layers, weak tests, code nobody understands.
Counter them Module owners, architecture rules, templates and small PRs.
Tip Count deleting unneeded generated code as a win. Don't reward volume.
Team workflows as agents grow Say how the work shifts From typing code to specifying, constraining and verifying changes.
Get a team ready for more agents Acceptance criteria, reliable tests, isolated least-privilege agents.
Tip Roles change, but people still own priorities, architecture, risk and the call to release.
Trap More agents in parallel only help if verification keeps pace with generation.
Nothing matches. Try a shorter word, or clear the search.
Practice Guided practice One question at a time, with the ones you miss coming back.
Practice 51 interview questions Full answers, from beginner to expert.
Found this useful? Pass it on.
Share on LinkedIn
Share on X
Copy link
This sheet stays free. With Pro , you can:
Every answer on this sheet. Read the full answer to all 51 questions it links, not just the 7 free ones.
My sheet. The cards you star and the ones you miss in Quiz me, from every sheet, on one page to quiz and print.
PDFs. Download this sheet and My sheet, laid out for A4, with every question a link to its answer.
The rest of Pro. Every answer in the question library, and 1,000 AI credits a month.