Dex Horthy

Their words

And so if I say, "Hey, make this change." and the agent makes the change and then it runs the test and then they're broken and then it fixes the test. I have very high confidence the next change I asked it to make, it's going to follow that path again

Their words

there's four things in your context window that matter. There's like the size of it, how many tokens? There's like the quality of the information is like is there any incorrect information? Like if the model had some thinking trace where it decided the wrong thing was true. Is there missing information? Does this like have context missing that it should have? And then there's the trajectory.

Their words

But if you don't have good LLM intuition, like 100K for smaller models, 200K for these like really beefy like Codeex and Opus 4.8 models is usually a good like training wheel guideline of like if you pass there, your quality of results may be degrading.

Their words

How do we control that in such a way that we get the best results possible which means doing as much work as possible in the smart zone the you know first 100,000 tokens of the context window.

Their words

I do the research I do the plan I do the implementation I throw the docs out and the next time I need research I just do it from scratch because tokens are cheap and my time is expensive

Their words

I don't think anyone found it useful enough to like maintain a system to keep the specs and the code in sync versus just using the code as the source of truth always.

Their words

And the plan doc, what was bad about it is it didn't give you leverage. The plan was every single line of code that was going to change like in diff blocks and like all the new stuff to write. And so like people would review these plans. We recommended this. We told people to read the plans. We read all our plans. And then eventually I found myself like I just kind of skimmed the plans.

Their words

you can slow way down and read every PR and read every line of code. Uh, and then you're only going to really get modest benefits from AI because that becomes I I think you should expect maybe 30 to 50% lift in productivity is kind of what I see when we go into teams

Their words

if you want to do loops engineering, you should build one loop at a time and you should keep them small and contained. Basically, I think everything except stop reading the code is really good advice.

Their words

yes it will catch things and it will raise your floor but I don't believe like the model writing the code is the same model reading the code and if you ask a model hey is this code good it's going to be like oh yeah it's great comprehensive it's got unit tests

Their words

But it's basically this idea that like the only thing that made claude code good was reinforcement learning. And the dimension along which it got good was like we made a model. We trained the model and the harness together. And so the model got really good at calling the specific tools in that harness.

Their words

And uh it's still worth it's still worth not reading the code for most of the time at the cost of every once in a while I'm going to have to spend two weeks fixing an issue by hand. And I don't believe that anymore because I think the amount of code we're able to write now is actually like 10xed or 100xed and I think the problem's just getting worse.

Their words

the problem with training models on maintainability is like the cost function of bad architecture and bad program design can't be evaluated by running the unit test because it hits you 3 to 6 months later

Their words

You'll notice what I said was not use loops to ship the features that users want. We use loops to actually improve the codebase quality and we read all the code because we care about how it's architected and we care not just about the system architecture but what I would call the program design

Their words

We tried this. We built a lights off software factory in July of 2025 and by November we had shut it down. I think it takes about three to six months of you shipping all the time with nobody reading the code before you realize like, wow, this is getting way worse and it's easier to start over than it is to fix it.

Their words

So I think the the thing I'm most excited is actually like what we call like iterated loops or like slow loops where we basically have a cron job. We have the loop the the the structure of the loop is really easy. It's like run this llinter fix one thing commit and push and then we run that every night in our GitHub actions and we wake up every morning to one PR that makes the codebase a little bit better.

Their words

And I think the lesson in loops engineering is like if you can make a problem very verifiable, you can kind of like treat it like a black box

Their words

there's a different kind of intuition that you that you develop over years as a software engineer and uh there's many categories of it but the one I'll I'll call attention to that is like a thing that you cannot teach you cannot do you cannot learn in a textbook. The only way to learn it is like I know bad patterns in software because I have debugged them at three in the morning.

Their words

But it's also your instruction budget is like if you give the model too many instructions and especially too many conflicting instructions and that's in your initial prompt and also like if you have a conversation you start going down a path and then you change your mind and you start going down a different you actually I don't want to do any of that I want to do this. It's like a it's a lot of computation the model has to do to notice that it has to ignore that whole thing.

Their words

You're not actually getting a like smarter model. like the intelligence of the model is is what drives its ability to attend to all of the tokens in the context window to figure out on the next turn which parts of this 100k or 200k context window are the most relevant to making the decision of like what is the next tool we call and doing that over and over again in a loop.

Their words

I think context engineering has been so long lived because it's it's grounded in the fundamentals of how transformer attention works and until we have post transformer models or linear attention or whatever it is which who knows when that's going to happen context engineering will be interesting and important to anyone building on AI

Their words

Well, harness engineering just is like how do I raise the floor so that every single turn of this thing, the results are as good as possible.

Their words

And at the end of the day, they're all like different ways to pass tokens into a model and ask it to produce usually some structured output. And understanding that is a lot more powerful than trying to learn memory and trying to pick some agent framework off the shelf and some memory framework off the shelf.