The three levers
Better prompts are just one of three levers, what the model can see and what happens after its reply often matter more.
Three levers for better results
When an AI agent gives you a bad result, people usually blame the model. In practice, the model is rarely the bottleneck. There are three distinct levers that shape what the agent produces, and only one of them is what you wrote in your message.
The first lever is what you say: the phrasing, examples, and constraints in your request. This is prompt engineering, the most visible but often the least powerful of the three.
The second lever is what the model sees: which files, documents, and memory are loaded into the context when your request is processed. Even a perfectly phrased prompt produces a mediocre result if the model is working without the relevant information.
The third lever is what happens around each response: the tools available, the verification steps built into the loop, whether subagents run independent checks, whether the agent retries on failure. This is loop engineering, shaping the agent's behaviour at the system level rather than the prompt level.
All three levers interact. A sharp prompt with the wrong files in context still fails. The right files with a loop that never verifies its own output produces confident mistakes. Getting good results consistently means thinking about all three.
| Lever | What it means | Example move |
|---|---|---|
| Prompt engineering | Changing how you phrase the request, adding examples, specifying format, stating constraints | Replace "fix this bug" with "fix the null-check bug in parseUser(); the function should return null, not throw, when the input is undefined" |
| Context engineering | Controlling which files, docs, and memory files are loaded when the model processes your request | Before asking for a refactor, open the relevant module and its tests so the model sees the actual code, not a stale cached version |
| Loop engineering | Shaping what happens around each response: tools available, verification steps, hooks, subagents, retry logic | Add a PostToolUse hook that runs the test suite after every file write, so the agent sees immediately whether its edit broke anything |
One task, "fix a failing test", improved three ways. Each step names what changed and why the output got better.
Step 1: Sharper prompt
Original request: "fix the failing test." Result: Claude guesses which test, reads a generic file, suggests a change that does not address the root cause. Improved: "The test parseUser_returns_null_on_missing_email in src/auth/parseUser.test.ts is failing with TypeError: Cannot read property 'email' of undefined. Fix the parseUser function so it returns null instead of throwing when input is undefined." What changed: the prompt named the exact test, the exact error, and the exact expected behaviour. What improved: Claude went directly to the right file with the right goal, no guessing.
Step 2: Right files in context
Even with a sharper prompt, Claude can still work from stale or incomplete information if the relevant files are not open. Before the request, open src/auth/parseUser.ts and src/auth/parseUser.test.ts so they are in the active context. What changed: the model now sees the actual current implementation alongside the actual failing test, not inferred versions reconstructed from memory or a previous read. What improved: the suggested fix targets the real code, not a guess about what the code might say.
Step 3: A loop that runs the test
A sharp prompt and the right files get Claude to a plausible fix, but plausible is not the same as correct. Add a PostToolUse hook (or instruct Claude explicitly) to run the failing test suite after every edit. What changed: the agent loop now includes a verification step. After writing the fix, Claude runs the test, reads the result, and either confirms success or continues iterating. What improved: the loop catches the cases where the first fix was wrong, before you ever see the output. The agent does not stop at a plausible answer; it stops at a verified one.
Question 1 of 5
What is the difference between prompt engineering and context engineering?