korrents

korrents · The Pragmatic Engineer Podcast

Context engineering with Dex Horthy

Dex Horthy · 1h 33m · youtube.com ↗

26 korrents from this recording

1h
Dex Horthy did not write this page.

Every claim below is a statement made in this recording, quoted word for word and linked to the second it was said, so you can hear it rather than take our word for it. The wording comes from the transcript published alongside the recording; the sentence above each quote is our reading of the claim, not their wording.

  1. 0:21:28 · watch on youtube.com↗

    Our reading

    Every abstraction in agentic programming — RAG, memory, agentic history, structured output — is just a different way of passing tokens into a model, and understanding that beats learning any of them.

    Their wordsAnd 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.
    Interesting
  2. 5 min later

  3. 0:26:43 · watch on youtube.com↗

    Our reading

    Harness engineering is raising the floor: optimising the environment a coding agent runs in so that the results of every single turn are as good as possible.

    Their wordsWell, 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.
    Interesting
  4. 1 min later

  5. 0:27:52 · watch on youtube.com↗

    Our reading

    Context engineering has stayed relevant for a year because it is grounded in how transformer attention works, and it will matter to anyone building on AI until post-transformer models arrive.

    Their wordsI 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
    Interesting
  6. 1 min later

  7. 0:29:05 · watch on youtube.com↗

    Our reading

    A bigger context window does not give you a smarter model; the intelligence of the model is what decides how much of that window it can actually attend to.

    Their wordsYou'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.
    Interesting
  8. 1 min later

  9. 0:30:15 · watch on youtube.com↗

    Our reading

    Context has two budgets, not one: the information budget everyone thinks about, and an instruction budget, where conflicting instructions cost the model real computation to ignore.

    Their wordsBut 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.
    Interesting
  10. 2 min later

  11. 0:32:15 · watch on youtube.com↗

    Our reading

    The engineering intuition that matters cannot be taught from a textbook — you know bad patterns in software because you have debugged them at three in the morning.

    Their wordsthere'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.
    Interesting
  12. 2 min later

  13. 0:34:38 · watch on youtube.com↗

    Our reading

    Loop engineering works exactly as far as verification does: make a problem very verifiable and you can treat it as a black box and let the model run.

    Their wordsAnd 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
    Interesting
  14. 2 min later

  15. 0:36:54 · watch on youtube.com↗

    Our reading

    The valuable form of loop engineering is a slow loop — a nightly cron job that fixes one thing and opens one pull request — not a redesign of your whole infrastructure around agents.

    Their wordsSo 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.
    Interesting
  16. 5 min later

  17. 0:41:53 · watch on youtube.com↗

    Our reading

    Ship for three to six months with nobody reading the code and the codebase gets so bad that starting over is easier than fixing it — we ran a lights-off software factory and shut it down.

    Their wordsWe 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.
    Interesting
  18. 1 min later

  19. 0:42:27 · watch on youtube.com↗

    Our reading

    Loops belong on codebase quality, not on shipping the features users want; we read all of the code, because program design is what decides whether a codebase stays changeable.

    Their wordsYou'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
    Interesting
  20. 1 min later

  21. 0:43:40 · watch on youtube.com↗

    Our reading

    Models will not learn to write maintainable code from today’s benchmarks, because the cost of bad architecture cannot be measured by running the unit tests — it arrives three to six months later.

    Their wordsthe 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
    Interesting
  22. 3 min later

  23. 0:46:17 · watch on youtube.com↗

    Our reading

    It is no longer worth not reading the code in exchange for the occasional two-week hand fix, because the volume of code we can now generate has gone up ten to a hundred times.

    Their wordsAnd 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.
    Interesting
  24. 8 min later

  25. 0:54:35 · watch on youtube.com↗

    Our reading

    What made Claude Code better than every CLI coding agent before it was reinforcement learning on the model and the harness together, so the model got good at that harness’s specific tools.

    Their wordsBut 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.
    Interesting
  26. 2 min later

  27. 0:56:24 · watch on youtube.com↗

    Our reading

    Agentic code review raises the floor but cannot be trusted, because the model reading the code is the same model that wrote it, and it will tell you the code is great.

    Their wordsyes 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
    Interesting
  28. 2 min later

  29. 0:58:26 · watch on youtube.com↗

    Our reading

    If you want loop engineering, build one loop at a time and keep them small: every part of the agentic-factory playbook is good advice except the part where you stop reading the code.

    Their wordsif 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.
    Interesting
  30. 2 min later

  31. 1:00:14 · watch on youtube.com↗

    Our reading

    A team that slows down and reads every pull request and every line of code should expect only a 30 to 50 percent productivity lift from AI.

    Their wordsyou 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
    Interesting
  32. 3 min later

  33. 1:02:53 · watch on youtube.com↗

    Our reading

    A plan that spells out every line of code to change gives you no leverage: it costs as long to read as the pull request, so you end up skimming it and reading the code twice.

    Their wordsAnd 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.
    Interesting
  34. 2 min later

  35. 1:05:05 · watch on youtube.com↗

    Our reading

    Research and planning documents are tactical execution artefacts to be thrown away and regenerated, because tokens are cheap and a doc that has drifted from the codebase costs you time.

    Their wordsI 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
    Interesting
  36. 1 min later

  37. 1:06:09 · watch on youtube.com↗

    Our reading

    Nobody has found keeping specs and code in sync worth the upkeep; the code stays the source of truth.

    Their wordsI 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.
    Interesting
  38. 1 min later

  39. 1:06:57 · watch on youtube.com↗

    Our reading

    The point of context engineering is to do as much work as possible in the smart zone — roughly the first hundred thousand tokens of the context window.

    Their wordsHow 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.
    Interesting
  40. 4 min later

  41. 1:10:42 · watch on youtube.com↗

    Our reading

    Without good intuition for models, treat 100k tokens on smaller models and 200k on the frontier ones as the line past which the quality of your results is probably already degrading.

    Their wordsBut 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.
    Interesting
  42. 2 min later

  43. 1:12:31 · watch on youtube.com↗

    Our reading

    Four things about a context window decide what an agent does next: its size, whether the information in it is correct, whether information is missing, and the trajectory it is already on.

    Their wordsthere'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.
    Interesting

  45. 1:13:00 · watch on youtube.com↗

    Our reading

    An agent repeats its own history: whatever it did on the last change — ran the tests or skipped them — is what it will do on the next one, because it is predicting the next message in the conversation.

    Their wordsAnd 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
    Interesting
  46. 2 min later

  47. 1:14:33 · watch on youtube.com↗

    Our reading

    Maxing out your token usage is optimising one node of the factory for utilisation instead of the end-to-end goal of shipping value that is stable and lasts.

    Their wordsAnd so it's like I mean getting into Eli Goldrat and the goal is like optimizing for utilization and efficiency of one node in your factory rather than the end to end goal of like how do we ship value and things that people like that are stable and like will last a long time. But that's my idea of token harder
    Interesting
  48. 8 min later

  49. 1:22:47 · watch on youtube.com↗

    Our reading

    The IDE of the future has to be rethought from the ground up for agents, rather than being a text editor with an agents tab bolted on.

    Their wordsbasically 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.
    Interesting
  50. 7 min later

  51. 1:29:23 · watch on youtube.com↗

    Our reading

    You can teach somebody to be a really good AI developer in a few months, but you cannot teach them a computer science degree in three — so hire for the fundamentals.

    Their wordsWe 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.
    Interesting