§ 01 — The Frame: Context Tokens Are a Finite Resource
Treating context tokens like free real estate is the root cause of most agentic pipeline quality failures. The previous article in this series explained the physics: attention is zero-sum, signal degrades with volume, hallucination risk scales with context size. This article skips the theory and goes directly to practice.
What follows are opinionated, battle-tested token budgets for six SDLC agent tasks. These are not theoretical minimums — they are working targets based on what produces reliable output. They will feel constraining at first. That constraint is the point. Disciplined context scoping is the difference between an AI pipeline that works and one that produces outputs that require extensive human correction.
Each recipe includes: the total token target, per-component allocations, what to include, what to exclude, and what failure mode to expect when the budget is exceeded.
“A budget forces prioritization. Prioritization forces clarity. The moment you ask ‘what does this agent actually need to complete this task?’ is the moment the task gets better-defined — and the output gets better too.”
§ 02 — The Recipes: Six Tasks, Six Budgets
Task 1: Focused Code Generation
Single function or module implementation. The agent has a specific task, a specific file to write or modify, and specific interfaces to respect.
Task 01 — Focused Code Generation Target: 4,200 tokens
System prompt + role definition600Role, output format, uncertainty protocol
Hard constraints (SLAs, limits)400Non-negotiables for this module only
Target file (to be modified)800Full file if <800t; relevant section only if larger
Direct interface dependencies600Type signatures of imports only — not full files
Decision registry (module-scoped)500Decisions relevant to this module specifically
Test examples (if pattern exists)500One existing test as style reference only
Task specification300Clear, scoped request
Total4,200 tokens
What to exclude: Other modules, full codebase, design docs not directly governing this change, git history, test suites beyond the style example.
Failure mode when exceeded: Agent generates code that compiles but ignores constraints and drifts toward generic patterns it has seen in training data.
Task 2: PR / Code Review
Reviewing a pull request for correctness, constraint compliance, and architectural alignment.
Task 02 — Code Review Target: 5,800 tokens
System prompt + review framework700Review criteria, output format, severity levels
The diff1,200Only changed lines + minimal context
Originating ticket / requirement600What this change was supposed to do
Decision registry (touched modules)800Constraints for every module the diff touches
Architectural boundary rules500Which modules may call which
Incident history (if applicable)400Prior incidents in modules being modified
Review request200Specific areas of concern to prioritize
Total5,800 tokens (complex PRs: up to 8,000)
What to exclude: Unchanged files, full module source (inject type signatures instead), entire test suites.
Failure mode when exceeded: Review comments address style and obvious bugs while missing constraint violations — the worst outcome because it provides false assurance.
Task 3: Test Generation
Generating test cases for an existing or newly written function or module.
Task 03 — Test Generation Target: 4,500 tokens
System prompt + test framework rules600Framework, naming, structure conventions
Function/module under test1,000Full source of what is being tested
Acceptance criteria (if from story)600The spec the implementation is supposed to satisfy
Interface dependencies500Mocked interfaces — type signatures only
One existing test as style reference400Team’s test style — not entire test suite
Known edge cases / constraints300Module-specific edge case annotations
Task specification200What to test; any required coverage criteria
Total4,500 tokens
What to exclude: The entire test suite, implementation details of dependencies (mock them), design docs beyond the acceptance criteria.
Failure mode when exceeded: Tests written against average behavior rather than specified acceptance criteria. Green suite, wrong spec.
Task 4: Architecture Q&A
Asking the agent to reason about architectural decisions, evaluate options, or explain a system’s design.
Task 04 — Architecture Q&A Target: 6,500 tokens
System prompt + reasoning protocol600Ask for explicit tradeoff analysis; surface assumptions
ARCHITECTURE.md (relevant sections)1,200Only sections relevant to the question scope
Non-functional requirements700SLAs, scale targets, compliance constraints
Decision registry (relevant scope)800Prior decisions in the area being discussed
Relevant component interfaces600Type signatures of components under discussion
Constraints from external systems400Vendor SLAs, compliance rules, external contracts
Specific question300Well-scoped architectural question
Total6,500 tokens
Failure mode when exceeded: Agent produces comprehensive-sounding architecture that is actually generic advice from pretraining, dressed in your system’s naming conventions.
Task 5: Dependency Analysis
Evaluating dependency upgrade safety, compatibility, or identifying transitive dependency risks.
Task 05 — Dependency Analysis Target: 3,800 tokens
System prompt400Analysis criteria, output format
Current dependency manifest800package.json / requirements.txt / go.mod (full)
Pinned version constraints + rationale600Why specific versions are locked — critical
Relevant usage patterns700How the dependency is used (import patterns, key APIs)
Known incompatibilities400Prior breakages or known conflict patterns
Analysis request200Specific dependency or upgrade being evaluated
Total3,800 tokens
Failure mode when exceeded: Agent recommends upgrades based on current ecosystem patterns without respecting your specific pinning rationale — the one you injected is buried and under-weighted.
Task 6: Incident Triage
Using an agent to assist with live incident diagnosis: tracing failures, suggesting causes, recommending mitigations.
Task 06 — Incident Triage Target: 7,000 tokens (urgency: compress aggressively)
System prompt + triage protocol500Triage framework: isolate, hypothesize, recommend
Error output / stack trace800Compressed: key frames only, not full verbose trace
Relevant source (suspected area)1,200The module where failure appears to originate
Recent changes (last 48h)600Compressed git diff of recent changes in area
Incident history for module600Prior incidents — high signal for pattern matching
Config / environment snapshot500Relevant config values at time of incident
Observable symptoms600Metrics, logs, alerts that define the incident
Triage request200What you’ve already ruled out
Total7,000 tokens
Failure mode when exceeded: Agent focuses on the most recent and visible symptoms, misses the underlying constraint violation that is the actual cause. Incident drags on.
§ 03 — The Meta-Rule: When to Break the Budget
These budgets are targets, not laws. There are legitimate reasons to exceed them — and specific failure modes that should make you contract, not expand.
| Scenario | Budget Response | Rationale |
|---|---|---|
| Cross-module refactor touching 5+ files | Expand to 12,000 — but split into per-module sessions | Better to run 5 focused sessions than one unfocused large one |
| New feature with no prior context | Maintain budget; write AGENTS.md section first | Create the context rather than substitute volume for structure |
| ”The model keeps missing the constraint” | Contract — move constraint to position [2] in context | Budget isn’t the problem; position is |
| Complex architecture question | Expand to 10,000 — but scope the question tightly | Question scope, not context volume, determines quality |
| Urgent incident under pressure | Maintain 7,000 budget; compress aggressively | Large contexts under pressure produce confident wrong answers |
The compression test: Before adding any component to your context, ask: “If I had to cut 20% of the context, would this survive?” If the answer is no, it’s essential. If the answer is “probably,” it’s a candidate for removal. Running this test before every session is the fastest way to build context discipline as a team habit.
∎
6
Common SDLC agent task types
Quick Reference: Targets
- Code generation: 4,200
- Code review: 5,800
- Test generation: 4,500
- Architecture Q&A: 6,500
- Dependency analysis: 3,800
- Incident triage: 7,000
Universal Budget Rules
- System prompt: ≤ 700 tokens
- Hard constraints: always position [2]
- Task request: always last
- Full files: only if under 1,000 tokens; otherwise inject relevant sections
- Type signatures over full implementations
The Compression Test
“If I had to cut 20% of this context, what survives?” If a component can’t answer yes — it shouldn’t be in the context at all.
Most Common Bloat Sources
- Full test suite files (use style examples only)
- Complete module sources (use type signatures)
- Git log beyond last 48 hours
- Design docs not directly governing the task
- Verbose stack traces (compress to key frames)