Advanced Context Engineering for Coding Agents (ace-fca.md)

Dex Horthy (HumanLayer) · article · 2026-10-08 source ↗ Reader 🖥️

Agentic Loop Agile & XP Context Engineering Context Rot & Context Limits Multi-Agent Orchestration Organizational Legibility

Solving hard problems in brownfield codebases requires designing your entire workflow — not just individual prompts — around keeping the context window in a 40-60% utilization sweet spot via a research/plan/implement cycle of frequent, intentional compaction, with human review concentrated at the research and plan layers because errors there compound into far more downstream bad code than a single bad line; and the open problem now is scaling this disciplined, human-engaged practice collaboratively across whole teams, not just a single highly motivated practitioner.

practical · narrative — A first-person practitioner essay structured as a journey (naive chatbot use -> ad-hoc restarts -> intentional compaction -> frequent intentional compaction) with embedded case studies, building toward a product pitch (CodeLayer) for scaling the practice across teams.

Structure

Part	Role
Origin story: unsustainable 2000-line Go PR review load forces adoption of spec-driven development over 8 uncomfortable weeks	motivating narrative
Four explicit goals: works in brownfield, solves complex problems, no slop, maintains mental alignment	success criteria framework
Progression of context-management sophistication: naive chatbot -> discard-and-restart -> intentional compaction -> frequent intentional compaction	taxonomy building to the recommended practice
Why obsess over context: LLM turns are stateless function calls; context window quality has four dimensions (correctness, completeness, size, trajectory) and three ranked failure modes (incorrect > missing > noisy information)	theoretical grounding
Geoff Huntley's Ralph Wiggum while-loop as a contrasting, more autonomous alternative	comparison / contrast
Subagents as context control, not role anthropomorphization	mechanism clarification
The research/plan/implement cycle with named prompt files and the worktree-only-for-implementation rule	concrete practice
BAML case studies, the parquet-java/Hadoop failure, and a second failure (MCP sHTTP keepalive race condition, two team-weeks lost)	evidence, including disconfirming evidence
On Human Leverage: a bad line of research costs more than a bad line of plan costs more than a bad line of code	core prescriptive claim
Team-scaling evidence: intern ramp-up, team Opus spend, and the CodeLayer pitch for scaling the practice across teams	generalization claim and forward-looking framing

Key terms

frequent intentional compaction
Designing the entire workflow — not just individual prompts — around context management, keeping context utilization in the 40-60% range throughout, via a repeated research/plan/implement cycle rather than one large push or occasional ad-hoc restarts.
context window quality dimensions
Four things to optimize a context window for — correctness, completeness, size, and trajectory — with three ranked failure modes in order of severity: incorrect information (worst), missing information, and too much noise (least bad).
mental alignment
(citing Blake Smith) The primary purpose of code review: keeping team members synchronized on how and why the codebase is changing, not primarily correctness-checking.

Propositions

explicitThe essay frames success through four explicit, named goals — working in brownfield codebases, solving complex problems, avoiding slop, and maintaining team mental alignment — and structures its entire case-study narrative as checking off each one in turn.conf: high
explicitA context window should be optimized along four dimensions — correctness, completeness, size, and trajectory — and the three worst things that can happen to it, ranked by severity, are incorrect information, then missing information, then too much noise.conf: high
extendsNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p5 — The talk names a single 'smart zone' heuristic (~first 40% of context); the written essay generalizes this into a full four-dimension quality framework (correctness/completeness/size/trajectory) and a ranked failure-mode list, giving the heuristic sharper theoretical structure.
explicitcorroboratedFrequent intentional compaction means designing the entire workflow — not individual prompts — around context management and keeping utilization in the 40-60% range throughout, escalating from occasional ad-hoc restarts to a continuous practice.conf: high
extendsNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p2 — The talk reports the outcome (2-3x throughput after 8 weeks of workflow redesign); the essay names the specific practice that redesign converged on — 'frequent intentional compaction' at 40-60% utilization — and traces the taxonomy of less-sophisticated approaches it supersedes.
supports ←12-Factor Agents: Patterns of reliable LLM applications — Dex Horthy, HumanLayer · p10 — This talk's 'micro agents inside a mostly deterministic DAG' is the architectural precursor to the later essay's formalized 40-60% context-utilization, frequent-intentional-compaction workflow — same author, earlier and coarser-grained version of the same practice.
explicitSubagents in Claude Code are a feature for context control, not for simulating specialized human-like roles ('playing house and anthropomorphizing roles'); their job is to return a compacted result, not to embody a persona.conf: high
supportsNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p6 — Both make the identical claim (subagents are for context control, not role-play), the essay adding the vivid 'playing house and anthropomorphizing roles' framing explicitly absent from the talk's own wording.
explicitOf the three-phase cycle, only the implementation step needs to run in a git worktree; research and planning are done directly on the main branch.conf: high
explicitGeoff Huntley's 'Ralph Wiggum' technique (an agent run in an unattended while-loop against a fixed prompt file) is a contrasting, more autonomous approach to the same context-scarcity constraint that the author takes seriously rather than dismissing as a gimmick, even though frequent intentional compaction is a different, more human-engaged solution to the same '~170k effective context window' problem.conf: high
extendsWhat the Hell Is a Loop, Anyway? · p3 — Voss's taxonomy defines the task loop (Ralph loop) as a named architecture; this essay places frequent intentional compaction as a human-engaged alternative addressing the same context-scarcity constraint Ralph solves via full unattended autonomy, sharpening the contrast between the two task-loop philosophies.
explicitA second, previously unreported production failure — a race condition that spiraled into MCP streaming-HTTP keepalive issues in Go — cost the whole team two weeks with no resolution via this workflow, a second concrete limit case beyond the Hadoop/parquet-java failure.conf: high
explicitAn intern using this workflow shipped 2 PRs on their first day and 10 PRs by their eighth day, offered as evidence that the practice ramps up quickly for a team member who is not the method's inventor.conf: high
explicitA three-person team practicing this workflow spends roughly $12,000/month on Opus API usage, a concrete operating-cost figure for the practice at small-team scale.conf: high
explicitThe hardest learning from the Hadoop-removal failure was not primarily a methodology flaw but a precondition the team lacked: the workflow's research/plan/implement cycle still needs at least one person on the task who is an expert in the codebase, and in this case neither participant was.conf: high
extendsNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p13 — The talk asserts commoditization of agent capability leaves team/culture adaptation as the hard problem; the essay makes this concrete by naming the company's own product response (CodeLayer) and its target customer profile (10-25 person eng orgs), showing what 'driven top-down by technical leadership' looks like as an actual intervention.
explicitThe author explicitly names scaling frequent-intentional-compaction workflows collaboratively across large teams (not just for a single motivated practitioner) as the open problem the company is now building tools (CodeLayer) to solve, and is forward-deploying with 10-25 person engineering orgs specifically to help them make the required culture/process/tech shift.conf: high
explicitDeep human engagement during the process — reading and discarding a wrong research document, staying 'deeply engaged' for hours — is treated as a necessary, load-bearing input to the outcome, not an incidental detail; the search for a single prompt that removes the need for this engagement is explicitly rejected as a category error.conf: high
refinesNo Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p14 — The talk's leverage-hierarchy claim (bad research > bad plan > bad code) is largely an assertion; the essay adds the specific mechanism for why it holds in practice — the author's own documented act of reading and discarding a wrong research draft before any plan or code existed, catching the error at the cheapest possible point.
implicitThe intern-ramp and team-cost evidence, while suggestive that the practice transfers beyond its inventor, is still drawn entirely from the author's own small team and company — it does not constitute the independent, outcome-measured adoption outside HumanLayer's network that would be needed to show the method generalizes to less motivated or less skilled teams at large-org scale.conf: medium

Arguments

Teams should adopt frequent intentional compaction — redesigning their whole workflow around a 40-60% context-utilization band via research/plan/implement — rather than ad-hoc restarts or one-off intentional compaction.

Explicit premises:

Context window contents are the only lever on output quality once the model is fixed
Occasional/ad-hoc compaction still lets utilization drift into the degraded 'dumb zone' between resets
A continuous, workflow-wide discipline keeps utilization consistently in the productive band rather than only after things have already gone wrong

Implicit premises:

The marginal cost of maintaining this discipline continuously (more structure, more artifacts, more token spend) is justified by the quality gain for the kind of complex, brownfield tasks the essay is scoped to — a tradeoff the essay doesn't quantify for simpler tasks

Inferences:

If the discipline's main cost is process overhead rather than model capability, then the open problem genuinely is organizational (team adoption, tooling, culture) rather than technical — which is exactly the problem the author says the company is now building a product around

Narratives

On a 300k-LOC Rust codebase (BAML) the author had never worked in, a first research pass was thrown out as wrong; a redone research pass, paired with a plan built on it, beat a parallel no-research plan on the same bug — the research-grounded PR was approved by the codebase's own maintainer without him knowing it was a demo.
→ Demonstrates, as a controlled-ish comparison (same bug, two competing plans), that the research step specifically — not just planning in general — is what produces a fix that fits existing codebase conventions rather than merely 'working.'
A second, unresolved failure: two team-weeks spent on an MCP streaming-HTTP keepalive race condition that spiraled into dead ends, named as evidence the workflow does not work for every problem.
→ Prevents the essay's case studies from reading as uniformly successful; explicitly offered to pre-empt the 'hyped sales guy' framing.

Questions addressed

✅ What exactly should a context window be optimized for, beyond just 'staying under some size limit'?
Four dimensions (correctness, completeness, size, trajectory), with incorrect information identified as strictly worse than missing information, which is worse than noise.
⭕ Does this research/plan/implement discipline transfer to team members other than its inventor?
Partially addressed with internal evidence (an intern's fast ramp-up), but not with independent, outside-the-company adoption data.

Gaps

incompleteThe intern-ramp-up and team-cost figures are offered as generalization evidence but remain internal to the author's own small company and network — the same limitation the corpus has already flagged for the companion talk (personal anecdotes from a founder's own team, no independent outcome measurement). A genuinely independent test of whether this transfers to a less-motivated or larger, less cohesive team at org scale is still missing.
Read next: Look for independent case studies or post-mortems of research/plan/implement-style workflows adopted by teams with no connection to HumanLayer, ideally including teams that abandoned the practice, to test generalization beyond a founder-led, highly bought-in team.
incompleteThe Ralph Wiggum while-loop is presented as a contrasting technique the author takes seriously, but the essay never states why he chose frequent intentional compaction over it for his own team — e.g. whether it's about task type (brownfield vs. greenfield), risk tolerance, or team review bandwidth. The two approaches sit side by side without a stated decision rule for choosing between them.
Read next: Read extract-voss-what-the-hell-is-a-loop and extract-11-tips-ai-coding-with-ralph-wiggum for the task-loop (Ralph) discipline-progression model, and compare its stated preconditions (small, well-scoped, externally-verifiable tasks) against this essay's research/plan/implement preconditions (complex, brownfield, requiring human judgment) to build the missing decision rule.