InterviewKata
AI engineering · Module 05 of 21 · Level 2: Working with AI

Prompting and context engineering

The same model gives a mediocre answer to one request and an excellent one to another. The difference is almost always the brief. This module teaches the six things every good brief contains, following what Anthropic, OpenAI and Google currently recommend for their own models.

1. The idea

A brilliant engineer joins your team today. They know every language and framework, but nothing about your product, your codebase, or what "good" means here. Ask them to "add tests" and they'll guess. Brief them properly and they'll nail it on the first try.

A prompt is everything you send: your request plus the instructions, files and examples that go with it. Anthropic's own guide puts it this way: think of the model as a brilliant but new employee who lacks context on your norms and workflows. Its golden rule: show your prompt to a colleague with no context; if they'd be confused, the model will be too.

A good brief has six parts. You won't need all six for a quick question, but a task that matters needs most of them:

  1. Goal: what you want, in one sentence, and what it's for.
  2. Context: what it needs to know: which files, which framework, who the users are. Point to files rather than pasting them.
  3. Constraints, with the reason: what must or mustn't happen, and why. "Don't change the public API: three other services call it" is followed far better than "DON'T CHANGE THE API".
  4. Examples: one to five samples of the output you want. All three vendors call examples one of the most reliable ways to steer format and style.
  5. Output format: a diff, a table, JSON, three bullet points.
  6. Definition of done: how you'll both know it's finished: "all tests pass", "covers these five cases".

Context engineering is the bigger idea behind this: deciding everything the model sees (the brief, project instructions, files, tools and history), not just the words of your request. Module 02 showed why less, better-chosen context wins.

2. How it works

Six parts go in; the model's output is checked against the definition of done. Missing parts get filled with the model's guesses.

Step through a prompt makeover. Each frame adds one part of the brief; the bar shows how close the result gets to what you actually wanted (illustrative).

3. Try it yourself: the brief checker

Paste or write a prompt and see which parts of a good brief it has. The checks are simple keyword heuristics, a nudge rather than a grade.

    4. Why it matters at work

    Most "the AI is bad at this" moments are briefing problems. These patterns fix the common ones, in any tool:

    SituationSay this
    Vague request"Before starting, ask me up to five questions that would change your approach."
    Big task"Break this into steps of under 200 changed lines each. Do step 1 only, then stop."
    Unfamiliar code"Explain this module as if onboarding a new engineer, then list three risks of changing it."
    A bug"Reproduce it with a failing test first. Don't fix anything until the test fails for the right reason."
    Refactor"Behaviour must not change. List every public signature you'll touch before editing."
    Review"Review as a strict senior engineer. Rank findings by severity; say 'none' if there are none."
    Long documentsPut the documents first and your question last. Anthropic measured up to 30% better answers this way on complex multi-document inputs, and Google gives the same advice.

    What changed with today's models (all three vendors' 2026 guides):

    5. In your five tools

    Two things you'll do daily: attach the right context, and save briefs you reuse. Checked October 2026.

    ToolAttach contextSave a reusable brief
    Claude Code@path/to/file or @folder/ in the prompt; or ask it to read filesProject rules in CLAUDE.md or AGENTS.md; repeatable tasks as skills you run with /skill-name
    Antigravity CLIMention paths in the prompt; /add-dir adds a folder to the workspaceRules in AGENTS.md or GEMINI.md; repeatable tasks as skills (/skills)
    GitHub Copilot (VS Code)#file, #codebase, #fetch in chatPrompt files in .github/prompts/*.prompt.md; instructions in .github/copilot-instructions.md
    Cursor@-mention files, folders, @Docs, @WebRules in .cursor/rules/ or AGENTS.md; saved commands in .cursor/commands/
    Codex CLIMention paths in the prompt; it reads the repoRules in AGENTS.md; repeatable tasks as skills

    Skills (Module 11) and project instructions (Module 09) are context engineering made permanent: the right brief, loaded at the right time, every time.

    6. Remember it

    Memory hook: "Brief it like a brilliant new hire"Assume skill, not context. Give the goal, the context, the constraints with reasons, an example, the format and what "done" means.
    How this hook works: what “Brief it like a brilliant new hire” means

    What the slogan means, phrase by phrase

    “Brief it”
    A prompt is a work brief, not a search query. Write it the way you'd hand a task to a person.
    “brilliant”
    Don't explain how to write a loop or shout to get attention. It's capable; tell it what you want and it will usually work out how.
    “new hire”
    It knows nothing about your codebase, your users, your conventions or what you tried yesterday. That context is your job to supply.

    Why this picture fits: everyone has onboarded a strong new colleague. You instinctively know what they need (the goal, the background, the rules and why, an example, and when to stop) and what they don't (lectures on basics). The same instincts write good prompts.

    The story → the concept

    Briefing a new hireIn the prompt
    "Here's what we need and why"Goal
    "The code is in billing/; customers are shops"Context: files, domain, users
    "Don't touch the API: three services depend on it"Constraints with reasons
    "Here's one we did last month"Examples
    "Send me a short PR with a summary"Output format
    "It's done when the tests pass and it handles refunds"Definition of done
    "Ask me if anything's unclear"Permission to ask questions first

    Watch it on an example

    Request: "add tests for the date parser".

    1. Treated as a search query, the model writes generic happy-path tests in whatever framework it guesses.
    2. Briefed like a new hire: goal "protect parseShipDate before we refactor it"; context "src/dates/parse.ts, Vitest, see parse-order.test.ts for style"; constraint "don't change the function: we only want tests now"; done "covers time zones, empty input, leap days, and all tests pass".
    3. The result: the right framework, the right style, the edge cases you care about, and no surprise edits.

    The trap it saves you from

    Writing prompts like search queries ("date parser tests") and then blaming the model for guessing. A new hire given four words would guess too.

    It still works when…

    You configure agents. AGENTS.md (Module 09) is the onboarding doc every new hire reads on day one; skills (Module 11) are the team's how-to guides, pulled out when a task needs them.

    7. Common mistakes

    No definition of doneWithout one, the model decides when it's finished, usually too early. State the check: tests, cases covered, files touched.
    Rules without reasons"Never use ellipses" is followed rigidly and narrowly; "the output is read aloud by a speech engine, so avoid ellipses" lets the model apply the idea sensibly.
    ShoutingALL-CAPS "CRITICAL" and "MUST" make current models over-apply a rule. Write normally; reserve emphasis for the one thing that truly matters.
    Several unrelated tasks in one promptThe model does all of them halfway. One task per request; chain them.
    Examples that are all the sameThe model copies quirks you didn't intend. Make examples varied, and cover an edge case.

    8. Hands-on lab (25 minutes)

    1. Pick your most common task (writing tests, a PR description, a migration).
    2. Before: ask for it in one short sentence in tool A. Save the result.
    3. After: write a six-part brief in the checker above, then run it in tool A in a fresh session. Compare the two results honestly.
    4. Cross-check: run the same brief in tool B. Did it transfer without changes?
    5. Save it as a reusable prompt or command in the tool you use most (see section 5), so next time it's one command away.

    9. Self-check quiz

    Which makes a constraint most likely to be followed sensibly?

    Current vendor guides agree: a reason lets the model generalise; shouting makes it over-apply.

    You're giving the model three long documents and a question. Best order?

    Both Anthropic and Google recommend long content at the top and the specific question at the end.

    The agent keeps stopping halfway. What's most likely missing from the brief?

    Without a stated finish line, the model decides it's finished. "Done when all tests pass" fixes it.

    How should you brief a reasoning model on a hard problem?

    OpenAI likens a reasoning model to a senior colleague: describe the outcome and the limits, not the method.

    10. Go deeper

    ResourceTimeWhy
    Prompting best practices (Anthropic)30 minThe most detailed current guide, including agentic and long-context prompting.
    Prompt engineering (OpenAI)20 minMessage roles, structure, examples, and prompting reasoning models.
    Prompt design strategies (Google)20 minFew-shot examples, context placement and Gemini-specific advice.
    Effective context engineering for AI agents (Anthropic)20 minFrom writing prompts to designing everything the model sees.
    Anthropic Academy prompt engineering course2–3 hFree, hands-on practice with exercises.