The manifesto explains what Extreme Contexting believes. This guide explains how to practice it.
The loop
Extreme Contexting turns AI work into a disciplined loop:
The central question is always: What is the minimum sufficient context required for the next verifiable move?
The move
Extreme Contexting does not begin with the prompt. It begins with the move. A move is the smallest useful step that creates an inspectable artifact.
A good move has: one intention, one primary output, a bounded context packet, a clear verification condition, and a reversible or reviewable result.
Bad move vs. better moves
| Type | Example |
|---|---|
| Bad move | Build the authentication system. |
| Move 1 | Summarize the current authentication flow. |
| Move 2 | Identify where permissions are enforced. |
| Move 3 | Write failing tests for the missing role behavior. |
| Move 4 | Implement the smallest change that passes the tests. |
| Move 5 | Refactor duplicated permission logic. |
| Move 6 | Update the auth notes with the new invariant. |
The goal is not to make the AI do less. The goal is to make each AI action clear enough to verify.
Three practitioner stances
Extreme Contexting does not require a large team. One person can practice it by moving through three stances.
| Stance | Core question |
|---|---|
| Designer | What is the next verifiable move? |
| Editor | What is the minimum sufficient context for that move? |
| Verifier | What proves the move worked? |
What matters is not organizational structure. What matters is that all three questions are asked before the output is trusted.
Sequence before context
Sufficiency is impossible without sequencing. Before deciding what context the AI needs, decide what move it is making.
Large projects should not be decomposed only by functional area (frontend, backend, database, tests, docs). They should be decomposed by uncertainty, risk, and verification:
- What do we not understand yet?
- What assumption needs proof?
- What behavior needs a test?
- What interface needs to stabilize?
- What change can be safely inspected?
- What decision must be preserved?
Not bad syntax. Asking the model to infer the sequence.
The Move Card
The Move Card is the primary operating artifact of Extreme Contexting. It turns vague AI delegation into a bounded unit of work.
The Move Card does not need to be long. It needs to be clear.
The Sufficiency Check
The Sufficiency Check produces the Context Packet. Before generating, ask:
- What is the job?
- What must the AI know?
- What must the AI not do?
- What examples define good output?
- What proves success?
- What context can be removed?
- What should be captured afterward?
Too little context creates guessing. Too much context creates drift. The goal is the narrow middle: enough context to make the next correct move, and no more.
Verification contracts
Every meaningful AI move needs a verification contract — a definition of what must be true before the output is accepted. The form matters less than the discipline.
AI output should not be accepted because it sounds plausible. It should be accepted because it passes a defined check.
Generation in bounded passes
A strong generation request contains: the move, the context, the exclusions, the expected output, and how the result will be verified. The final sentence matters most:
"Do only this move." — prevents the model from combining discovery, implementation, refactoring, and documentation into one uncontrolled pass.
Refactor the context
When output fails, inspect the context before asking again. Was the move too large? Was the intent ambiguous? Was the wrong file included? Were exclusions missing? Was verification undefined? Did the model have to infer a rule?
If the same correction is made twice, it belongs in durable context: add a gotcha, update the style guide, create a test, split an overloaded file, remove an obsolete example.
Capture durable context
A completed move should leave something behind: a new test, a clarified rule, a decision record, a gotcha, an updated brief, a validator rule, a reusable example.
The purpose of capture is compounding. Each good cycle should make the next cycle easier.
Decomposition pattern
For large projects, use this sequence:
- Name the outcome. What should be true when the work is done?
- Identify the seams. Where can the system be divided safely?
- Identify the risky unknowns. What could make the project fail?
- Convert unknowns into discovery moves. Before generating code, generate understanding.
- Convert behavior into verification contracts. Before implementation, define proof.
- Implement in vertical slices. Prefer thin, testable slices over broad horizontal layers.
- Refactor after behavior is locked. Do not ask AI to redesign while behavior is still ambiguous.
Anti-patterns
| Anti-pattern | Failure mode |
|---|---|
| Prompt stuffing | Assumes more context equals better output. |
| Mega-tasking | Asks the model to infer sequencing, scope, and verification. |
| Vibe acceptance | Accepts plausible output without proof. |
| Context accretion | Keeps adding instructions without pruning old ones. |
| Hidden chat dependency | Makes the work non-repeatable. |
| Spec theater | Produces long specs that do not guide the next move. |
| Premature refactoring | Lets structure change before behavior is verified. |
| Unbounded autonomy | Lets the model decide purpose, scope, and acceptance. |
The cure is usually the same: smaller move, sharper context, clearer verification, durable capture.