Coding agents can work in large, established codebases when developers manage the context window deliberately.
2
Research, planning, and implementation keep agents in the smart zone, while human review catches wrong assumptions before they become large code changes.
3
The hard problem will shift from using coding agents to changing team workflows for a world where most code is generated by AI.
Summary
Dex Horthy argues that coding agents struggle with established codebases because their context becomes noisy, incomplete, or pointed in the wrong direction. His answer is frequent intentional compaction: keep the agent's working context small, compress research into useful files, and restart or fork contexts before performance drops. His workflow has research, planning, and implementation phases. Research finds the relevant parts of the system, planning records exact files, line snippets, code changes, and tests, and implementation follows that plan. Horthy says this approach helped his team work on a 300,000-line Rust codebase and ship 35,000 lines in seven hours on BAML, although another attempt to remove Hadoop dependencies from Parquet Java required returning to a whiteboard. Humans still need to understand the research and plans. Horthy expects coding-agent capabilities to become common, leaving teams to change review, collaboration, and software development processes.
Context engineering can make current coding agents useful in brownfield codebases
Horthy starts from the finding that AI-assisted development creates substantial rework in complex, established codebases. Greenfield projects and small changes work better, while a 10-year-old Java codebase can become a source of slop and technical debt. His team found that managing context let them get two to three times more throughput from Claude Code. That increase forced a three-person team to change how it collaborated over eight weeks. The goal is to solve complex problems without shipping slop, preserve the team's shared understanding, and offload useful work to the model.
The model's next action depends on the conversation it has been given
Horthy describes the naive loop as asking an agent to make a change, correcting it when it goes wrong, and repeating until the context fills up. Starting a fresh context is better when a conversation has gone off track. Intentional compaction goes further: the agent compresses its current work into a Markdown file, a human reviews or edits it, and a new agent starts from that summary. Useful compacted information includes the exact files and line numbers that matter, rather than every search result, edit, test output, or noisy MCP payload. Horthy says context should be optimized for correctness, completeness, size, and trajectory.
The dumb zone begins when a context window becomes too full
Horthy uses the term dumb zone for the part of a context window where results start to get worse. Using Claude Code as an example, he says the context window is roughly 168,000 tokens, with space reserved for output and compaction, and that diminishing returns can begin around 40 percent depending on the task. Too many MCPs can consume the useful space before the agent has done meaningful work. Subagents help when they control context: a separate context can search a large codebase, read files, and return a short answer to the parent agent. They are not mainly a way to assign human-like roles such as frontend or backend.
Frequent intentional compaction divides work into research, planning, and implementation
The workflow Horthy calls frequent intentional compaction keeps the agent's context small throughout the task. Research determines how the system works and identifies the relevant files. Planning turns that research and the task description into exact steps, with file names, line snippets, and explicit tests after each change. Implementation then executes the plan. Horthy says a detailed plan can make it difficult even for a weak model to make a mistake. The process also creates checkpoints where a person can inspect the system understanding and intended changes before code is written.
The workflow can handle substantial changes, although it has limits
Horthy describes using this method on a 300,000-line Rust codebase for a programming language. After comparing research and plans, the resulting pull request was accepted for a coming release. He also says he and a colleague spent seven hours shipping 35,000 lines of code to BAML, with one pull request merged about a week later. Some of that work was code generation, such as updating behavior and regenerating golden files. A separate attempt to remove Hadoop dependencies from Parquet Java failed. After finding the footguns, they discarded the plans and returned to a whiteboard to work out the design.
Compressed context should come from code rather than stale internal documentation
Agents need onboarding or they will fill gaps with guesses. Horthy describes repository context files that explain how a codebase works, then progressively disclosed context at deeper levels of a large monorepo. A single document for a five-million-line repository can consume the smart part of the context window before useful tool calls begin. Documentation also becomes outdated as features change. Horthy prefers on-demand compressed context: steer research toward the relevant area, have subagents trace vertical slices through the code, and build a snapshot based on what the code currently does. This compresses truth instead of relying on documentation that may contain lies.
Plans preserve mental alignment across an increasingly fast team
For Horthy, code review is mainly about keeping the team aligned on how and why the codebase is changing. Technical leaders may not be able to read every generated line, but they can review research and plans, catch problems early, and maintain an understanding of system evolution. He describes pull requests that include the agent's prompts, exact steps, and build results, rather than only a wall of green text. His team has made plans more concrete by adding code snippets for the changes that should happen. Longer plans tend to be more reliable but harder to read, so each team needs to find a useful length.
Humans still have to think through the plan before the agent executes it
Horthy rejects the idea that agents remove the need for engineering judgment. AI can amplify the thinking that has already happened, or amplify the lack of it. A wrong line of research can send the whole task in the wrong direction. A bad plan can produce many bad lines of code. The right amount of process depends on the task: a button color may need only a direct instruction, a medium feature across repositories may need research and a plan, and a harder problem may need more compaction and review. There is no perfect prompt or silver bullet, and learning the right level takes repeated practice.
Teams must change their software process as AI writes more code
Horthy expects coding-agent capabilities to become commoditized as teams learn these techniques. He thinks the harder problem will be adapting team workflows and the software development life cycle to a setting where 99 percent of code is generated by AI. He describes a growing split: staff engineers may not adopt tools because they are not much faster, while junior and mid-level engineers use them to fill skill gaps and may create more slop. Senior engineers then spend more time cleaning it up. Horthy says this cultural change has to come from technical leadership. His advice is to choose one tool and get repeated practice with it.
"AI cannot replace thinking. It can only amplify the thinking you have done or the lack of thinking you have done."10:03
Who should watch
You work on a large, mature codebase and coding agents keep producing rework or technical debt.
You lead engineers who need a way to review AI-assisted changes without reading every generated line.
You are experimenting with research, planning, and implementation workflows and want guidance on how much process a task needs.
