Home/ Part IV — AI Studio Deep Dive: Every Knob Matters Eventually/11. Context Management Like a Pro/11.1 What to include vs exclude from context

11.1 What to include vs exclude from context

Overview and links for this section of the guide.

On this page

The goal: enough signal, minimal noise

When you provide context, you are answering one question:

“What does the model need to know to do this task correctly, without guessing?”

Anything that doesn’t help answer that is noise—noise increases hallucination and drift.

High-signal context is specific

Specs, acceptance criteria, failing tests, and relevant code slices are high signal. Long chat history is usually low signal.

What to include (high signal)

Include the smallest set that makes correctness measurable:

  • Spec block: goal, constraints, acceptance criteria.
  • File tree: enough to orient the model.
  • Relevant code: only the files/functions involved in the change.
  • Interfaces: function signatures, schemas, or API routes.
  • Evidence: failing test output, stack traces, logs.
  • What changed recently: the last diff or the last decision if relevant.

For debugging specifically

  • exact repro command,
  • expected vs actual output,
  • full stderr/stdout,
  • minimal code slice around the failure,
  • versions (runtime + relevant libraries).

What to exclude (common noise)

Exclude things that bloat context without improving diagnosis:

  • Long conversation history: replace with a short summary block.
  • Unrelated files: don’t paste the whole repo “just in case.”
  • Huge logs: paste the relevant excerpt around the error.
  • Generated code: minified bundles, lockfiles, vendor blobs.
  • Sensitive data: secrets/PII; replace with placeholders.
More context can reduce quality

When you paste too much, the model may anchor on irrelevant details and miss the true signal. Start small and expand only if needed.

Ordering matters (how to pack context)

Order your prompt so the model sees constraints and success criteria before code:

  1. SPEC: goal + constraints + acceptance criteria.
  2. Process rules: plan-first, diff-only, file scope.
  3. Evidence: failing output/tests.
  4. Code: relevant files only.

This reduces “model starts coding before it understands the goal.”

Copy-paste context templates

Template: change request context pack

SPEC (authoritative)
Goal: [...]
Constraints: [...]
Acceptance criteria: [...]
END SPEC

Process:
- Plan first, then diff-only changes
- Only touch: [...]

Context:
- File tree: [...]

Relevant code:
File: [...]
```[lang]
...
```

Template: debugging context pack

SPEC (authoritative)
Goal: [...]
END SPEC

Reproduction:
Command:
```sh
...
```

Expected:
...

Actual output:
```text
...
```

Environment:
- OS: ...
- Runtime: ...

Relevant code:
File: ...
```[lang]
...
```

Where to go next