From one piece Context engineering with Dex Horthy 12 beliefs, in the piece's order there
-
Their words
We can we can teach we can teach somebody, I think, to be a really good AI developer in a few months. You can build enough intuition where you are, you know, accelerated off the ground and you can go like keep growing there. It's really hard to teach someone a CS undergrad program in in 3 months.
-
Their words
basically the idea is like the IDE of the future needs to be rethought from the ground up for agents. And it might not even be a like I don't know a lot of editors kind of started with the text field and bolted on an agents tab.
-
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
+ 9 more
-
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
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
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
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
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.