I watched Dex’s talk on context engineering at AI Engineer World’s Fair, and it gave a name to something I’ve been experiencing for months. You know that feeling when you’re five turns deep into a conversation with Claude, and suddenly it starts suggesting things that make no sense? Or when it confidently proposes changes to files it already edited correctly three messages ago?

I knew something was happening. I just didn’t have the vocabulary for it. Dex is pulling a Fowler here - observing patterns practitioners already use, giving them names, making them discussable.

The Slop Problem

Dex opened with an uncomfortable stat: surveys of 100,000+ developers show that most AI-assisted coding results in significant rework. You’re shipping more code, sure. But a lot of it is just cleaning up the slop from last week.

This matched my experience. Greenfield projects? AI tools are incredible. New utilities, fresh codebases - they sing.

But brownfield? The 10-year-old legacy monsters where real work happens? AI tools often feel like they’re fighting you more than helping. Too much context to understand, too many implicit conventions, too many ways to get it wrong.

The conventional wisdom has been “wait for better models.” Dex’s argument is different: the models are already good enough. We’re just using them wrong.

The Dog Ate My Homework

Here’s my hot take: blaming AI when your pull request leaves a lot to be desired is like saying the dog ate your homework.

The moment you mark that pull request as ready for review, you wrote it. However you got there, you’re on the hook.

This is the thing Dex keeps hammering: AI cannot replace thinking. It can only amplify the thinking you’ve done - or the lack of thinking you’ve done.

A bad line of code is a bad line of code. But a bad part of a plan? That’s a hundred bad lines of code waiting to happen. A misunderstanding in your research? Your whole approach is compromised before you even start.

The highest leverage isn’t in the execution phase. It’s in the research and planning. That’s where human attention actually matters.

Don’t outsource the thinking. Watch out for tools that just generate a bunch of markdown files to make you feel good. If you don’t read the plan, it won’t work. There is no perfect prompt. There is no silver bullet.

The Dumb Zone

So why do AI tools lead us astray in the first place? Here’s the concept that gave me vocabulary for what I’d been noticing.

Your context window has a capacity - roughly 168,000 tokens for Claude. But here’s the thing: the more you use it, the worse outcomes you get. Around the 40% mark, you start seeing diminishing returns. The quality degrades. The model starts making mistakes it wouldn’t make with a fresh context.

Dex calls this operating in “the dumb zone.”

If you have too many MCPs dumping JSON and UUIDs into your context, you’re doing all your work in the dumb zone. You’re never going to get good results because you’ve already burned your cognitive budget on noise before you even start the real work.

The Trajectory Trap

Here’s the trap Dex describes:

  1. Ask the AI for something
  2. It does something wrong
  3. Correct it
  4. It does something wrong again
  5. Correct it more forcefully
  6. Repeat until context is exhausted or you give up

The problem, as Dex explains it? LLMs are stateless. Every turn, the model looks at the entire conversation and predicts what comes next. If your conversation is a pattern of “I tried something → human corrected me → I tried something → human corrected me,” what’s the most likely next token?

Another mistake for the human to correct.

You’re literally training your context window to fail. The trajectory of the conversation influences the output. A conversation full of corrections primes the model for more corrections.

Intentional Compaction

The fix isn’t to yell louder. It’s to start over with better context.

My practice now: instead of multi-turn corrections, I go back and edit my initial prompt. One-shot the solution right instead of steering through the dumb zone.

This aligns with what Dex calls “intentional compaction.” Whether you’re on track or not, you can take your existing context window, ask the agent to compress it into a markdown file with the key learnings, and then start fresh. The new agent gets straight to work instead of having to redo all that searching and codebase understanding.

What takes up space in your context window? Dex’s breakdown:

  • Looking for files
  • Understanding code flow
  • Editing files
  • Test and build output
  • MCP tool responses full of JSON

A good compaction captures the essential information: “Here’s exactly what we’re working on, the exact files and line numbers that matter, and here’s the approach.” Everything else is noise you don’t need to carry forward.

Research, Plan, Implement

Dex’s team built a workflow around this compaction principle. Three phases, each one compressing the previous into something the next phase can execute reliably.

Research → Compress the codebase into understanding

Understand how the system actually works. Find the right files. Stay objective.

The key here is launching this as a subagent - a separate context window that goes and does all the reading, searching, and understanding. It returns a succinct summary: “The file you want is here. This is how the system works. These are the constraints.”

The parent agent never has to burn context on all that exploration. It just gets the compressed result.

Plan → Compress understanding into intent

Outline the exact steps. Include file names and line snippets. Be explicit about how you’re going to test after every change.

A good plan has actual code snippets of what’s going to change. When you read it, you should be able to see very easily how even a dumb model isn’t going to screw this up. The goal is high confidence that the model will do the right thing.

Implement → Compress intent into code

Execute the plan. Keep context low.

If you’ve done research and planning well, this phase is almost mechanical. The model is just following instructions, not figuring things out.

Each phase is a compression step. You’re taking something large (the codebase, the problem space, the approach) and distilling it into something small enough to fit in the smart zone with room to spare.

The Limits

This isn’t magic. There are limits.

Some problems are genuinely hard - the kind where you do the research, write the plan, and realize halfway through that you didn’t understand the problem deeply enough. Throw everything out. Back to the whiteboard.

Context engineering can’t save you from problems that require actual architectural thinking. It can’t replace the moment where you stare at a dependency graph and finally understand why the thing is coupled the way it is. It can’t skip the hard cognitive work of designing how pieces fit together.

What it can do is make sure you’re not wasting the AI’s capacity on noise. It can make sure that when you do understand the problem, the execution is clean. But understanding the problem? That’s still on you.

The Point

AI is a power tool. A really good one. But power tools don’t think for you - they amplify.

The slop problem isn’t the AI’s fault. It’s not the junior engineer’s fault for using Cursor. It’s a workflow problem. It’s a context engineering problem. And increasingly, it’s a cultural problem that needs to come from the top.

If you outsource the thinking, you’re going to ship slop and wonder why AI “doesn’t work.” If you put in the work upfront - understanding the problem, planning the approach, staying in the smart zone - you can get 2-3x throughput without the tech debt hangover.

The models will get better. But the accountability is already solved: it’s you.