Solving Hard Problems in Complex Codebases

Most of the time teams use AI for software engineering, they end up doing a lot of rework. Codebase churn goes up. Complex tasks and brownfield systems—ten-year-old Java codebases, large existing architectures—remain stubbornly difficult. Greenfield work, such as a small dashboard, often goes smoothly. Everything else tends to produce slop that has to be cleaned up the following week.

The question is not whether models will eventually get better. The practical question is how to get the most out of the models we have today by managing the context window carefully.

That is what advanced context engineering is about.

Context Is the Core Problem

Coding agents work from the context available to them. When that context becomes incorrect, incomplete, or noisy, the agent can move in the wrong direction.

Dex describes a “smart zone” and a “dumb zone”, explaining that excessive context can lead to diminishing returns. His approach is to keep the context focused through intentional compaction and careful context management.

Research, Plan, Implement

The workflow presented in the talk has three phases:

Research → Plan → Implement

Research finds how the system works and identifies the relevant files. Planning turns that understanding into explicit steps, including file names, code snippets, and testing steps. Implementation then follows the plan while keeping context low.

This process was tested on difficult real-world codebases. Dex describes a 300,000-line Rust codebase where research and planning helped produce a change that was accepted for the next release. He also describes shipping around 35,000 lines of code to BAML in seven hours, while noting that some of the output was generated code.

Compress Truth and Intent

Instead of giving an agent an entire large repository, context can be progressively disclosed. Root-level context can be combined with more specific information only when needed.

Dex calls the creation of task-relevant research from the actual codebase “compressing truth.” Planning then becomes “compression of intent.”

Subagents can support this by exploring separate context windows and returning only the important findings to the main agent. Their purpose is primarily context control, not simply dividing agents into artificial roles.

Keep Humans in the Loop

The talk strongly emphasizes:

“Do not outsource the thinking.”

A bad line of code creates one problem. A bad plan can create many bad lines of code, while incorrect research can send the entire implementation in the wrong direction.

Plans also help teams maintain mental alignment by making the intended changes and reasoning easier to review.

Not every task needs the full process. A small UI change may only need a direct instruction, while larger features across multiple repositories may benefit from research and planning. The harder the problem, the more context engineering may be required.

The Main Takeaway

There is no perfect prompt or silver bullet.

The important work is context engineering: understanding the codebase, compressing useful information, planning changes clearly, keeping context focused, and maintaining human judgment throughout the process.

AI can amplify engineering thinking, but it does not replace it.