{
  "video_id": "-WBHNFAB0OE",
  "channel_slug": "indydevdan",
  "channel_handle": "indydevdan",
  "title": "AGENT THREADS. How to SHIP like Boris Cherny. Ralph Wiggum in Claude Code.",
  "duration_seconds": 1861.0,
  "url": "https://www.youtube.com/watch?v=-WBHNFAB0OE",
  "upload_date": "",
  "transcript": "What's up engineers? Andy Devdan here. I\nhave a simple trick question for you.\nHow do you know you're improving from\nthe vibe coder to the senior engineer\nshipping to production? With each\nprompt, how do you really know you're\nimproving your ability to ship with\nagents? Even Andrew Carpathy, one of the\ngreatest engineers of our generation,\nfeels left behind. He says, \"I've never\nfelt this much behind as a programmer.\"\nI think this speaks to a larger trend\ngoing on right now where we see a\nwidening gap between engineers that are\nusing agents and engineers that haven't\nbeen able to keep up. And with the\ncreator of Claw Code himself sharing his\nindividual setup, I thought this would\nbe a great time to talk about a new\nmental framework I've been using for\nover 2 years that's helped me\noperationalize my agents so that I can\ncontinuously improve. One step is not\nenough. You need to be thinking about\nhow to continuously day after day\nimprove what you can do with agents\nbecause the ceiling keeps moving higher.\nThis framework I'm going to share with\nyou here strikes a common thread between\neverything happening right now in the\nage of agents from some of the best\nengineers feeling like they're falling\nbehind which by the way Andrew Karpath\nis going to catch up with no problem.\nAll the best engineers have one thing in\ncommon. They are self-aware. You can see\nhe knows that this feels like a skill\nissue and he's 100% right about that.\nAgentic engineering is a new skill. New\nskills need new frameworks to measure\nprogress against. This mental framework\nI'm going to share with you will tie\ntogether the Ralph Wickham technique\nwith Boris Churnney setup and it'll give\nyou a concrete road map for knowing for\na fact that you're improving. If you\ndon't measure it, you will not be able\nto improve it. So let me introduce you\nto threadbased engineering.\nSo what do I mean when I say a thread?\nI'm talking about a unit of work over\ntime driven by you and your agents. A\nthread has two mandatory nodes. You show\nup for the prompt or the plan and the\nreview or the validation. Now, the\nmiddle piece here is your agent doing\nwork. These are the individual tool\ncalls that your agent makes. The\nbeginning is you prompting or planning.\nThe middle is your agent doing work. And\nthe work here is the string of tool\ncalls. And the end is you reviewing or\nvalidating. This should look very\nfamiliar. Every time you hit enter on a\nprompt in a tool with an agent, you are\nstarting a thread of work. Let me be\nsuper concrete here. Every time you open\na terminal and you fire up your agentic\ncoding tool and you run a prompt, what\nis this codebase about? You are firing\nup a new thread of work. So, I've just\nran the prompt and now my agent is doing\nits line of work. It's running a chain\nof tool calls. In this case, it's firing\noff a sub agent to accomplish work. But\nyou can see there are all the tool calls\nrunning. When this completes, I'm going\nto have to review the work. So, you and\nI show up at the beginning and the end.\nSo, 10 tools, 21K tokens. Now it's going\nto give us a summary and this is us\nreviewing the work. This line of work,\nthis thread has now completed. This is\nwhat I mean when I'm talking about\nthreads of work. So why do we care about\nthe base thread? It's because this gives\nyou everything you need to know to\nimprove. And the key insight here is the\nfact that you can measure the value your\nagents creating in tool calls. Tool\ncalls roughly equal impact assuming\nyou're prompting something useful. Now\npre2023 you and I were the tool calls.\nWe were updating the code. We were\nreading. We were doing the web requests.\nWe were doing all of that. But\neverything has changed. Now we show up\nat the beginning with the prompt and the\nend with the review. The base thread\nrepresents a unit of engineering work\nover time driven by you and your agent.\nNow the base thread itself isn't that\ninteresting, but everything we do from\nhere builds on that. Because after you\nhave one thread, guess what you can do?\nYes. Scale it.\nparallel execution. You can set up\nmultiple threads of work running\nsimultaneously in your terminal, in your\ngit work tree, in your sandbox. And\nnormally these will be spread across\ntime. You can kick your prompts off in\nsync together like this, but oftent\ntimes you'll be firing off a new\nterminal or work tree or some process,\nright? some cloud out of the loop agent\ndecoding tool across time because you\ncan't really review or prompt everything\nat the same time. There's always a\nlittle shift over time. So here's a\nprompt. Once that line of work gets\ngoing, you can write another prompt.\nOnce that line of work gets going,\nyou're freed up to write another prompt\nor plan and then you eventually review.\nAnd we can concretely see this from an\nengineer like Boris Churnney, the\ncreator of Claw Code. How does this tie\ninto everything happening right now in\nthe industry? Everyone is running\nthreads of work. Boris has this great\ntweet here. He's talking about his\nvanilla setup of cloud code. It's\nrelatively simple, but you can see here\nhe is running the P thread parallel\nthreads. All right, he runs five clawed\ncodes in his terminal and he numbers his\ntabs one through five. So out of the\ngate, Boris Churnney expects to run\nmultiple agents. It's not even a\nquestion. He just defaults to running\nfive agents in parallel. Guess who's\ngetting more done? The engineer kicking\noff a single agent in one terminal or\nfive agents in five separate terminals.\nThis is the Pthread in action. Now, if\nwe scroll down even further, he mentions\nthis as well. He also runs five to 10\nadditional cloud codes in the Cloud Code\nweb interface. All right, so he's got\nbackground clouds running and he kicks\nthem off using the at symbol you can run\nin Cloud Code to kick off sessions in\nChrome that he teleports back and forth.\nThis is very cool. And once again, he's\nkeeping track of multiple threads of\nwork. So this is very powerful. After\nyou have a single line of work running,\nyou can then kick off additional lines\nof work, right? Units of work. You can\nkick off additional threads. I do this\nso often that I have tools like the fork\nterminal skill that I can use to kick\noff brand new terminals and kind of\nbranch out. And I also have tools like\nthis pthread review the Ralph Wiggum\nimplementation in apps/star. And I want\nto run four of these. All right. So I'm\ngoing to fork my terminal and I'm going\nto kick off a brand new process. I have\nPthread alias. And so what I'm going to\ndo here is kick off multiple threads of\nwork with a single prompt. All right. So\ncheck this out. I forked a terminal and\nit's created four instances of this\nAsian. I'm using a few different tools\nand a few different skills combined\nhere, but the idea is simple. I can have\nmy agents and I can run commands that\nspin up additional agents. So, what I'm\ndoing here is I have four agents running\nin parallel with that same prompt.\nThey're all figuring out what this\ncodebase does. And if we scroll up here,\nyou can see these are all individual\ninstances review the Ralph Wickham\nimplementation in apps. So, I have four\nagents, right? I just spun up 4x the\ncompute that a normal engineer would by\nparallelizing. All right, so this is the\nP thread and this allows me to tap into\nmore compute. This is ultra useful for\nthings like reviewing. In addition to\nthe way that Boris uses cloud code,\nwhere you are spinning up one to 10\nparallel cloud codes to accomplish\nindividual units of work, you can also\nspin up agents to run the exact same\nprompt to get more confidence in their\nresponses. For example, one of my\nfavorite ways to use a tool like this is\nto run codebased review. Repeat threads\nlet you scale your engineering output\nthrough parallelism. This is one\nconcrete way to know that you're\nimproving. Can you spin up more threads\nof work where you are prompting and then\nreviewing after your agent has\naccomplished the work? If you have to\nsit and babysit a single agent, you\nprobably need to scale down your threads\nand just work on a single thread of\nwork. So, this is just two of six\nthreads we're going to talk about in\nthis video. We're going to work through\nthese to showcase how you can think\nabout engineering with agents and\nimproving what you can do. And there's a\ncommon thread. There's there's a common\nidea among all of these, right?\nUltimately, what we're doing here is\nincreasing the total tool calls your\nagents are making on your behalf. So,\nwe've covered the base thread and the P\nthread, the two most common types of\nthreads, the two most common lines of\nwork you can do with your agents. We're\ngoing to cover C, FB, and L threads\nright now. And to be super clear, we're\nnot talking about traditional, you know,\nCPU process threading. These are lines\nof work that you and your agent\naccomplish where you show up at the\nbeginning for the prompt or the plan and\nthen the ending for the review and the\nvalidation. All right, this is a new way\nyou can think about engineering with\nagents.\nWhat if you have a massive multi-phase\nplan? You can use a Cthread. The C\nthread is perfect for this. This is a\nchained thread. You can chain together\nwork into phases. Now, these checkpoints\naren't because your agent has messed up.\nThat's not what a chain thread is.\nThat's bad agent coding. All right. What\nI'm talking about here is intentionally\nchunking your work. Why would you use a\nCthread? There are two main reasons.\nMaybe the work can't fit in a single\nagent's context window. Or maybe you're\ndoing high pressure production work and\nyou want to chunk it down to make sure\nevery single step is right. This is the\ntool you can pull out of your pocket\nwhen you have a large chunk of work that\nneeds to be broken down into smaller\npieces. Say you have a 50-step plan that\nis very sensitive and if one thing goes\nwrong, things will crash in production.\nSay you're doing like a migration or\nsomething, right? Some type of high-risk\nproduction level work. You can run in\nchunks. So you can plan and review one\nchunk of work and then after you review\nyou can continue the next phase of work\nwith that agent or another agent and\nthen you can continue to phase three. So\nthis is a great way to chunk up work.\nCloud code has the ask user question\ntool where your agent can stop\nmidworkflow and ask you a question. This\nis great for Cthreads. You can also just\nuse the system notification and this is\nsomething that Boris does. He mentions\nthe system notification when cloud code\nneeds input. So when it's finished its\nchunk of work that it just did, you can\nhave your agent use natural language to\ncommunicate to you that it's finished\nwork. I have a text to speech hook that\nruns in some of my code bases that will\nhave my agent summarize the work and\nthen spit it back to me in natural\nlanguage. It's super useful for hopping\nback in the loop for that next phase of\nwork. So Cthreads are very powerful for\nthis reason. It's great for production\nsensitive work. Of course, on the\nchannel, we always talk about increasing\nthe trust you have with your agent so\nthat you need fewer human in the loop\nreview steps. But still, we have to be\nrealistic. There's a lot of production\nwork that we want to decompose down into\nsingle steps so that we increase our\ntrust in the work that was done. All\nright? And the trade-off here is your\ntime and energy. The Cthread is the\nfirst thread where you really want to\nquestion yourself before you use this.\nDo you need to break this work down into\nphases? If you do, C threads are great.\nIf you don't, just use a base thread.\nLet's move on to the F thread. This is\nby far my favorite type of thread. All\nright, this is the fusion thread. This\nis also known as a fusion chain. We've\ntalked about this pattern for over two\nyears now on the channel, and it's never\nbeen more relevant. The idea is simple.\nYou send the same prompt or a similar\nprompt to multiple agents. You then\nreview all the results and then you\ncombine them. You aggregate them. You\nfuse them. And in previous videos, we've\ntalked about the best of end pattern\nwhere you spin up multiple agents and\nthen choose the best. This is that\npattern exactly with entire lines of\nagent work. All right. So now, not only\nare we parallelizing, we're spinning up\nmore agents using more compute and then\ntaking the result we like the best and\nthen combining it. And you can aggregate\nany way you want, right? It's not always\nbest of end. Sometimes you want to\ncherrypick ideas and results from many\ndifferent agents to get a superior\nresult. Again, I use this all the time\nwith my Pthread tool. If we open up a\nterminal and then we can prompt\nsomething like this. I have this queued\nup already for us. So, I'll just paste\nthe send. Use Pthread with three CC3 gem\nthree codecs and then use this prompt.\nExactly. We're firing up multiple agents\ninside of a single workload. We're\nparallelizing a result. And this is one\nof my favorite ways to use agents. By\nthe way, I'm doing rapid prototyping all\nthe time now. And my Pthread skill, my\nparalleliz skill helps me do this. Now,\nthe fusion thread starts out as a P\nthread and then you combine the results,\nright? You choose the best event or you\naggregate or you merge the result,\nright? You fuse them and then you have\nyour final result at the end. And so\nwhat's going to happen here is my agent\nis going to kick off nine agents in\nparallel, three running cloud code,\nthree running Gemini, three running\ncodecs. And you can see here uh with\nthis great MROS tool. I'll link it in\nthe description for you. I've kicked off\nmultiple agents and they're all going to\nspin up their own agent sandbox. We've\ntalked about agent sandboxes in the past\non the channel. I'll go ahead and link\nthose as well if you're interested. Um\nagent sandboxes are great because you\ncan defer trust with your agents. This\nis the pattern for rapid prototyping,\nrunning many versions, right? For\nlooking into the future with multiple\nbranches of what a solution could look\nlike. Again, this is my favorite thread\nby far just because you can do so much.\nYou can experiment so much and so fast\nby deploying more compute. So anyway, so\nthese agents are going to spin. This is\na P thread I've spun up, right? So I\nhave multiple lines of work running. I\nhave nine lines of work technically\nrunning right now. And when they finish,\nwe're going to synthesize them, combine\nthem, choose the best, and then when it\ncomes to agent sandboxes, we would pull\ndown maybe one or two versions, and then\ncombine them to select the result we're\nlooking for. The key insight here is\nsimple with the fusion thread. The\nchances you'll have a successful agent\ncomplete the work go up when you have\nmore agents trying to complete the work,\nright? Just take more shots at the\nproblem. Fusion threads scale through\nconsolidation. And the idea is so\nsimple. Here we're using more compute to\ngain more confidence. If you ask one\nagent a question, it'll say something\nback. If you ask five, you'll get a much\nhigher confidence in the answers that\nwere returned. Say four out of five of\nthem gave you the exact same answer. you\ncan be more confident in that answer.\nResearch agents use fusion threads\npretty often. You know, using sub aents\nor, you know, spinning up multiple\nversions to do multiple web searches.\nThat's the kind of most blatant example\nout there. But there are many other ways\nto use the fusion thread. This is where\nwe start stepping into advanced agentic\nengineering territory. Most engineers\nhaven't used a fusion thread outside of\nspinning up multiple sub aents, which is\nabsolutely an example of a fusion\nthread. The big difference there is your\nprimary agent is fusing the results for\nyou. So you need to be clear about how\nthat work occurs. The fusion thread is\nthe cream of crop for rapid prototyping.\nAnd I'm just going to go ahead and say\nthis. The future of rapid prototyping\nwill be done with fusion threads. You\ncan mark my words on that. I'm betting\nbig on this trend. This is the F thread.\nNow things start to get interesting. Now\nwe can start scaling and getting kind of\nmeta with our threads. All right.\nEverything in engineering eventually\nrecurses back on itself. You build the\nthing with the smaller pieces of the\nthing. Bthreads, also just known as a\nbig thread, is a meta structure. Now\nyour prompts are firing off other\nprompts. So the clearest example of this\nis firing off sub aents. When your agent\nprompts other agents, those sub aents\ncan do more specific well-defined work\nfor you. The simplest example of this is\nthe plan build workflow where you have\none agent plan and the other build. The\ngreat thing is here with the Bthread is\nfrom your perspective as the engineer\nyou're just running a prompt and you're\nreviewing it at the end. Of course you\nwill agent engineer all the stuff that\nhappens on the inside whether you're\nrunning a base thread a P thread C\nthread F thread whatever you're doing\ninside of your big thread that is all\nhidden from you. It's a black box. You\ndon't care because you've engineered it\nthe right way and it's just going to run\nthat way. So the whole idea here with\nthe B thread is by deploying more\ncompute here you create a thicker\nthread. You can run more threads, you\ncan fuse your threads and you can create\nthicker threads. More stuff happens here\nwithin a specific unit of time when you\ndeploy the right subthreads. All right,\nso this is the meta structure. The big\nthread contains threads. The key pattern\nhere is that you have an agent that is\nwriting prompts for you. The first\nversion of this showcased by claw code\nis the sub aent. When you prompt your\nprimary agent to run sub agents, it is\nprompting the sub agents. Now on the\nchannel, we've also looked at the\norchestrator agent, which is the next\nhigher level up to this where you have a\norchestrator agent kicking off primary\nagents. There's a lot more you can do\nthere, but you know, imagine a team,\nright? Your orchestrator agent can kick\noff a team, a plan agent, a scout agent,\nthen a build agent, then multiple review\nagents, then finally a, you know,\npre-eploy staging agent. Then you come\nin at that last step for the review and\nthen you kick it off, right? That's the\nB thread. A bunch of stuff, other\nthreads of work happen inside, but you\ndon't care about them. That's where your\nB thread to manage. From your\nperspective, you kicked off one thread\nwith a prompt and then you reviewed it\nat the end. You showed up at the\nbeginning and the end under the hood.\nYour system of agents or your teams of\nagents orchestrated running a base P or\nof course another Bthread underneath.\nAll right, Bthreads are really important\nand very powerful because they start\npushing you into not just running\nagents, right? They start pushing you\ninto this idea of combining code plus\nagents to get outsiz return on your time\nand your effort. All right? And a\npattern that does exactly that is\nstarting to emerge. We now have this\nRalph Wiggum pattern which is\neffectively AI engineers are starting to\nfigure out that agents plus code\noutperforms agents alone. Right? Ralph\nwelcome is literally a loop over an\nagent to accomplish specific work. I'm\nbeing a little bit reductive there, but\nthat is the idea. We've talked about\nthis idea for over a year now. This is\nin both courses, principal AI coding and\ntactical agent coding. We know this as\nAI developer workflows, ADWs, but it is\ngreat to see a pattern like this really\nhitting the mainstream. Big shout out to\nJeff Huntley for bringing this idea to\nthe masses and really scaling it. That's\nthe B thread. Now, speaking of Ralph,\nthere is one more thread that ties it\nall together. So, how do you get thicker\nthreads? You build teams of agents. You\nbuild workflows, right? You build\nagentic workflows. You build prompts\nthat call other agents. You build sub\nagents, custom agents. Ultimately here,\nwhat we're doing is you're specializing\nyour agents. You teach your primary\nagent how to use the right tools. And\nthen they do it end to end.\nNow this brings us full circle to the L\nthread. So the L thread is high autonomy\nendtoend long duration work. All right,\nextended agent autonomy without human\nintervention. You can have a huge huge\nprompt that runs and it can be hundreds\nand hundreds of steps long. It could run\nfor hours. You've seen Boris and other\nengineers run prompts for hours and\nhours. Some, you know, over a day long.\nAnd I think he had a post down here\nsomewhere showcasing one of his long\nduration runs. Yeah. 1 day, 2 hours.\nVery, very impressive longunning L\nthread. And he even mentions the Ralph\nWickham plugin here. But the idea is all\nthe same. Scratch all the, you know,\nfancy prompting threading work from all\nof our previous steps. Just write a\nclearer, better prompt with the right\ntooling that lets your agent run longer,\nhigh autonomy, massively long duration\nworkflows, calling many, many, many\ntools. We're talking hundreds and\nthousands of tool calls. And this is the\nLthread. Now, notice what this looks\nlike. The Lthread comes full circle\nright back to our base thread. Same\nshape, just longer, more tool calls.\nThat means more autonomy. Nothing fancy\ngoing on here, right? We're getting\nbetter at prompting. We have better\nmodels. or manage our context better and\nour tools help drive that effort\nforward. Once again, I'm referencing the\ncore four context model prompt tools. If\nyou understand the core four, you\nunderstand agents and therefore agentic\nengineering. Everything comes back to\nthis. The engineer running longer\nthreads of useful work is outperforming\nthe others. There's a ton of untapped\npotential in figuring out how to kick\noff agents to run longer. This is where\ngreat planning pays off because great\nplanning is great prompting. And this is\nof course why Ralph Wiggum is gaining so\nmuch traction right now because\nengineers are realizing that if you can\nhave your agent keep running against the\nproblem you want to solve, it will run\nlonger chains of work with more\nautonomy. Right? Even if we are kind of\nconducting the autonomy with something\nlike the stop hook. Now I want to give\nthe stop hook a little attention here\nbecause I think Ralph Wickham again\ngreat idea Boris mentions this as well\nright stop hook for very longunning\ntasks the L thread I will either prompt\nclaw to verify its work with a\nbackground agent so here this is in fact\na C ththread after it finishes it work\nhe's going to run another agent to\nverify its work okay so he's chaining\ntogether multiple calls to make sure the\nwork is done or he uses the agent stop\nhook all right so this is super\ninteresting the agent stop hook is\nsomething we're going to be talking\nabout more on the channel. I didn't want\nto put it in this video, but I wanted to\nbriefly kind of showcase the workflow.\nYour agent tries to stop, the stop hook\nruns, and then there's some decision\ncode that you run. This is the\ndeterministic code. The stop hook can\nintercept, it can run some code, it can\ncheck a progress file, it can run a\nvalidation command, and then it can\ncontinue the workflow where you reloop\nover again or it completes the work. All\nright, so the stop hook is super\nimportant. It allows you to tap into\nthat deterministic traditional code plus\nagents. Again, if you're inside of\ntactical agent decoding, you've already\nseen this. You're already working with\nthis. We call these ADWs there. All\nright. The stop hook lets you tap into\nthat inside of the claw code ecosystem.\nVery powerful. What do all of these\ntechniques give us? Thread-based\nengineering is a way to think about\noperating with agents. You show up at\nthe prompt and the review, but this\nmeans that there is a huge intermediate\nstretch of time where your agent is\ndoing the work. This gives you the\nopportunity to spin up additional\nthreads of work in different shapes and\nconnect them in different ways. So, we\nhave six threads here. These are the\nmost common that I've seen and the most\nimportant for quickly getting results\nout of your agents and for knowing that\nyou're improving. So, let's dive into\nthat more. Right, we kicked this all\noff. We started this video by asking,\nhow do you know you're improving? You\ncan think of improving in terms of your\ntotal threads, the length of your\nthreads, the size of your threads,\nultimately boiling down to one thing.\nThe number of tool calls you're running\nwith your agent.\nThere are four concrete ways to improve\nwith the threadbased engineering\nframework in mind. You can run more\nthreads, you can run longer threads, you\ncan run thicker threads, and you can run\nfewer human in the loop checkpoints. All\nright, when you do this, you're\nincreasing the trust you have in your\nsystem. So these are the four ways you\ncan improve when you're thinking about\nengineering with agents, right? When\nyou're thinking about agentic\nengineering, more threads, longer\nthreads, thicker threads, or fewer\ncheckpoints. And you can see this, you\nknow, for me, Boris's post here is so\nvaluable because it showcases how he's\ndoing more with his threads of work.\nHe's got five clouds in parallel in the\nterminal. Fantastic. And then he puts\nthem on the background, probably short,\nmedium to long running threads, but he's\nscaling up even further. Right? If we\nhop back to parallel, right, our P\nthreads, he's got multiple threads\nrunning. He's got 10 threads running at\nmost based on his post. So very very\npowerful, very cool. There are a couple\nother mentionables here. He always uses\nOpus 4.5. Makes sense. Claude in the\nrepo, but they don't let it get too\nlarge. That's great, right? He's got\ninloop agent decoding inside of his\nterminal, and he's got outloop agent\ndecoding with the cloud code web\ninterface, so he can step away. Let's\nsee. Anything else here? Interesting. He\ndoes not use dangerously skip. He sets\nup specific permissions. I think this\nmakes sense if you're working in a\nsingle codebase for the most of your\nwork. But you can see all in all he's\ngot multiple threads running of work,\nspecifically parallel threads, right?\nAnd then his final tip here is the most\nimportant thing to get great results out\nof cloud code, give it a way to verify\nits work. Essentially creating a\nvalidation loop or a closed loop system,\nright? A feedback loop so that your\nagent can resolve its own work. And this\nspeaks to both the strengths and the\nweaknesses of the Cthread. You don't\nreally want to be hopping in the loop.\nIn fact, this is one of the four ways\nyou can improve. reduce the number of\ntimes you have to review your agent's\nwork. Again, there's some critical\nscenarios where you do want to step in\nthe loop and make sure that your agent\nhas done the right thing, but as much as\nyou can give your agents the tools to\nvalidate their own work. All right, so\nagain, four ways to improve your\nengineering. Run more threads, run\nlonger threads, run thicker threads, and\nrun fewer human in the loop checkpoints.\nI know this is a little high level. It's\na little void of details of how you run\nmore, longer, thicker, or fewer, but the\nideas are there. Spin up more terminal\nwindows. Make sure you have inloop agent\ndecoding tools and outloop agent coding\ntools. Of course, Boris uses cloud code\nand the cloud code web interface. You\ncan use whatever you want. I always\nrecommend, you know, for your production\nassets, you build your own net new\nagentic layer around your codebase.\nThat's one of the critical topics inside\nof tactical agentic coding. Why do I say\nthat? It's because you want a\nspecialized set of agents operating your\nspecialized codebase built to solve a\nspecific problem. So these are four ways\nyou can improve your agentic engineering\nby looking at everything you do as\nthreads of work.\nAnd so I want to share just one last\nthread here, kind of a teaser thread for\nyou. What happens when your agentic\nengineering evolves to such a high level\nthat you're able to push your agents far\nand they're reviewing all their work and\nthey're accomplishing tons and tons for\nyou. What is the future of engineering?\nRight? What happens when you increase\nyour trust with your agent to the max?\nYou blow away the review step. All\nright? There is a hidden seventh thread.\nI call it the Zthread. This is the zero\ntouch thread. All right? This is the\nmaximum trust you have with your agents.\nI've teased this in the singularity\nvideo we put out last week or a couple\nweeks ago and this is a big idea of\nwhere engineering is going. I'm not\ngoing to talk about this one too much\nbecause it's one of the big ideas we\ntalk about in tactical agent coding near\nthe ending advanced lessons and a lot of\nengineers just don't believe that this\nis possible and I don't want to confuse\nany engineers especially newer engineers\nin thinking that this is vibe coding\nthis is not vibe coding this is very\nvery high level very advanced agentic\ncoding this is maximum trust it isn't\nthat we don't look at the code it's that\nwe know we don't have to that's the\nendgame let's come full circle here how\ncan great engineers like Andrew Carpathy\nkeep up in the age of agents that we\nlive in. You can think of all of your\nwork in threads. A thread is a unit of\nengineering work over time conducted by\nyou and your agents. You prompt and plan\nin the beginning and then you review and\nvalidate when your agent has finished.\nIn the middle, your agent is doing the\nwork through tool calls. This is\nthreadbased engineering. So, how do you\nknow you're improving? You know you're\nimproving because you can do one of the\nfollowing. You can add threads. You can\nrun longer threads. You can combine the\nresults of different threads of work.\nAnd then you can compose threads\ntogether so that you show up at the\nprompt and review step while additional\nthreads run in between your agents work.\nSo your agents are firing off other\nagents to complete and chain together\nwork. And then in the end you just run\nlonger threads. You do this by learning\ngreat agentic prompt engineering and\ngreat context engineering. In the end,\nremember that everything boils down to\njust four pieces. The core four,\ncontext, model, prompt, and tools. You\ncan use these six threads as a\nfoundation for you. But the core idea is\nto remember if you want to improve,\nyou're running more threads, you're\nrunning longer threads, you're running\nthicker threads with nested threads\nunderneath, and you're running fewer\nhuman in the loop checkpoints, right?\nbecause you've built systems that you\ntrust, because you're using better\nmodels, better tools, better context,\nand you're writing better prompts. All\nright, the most important thing to\nremember, too, is that agentic\nengineering or engineering with agents\nis a new skill. At first, you'll be\nrunning short threads of work with one\nagent in the terminal. Then, before you\nknow it, you'll be more like Boris,\nrunning five agents in the terminal and\nfive more out the loop in the cloud\nsomewhere. You'll add more threads.\nYou'll make them thicker and then you'll\nmake them run for longer. Then once\nyou've pushed to the edge of agentic\nengineering, you'll access the final\nthread level, the Zthread. This\nrepresents the northstar of the big\nideas we talk about in tactical agentic\ncoding. I'll leave a link for that in\nthe description for you if you're\ninterested. But in the end, we're\nrunning Zthreads, zero touch threads.\nThere's no more review node. This is\nwhat you want to be pushing toward. This\nis what I and other top engineers are\npushing toward. I don't want to have to\nreview my agents work. I want to be able\nto push past that, scale past that. All\nright? I want to accomplish the mission\nof this channel, which is to build\nliving software that works for us while\nwe sleep. That's been the mission for\nyears. That hasn't changed, and we're\ngoing to work toward that every week\nhere, every single Monday. This is the\nfuture of engineering. So, start pushing\ntoward it. Don't be afraid of it. Don't\nrun away from it. Software engineering\nhas changed again and again and it will\ncontinue to. But by thinking in threads,\nyou can know that you're improving\nbecause you're giving more work to your\nagents and you're showing up where it\nmatters most, the planning and the\nreviewing. If you want to scale your\nimpact, you must scale your compute. If\nyou want to push what you can do further\nand fast track your journey into this\nnew role of Agentic Engineering, check\nout Tactical Agentic Coding, link in the\ndescription. As always, I'll see you\nnext Monday. Stay focused and keep\nbuilding.",
  "transcript_chars": 32491,
  "ingested_at": "2026-05-15T04:47:08.844112+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 29286,
    "like_count": 973,
    "channel_id": "UC_x36zCEGilGpB1m-V4gmjg",
    "categories": [
      "Science & Technology"
    ],
    "tags": []
  }
}