Dex Horthy explains how to use context engineering to make AI coding tools actually productive in large, established codebases.
It seems pretty well-accepted that AI coding tools struggle with real production codebases. At AI Engineer 2025 in June, The Stanford study on AI's impact on developer productivity found:
A lot of the ""extra code"" shipped by AI tools ends up just reworking the slop that was shipped last week.
Coding agents are great for new projects or small changes, but in large established codebases, they can often make developers less productive.
The common response is somewhere between the pessimist ""this will never work"" and the more measured ""maybe someday when there are smarter models.""
After several months of tinkering, we've found that you can get really far with today's models if you embrace core context engineering principles.
This isn't another ""10x your productivity"" pitch. I tend to be pretty measured when it comes to interfacing with the ai hype machine. But we've stumbled into workflows that leave me with considerable optimism for what's possible. We've gotten claude code to handle 300k LOC Rust codebases, ship a week's worth of work in a day, and maintain code quality that passes expert review. We use a family of techniques I call ""frequent intentional compaction"" - deliberately structuring how you feed context to the AI throughout the development process.
In this talk, I'll share what we've learned since first sharing these techniques back in August, and some educated predictions on what's coming in the next 6-12 months for software engineers.
Speaker: twitter.com/dexhorthy
Timestamps:
intro: complex code
context engineering
advanced context
context obsession
dumb zone concept
context management
complex problem solved
semantic diffusion
onboarding agents
internal docs lies
mental alignment key
code snippet plans
don't outsource think
rpi: smart zone
cultural change hard
Hey - I'm Dex, and I'm hacking on getting AI coding agents to solve hard problems in complex codebases at HumanLayer. Before this I was working on APIs for agent orchestration and Human-in-the-Loop, and wrote the April 2025 essay "12 factor agents" that first coined the term Context Engineering. I've been coding since high school, when I built tools for NASA researchers to navigate the south pole of the moon. Enjoyer of tacos and burpees (not necessarily in that order).
---
Watch along with the corrected transcript, summary, timestamps and resources on this talk's official AIE page:
ai.engineer/talks/rmvDxxNubIg-context-engineering-for-comple…
Join our upcoming AI Engineer conferences (see ai.engineer landing page):
- AIEi Shanghai, November 5–6 — the first for meeting top Chinese labs and engineers
- AIE CODE in SF, November 10–12 — the top AI Coding conference returns
- AIEi Sydney, December 7–8 — the first AIEi run alongside NeurIPS 2026 in Sydney
---
Why it's here
3 people recommend this
What people say. Recommended for practical strategies on verifying and integrating AI-generated code in production environments.
Moments people linked to
m
u/martiantheoryin r/ExperiencedDevs • Recommends
On “What tools and techniques are you using to verify AI-generated code before it hits production? I tried using mathematical proofs, which helped to some extent, but the actual bugs were outside, and between, the verified code.”
Ah, that makes sense. It’s a bit of a wild time in the industry transitioning from the way things used to be, to this mandate to integrate with our robot overlords lol.
Apologies if I came off pedantic asking about your background. Now that I understand what’s going on, your post makes total sense.
I’ve been trying to figure out the best way to QA AI projects myself. Even though I was already doing a lot of what this guy says, I think he organized and presented it in a way that’s really helpful. I don’t know if this video addresses your problem, but it might point you in a good direction.
link to this video
Best of luck with everything 🫡👨💻
On “Vibe Coders Passing Responsibility to Code Reviewers”
I am in no way diminishing OP’s concern.
What has worked for absolute proof that the developer followed research, plan and implement strategy. Second thing is without quality PR, Screenshots and screen recoding it will not be approved.
Leadership was onboard with that checks and were ok in increased rejected PRs.
Future is this, embrace it and adapt. Start with low impact projects and trial it. It has worked for us.
Check this video from DEX Horthy
On “Vibe Coders Passing Responsibility to Code Reviewers”
I am in no way diminishing OP’s concern.
What has worked for us is an absolute proof that the developer followed research, plan and implement strategy. No research -> reject, no plan docs -> reject.
Second thing is without quality PR, Screenshots and screen recoding it will not be approved.
Leadership was onboard with that checks and were ok in increased rejected PRs.
Future is this, embrace it and adapt. Start with low impact projects and trial it. It has worked for us.
Check this video from DEX Horthy
