Anthropic surveyed 100,000 developers across company sizes and found something uncomfortable: most of the time, when you use AI for software engineering, you're just creating rework.
You ship more code, but a lot of it is just refactoring the slop you shipped last week. AI works great for greenfield projects — building a new dashboard from scratch — but falls apart when you touch a 10-year-old Java codebase.
This is the dirty secret of AI coding that nobody wants to talk about. It's creating a tech debt factory.
But here's the thing: the models are getting better. The real problem isn't the AI — it's how we're using it. Specifically, how we're managing context.
This is what Dexter calls "context engineering." And it might be the most important skill in software development right now.
LLMs are stateless. The only way to get better performance out of them is to put better tokens in. Every time the model picks its next action, it's choosing between hundreds of right steps and hundreds of wrong steps. The only thing influencing that choice is what's in your conversation so far.
Here's the problem: as your conversation gets longer, you enter what's called the "dumb zone."
Around 40% of your context window, you start seeing diminishing returns. If you're working in the dumb zone, you're never going to get good results. The model gets confused, loses track of what matters, and starts making decisions based on noise.
Most people discover this the hard way: you ask the AI to do something, it gets something wrong, you correct it, it gets something else wrong, you correct that again, and eventually you either run out of context or give up.
The solution isn't a better prompt. It's better context management.
The naive approach is to just keep the conversation going until it breaks. But you can be smarter about this.
Dexter's team discovered they could get 2-3x more throughput by constantly compacting their context. Here's how it works:
Intentional Compaction: Take your existing context window and ask the agent to compress it down into a markdown file. Review it, tag it, and when a new agent starts, it gets straight to work instead of having to do all that searching and codebase understanding.
What takes up space in your context?
When you compact, you're creating a compressed version of the context that matters — the exact files and line numbers relevant to your problem.
Then you start fresh. The new agent reads the compressed context and gets straight to work, staying in the smart zone.
People love the idea of sub-agents: a frontend agent, a backend agent, a QA agent, a data scientist agent. But here's the thing: sub-agents aren't for anthropomorphizing roles. They're for controlling context.
Here's how they actually work: when you need to understand how something works in a large codebase, you can fork out a sub-agent to do the heavy lifting. That sub-agent opens a new context window, reads all the files, searches around, understands the system, and returns a succinct message back to the parent agent: "The file you want is here."
The parent agent reads that one file and gets straight to work.
If you wield sub-agents correctly, you can manage your context really well. You're not burning your main conversation on exploring and understanding — you're offloading that to sub-contexts.
This is where it all comes together. The workflow that actually works:
The research phase is all about understanding the codebase objectively. Finding the right files. Staying neutral.
The output of research should be compressed truth — a snapshot of the actual parts of the codebase that matter to your problem.
If you're working on a feature that involves SCM providers and Jira, you might give the agent some steering: "We're working in this part of the codebase." Then launch sub-agents to take vertical slices through the codebase and build a research document.
Planning is about compression of intent. You take your research, your PRD or bug ticket, and create a plan.
A good plan includes:
The goal is leverage. You want high confidence that the model will actually do the right thing. You want to be able to read a plan and know exactly what code changes are going to happen.
As plans get longer, reliability goes up but readability goes down. There's a sweet spot for your team and codebase. Find it.
If you have a good plan, implementation should be straightforward. The model executes the plan step by step, and you keep the context low throughout the whole process.
Here's something nobody talks about: code review isn't just about catching bugs. It's about mental alignment — keeping everyone on the team on the same page about how the codebase is changing and why.
When you're shipping 2-3x more code, you can't read all of it. But you can read the plans. You can maintain understanding of how the system is evolving.
A plan file is more valuable than a wall of green text in GitHub. It shows:
This takes the reviewer on a journey that a raw PR can't. It's how you maintain mental alignment when you're shipping massive amounts of code.
There are two approaches to giving agents context about your codebase:
Put onboarding information into every repo. "Here's the repo. Here's how it works." This is a compression of all the context in the codebase.
The problem: as your codebase gets big, this gets too long. You either make it longer (burning your smart zone) or leave information out (making it incomplete).
Plus, it gets out of date. Every time you ship a feature, you need to rebuild this documentation.
Split your context across the stack. Put a file in the root of every repo, and then at every level, have additional context based on what you're working on.
The problem: still gets out of date, and maintaining it is a pain.
This is what works best. When you start working on a feature, launch research sub-agents to take vertical slices through the relevant parts of the codebase and build a research document that's a snapshot of the actual code.
You're compressing truth, not maintaining static documentation. The research document is accurate because it's based on the actual code as it exists right now.
Here's the most important lesson: AI cannot replace thinking. It can only amplify the thinking you've done — or the lack of thinking you've done.
People treat coding agents like magic. They want the perfect prompt that makes the AI do everything. But there's no perfect prompt.
The human in the loop is critical. When you create a plan, you're reviewing it. When you implement, you're steering. When you get results, you're validating.
If you outsource your thinking, you get slop. A bad line of code is a bad line of code. But a bad part of a plan could mean hundreds of bad lines of code. A misunderstanding of how the system works in your research could send the model off in the completely wrong direction.
The whole process is designed to move human effort to the highest-leverage parts of the pipeline: reviewing research, validating plans, catching problems early.
Here's the real crisis coming: a rift is growing between engineers who adopt AI and those who don't.
This is not AI's fault. It's not the junior engineers' fault. It's a cultural change problem.
And cultural change is hard — it needs to come from the top.
If you're a technical leader:
Let's talk about the business implications.
The hardest problem you can solve, the ceiling goes up the more context engineering and compaction you're willing to do.
Simple features? Just talk to the agent. Medium features across multiple repos? Do one research, then build a plan. Complex brownfield codebase problems? Full research-plan-implement workflow with intentional compaction.
AI doesn't eliminate technical debt. It can compound it if you're not careful. You can ship slop faster than ever before, and if you're not managing your context well, that's exactly what will happen.
The teams that win will be the ones that figure out how to maintain quality while shipping faster.
The skills that matter are changing:
Your team needs to adapt. The engineers who thrive will be the ones who can think at a higher level of abstraction.
The coding agent tools (Cursor, Claude Code, etc.) will become commoditized. Everyone will have access to them. The competitive advantage will be in how you use them — your workflows, your context management, your team integration.
The companies that figure this out first will have a massive advantage. They'll be shipping 10x more code without increasing team size.
But the companies that don't figure it out will get buried under mountains of slop and technical debt.
If you're running a team that builds software:
Don't try every coding agent out there. Pick one and learn it deeply. You'll get context engineering wrong at first. That's okay. You need the reps.
Design your workflow around staying in the smart zone. Make intentional compaction part of your process, not an afterthought.
Don't use humans to catch slop at the end. Use them to validate plans upstream. A bad plan caught early saves hundreds of lines of bad code.
Create workflows that keep your team aligned as you ship more code. Plan files, research reviews, peer review of approaches before implementation.
AI is a force multiplier, not a replacement for thinking. The human in the loop is still the most critical component.
Context engineering is the missing piece of the AI coding puzzle. The models are good enough now — the problem is how we're using them.
When you manage your context well, you can get 2-3x more throughput. You can ship massive amounts of code without drowning in slop. You can solve complex problems in brownfield codebases.
But it requires a fundamental shift in how you think about software development. Less about writing code, more about directing AI to write code effectively.
The teams that figure this out first will win. The ones that don't will get buried.
Want to build an AI-powered development workflow that actually works? That's what we do at Medianeth. We help teams figure out how to use AI not as a toy, but as a force multiplier for real business impact. Let's talk about what you're building.
Founder & Lead Developer
With 8+ years building software from the Philippines, Jomar has served 50+ US, Australian, and UK clients. He specializes in construction SaaS, enterprise automation, and helping Western companies build high-performing Philippine development teams.
Ready to make your online presence shine? I'd love to chat about your project and how we can bring your ideas to life.
Free Consultation