Transcription
Mastering AI is not about how well you write prompts. It's about creating systems where loops start to run without humans having to tell them to move one by one. That is, doing loop engineering is what it means to be able to master AI. This is the 2026 version. Boris Cherny says he no longer prompts directly. He says his job is to write loops. For example, after a meeting ends, the AI starts up, coordinates a meeting between person A and person C, and sends out calendar invitations. Hello everyone. I'm Takahiro Yasuno. Today, I will talk about loop engineering. When we talk about mastering AI, what most people think of is how to write good prompts. There was the concept of prompt engineering, where writing a good prompt leads to good results. However, recently, people working on the front lines of AI coding have started saying, "Let's stop writing prompts." What does this mean? It means that instead of writing prompts and giving AI instructions one by one, the focus is shifting to how to create mechanisms that allow AI to operate automatically. The focus is shifting to designing the loops that AI uses to do various things. This is the concept of loop engineering. Therefore, today I would like to talk about loop engineering. I will divide this into three parts. The first part is: What is loop engineering? We will look at the overall picture through four stages. Second, I will explain why people on the front lines have started saying, "Don't write prompts, write loops." Third, I will look at how these loops actually work through concrete development examples. This is not just for people developing with AI, but I believe this approach will increasingly spread to jobs outside of software engineering in the future, so I hope those people will listen as well. Okay, from here, please look at the image. What is loop engineering? First, it's a shift from the initial stage of writing prompts to writing loops where AI performs tasks. The word "loop" is a key keyword here. What is this loop? Generally, humans perform tasks, and AI produces results. We then judge whether these AI-produced results are good or bad. If they are bad, we might ask for them to be modified in a certain way, inspect them, review them, and then the next time, AI performs the task again, and humans review what it produces. This process is a spiral loop. It's like, "Do this, do that, and then humans confirm." There is such a loop. Within this, there is the concept of "human-in-the-loop." This means that humans are within the loop, reviewing or telling the AI to do something. This entire workflow where humans are involved is called "human-in-the-loop," or HITL. Recently, it's been said that having humans in the loop is very inefficient. With AI becoming so intelligent, perhaps humans don't need to be in the loop. This has led to the concept of "human-on-the-loop." Not "human-in-the-loop," but "human-on-the-loop." This means humans supervise the loop from the outside, and if it goes in the wrong direction, they say, "Wait, wait, wait," but they are not involved in the basic tasks. The difference between "human-in-the-loop" and "human-on-the-loop," where only "in" and "on" change, is very important. There are several stages to this transition from "human-in-the-loop" to "human-on-the-loop." It is said to be four stages of human involvement. First, there is the prompt. Second, there is context. Third, there is harness. And finally, there is the loop. These are referred to as 1, 2, 3, and 4. First, at the prompt stage, which is prompt engineering, it's about devising ways to ask AI. For example, "You are an experienced software engineer. From the perspective of a software engineer, what kind of bugs do you think the code below has?" Asking questions like this is part of the initial stage of designing prompts. Second is the stage called context engineering. This is not just about how to ask each time, but about designing the entire information context that AI considers when making decisions. For example, the AI looks at the specifications, then at the coding standards, which are the rules for coding, then at related files, and then at past interactions. We ensure that this is provided each time. So, it's not just about what you want done, but about providing the necessary information to the AI when you want it done. The amount of information that AI can handle at once, called the context size, is limited. For example, with current models like Claude, it's up to 1 million tokens, which is about the volume of 10 books. While 1 million tokens is a lot, context engineering is about how to fit what kind of contextual information into this limited context window. Third. The third stage is called harness, or harness engineering. A harness is a scaffold that allows AI to work safely and with verification. For example, writing a command to test after a task is completed is a prompt. However, if the test fails, you cannot proceed to the next step. It's not a valid inspection. The mechanism that ensures tests must pass is not a prompt request, but rather part of the environment in which the AI operates. So, when the AI operates, it's about creating an environment where the AI can work safely, such as having to pass tests when creating or executing software, or having rules about what it cannot do. This is called harness engineering. It's about creating an environment where AI can work safely, such as not being able to delete data, being able to connect to certain websites on the network, or not being able to proceed to the next phase without passing tests. Fourth is what we are talking about today, called loop engineering. This is not about writing prompts each time. Up to level 3, harness engineering, humans are giving instructions each time. Prompt engineering is about improving how those instructions are given. Context engineering is about ensuring that AI receives the necessary information. Harness engineering is about creating a safe working environment so that the AI that starts operating can proceed smoothly. Loop engineering is about incorporating the initial stage of writing a prompt and the AI starting to operate into the loop. It's about automating the process of giving instructions to AI and making it move, so that you can get out of the loop of that work. However, it's important to note that simply letting AI operate automatically doesn't mean it will work well. If you don't have a robust harness in place to ensure it operates safely and follows rules, letting it move freely in a loop can lead to dangerous situations. What is included in a harness? For those who haven't dealt with software engineering, it might be difficult to understand, but for example, there are files like Agents MD or Claude MD, which write rules for how the AI should operate. There are also tests, which are separate software that confirms whether the source code is working correctly. The ability to create these tests and confirm that they all pass as normal behavior is part of the mechanism. There are also linters, which check if the code adheres to specific rules. There's also log management, history management, and mechanisms for escalating to humans when unsure, to seek human guidance. All of these are included in what is called a harness. Without such scaffolding, if you start running loops, they will go out of control. Therefore, for loop engineering, it is a prerequisite to have harness engineering well established. In other words, by 2026, mastering AI will not be about how well you write prompts. It will be about how well you incorporate not just prompts, but also contextual information, information that enables AI to work. How well you set up the harness that allows AI to operate, and how well you can start the loops running smoothly, so that the loops start running without humans having to tell them to move one by one. This means that humans can get out of the loop and achieve human-on-the-loop. This is what it means to be able to master AI in the 2026 version. The idea of designing these loops began to emerge around the beginning of 2026 and became quite a topic. To introduce just two people, Peter Berger, who is now at OpenAI, posted on X, saying, "Let's stop prompting coding agents directly. We should design loops that prompt agents." Around the same time, Boris Cherny, who developed Claude Code at Anthropic, is also famous for having a past experience making miso in Japan. So, there was a popular joke that because Boris Cherny made miso, he made Claude Miso OS, or Mythos as it's now called, or Mythos in English pronunciation. Putting that aside, Boris Cherny says he no longer prompts directly. He runs loops that instruct Claude. He says his job is to write loops. Both of them are shifting from a world of giving instructions one by one to designing the mechanism of instruction itself. Both of them also talk about human-on-the-loop, where humans get out of the loop and supervise it. Now, for those who want to know more concretely how these loops work, Andrej Karpathy, a highly respected AI researcher, shares his perspective, which he organized while building products from scratch. Karpathy views loops as being composed of three types of loops with different speeds, nested within each other. The first is the fastest loop, shown in green in the diagram, where the agent writes code. Given specifications for what kind of software to create, and if necessary, test data, the agent implements, tests, corrects, implements, tests, corrects, and repeats this process every few minutes. This is the fastest loop. Karpathy mentioned that he built a typing practice app for his daughter over a weekend. It's a heartwarming episode that even a leading AI researcher does such things. For his daughter's typing practice app, the agent worked in a web browser, with the AI confirming what the agent created, and the work continued for about an hour without human intervention. The second loop operates more slowly, every few tens of minutes to a few hours, and this is where humans come in. So, the first loop is not human-in-the-loop, but human-on-the-loop, and Karpathy refers to it as a supervision loop. The blue parts represent human intervention. So, after about an hour, looking at what has been produced, you might say, "This part is wrong, this part is different," and continuously correct the direction. Since the AI tests itself, humans no longer have to do all the testing and coding. Instead, humans can focus on looking at what is produced every few tens of minutes to an hour and saying, "This is correct, this is wrong, this needs to be adjusted a bit more." This is the second loop. The third loop is a longer, external feedback loop, which can take anywhere from a few hours to several weeks. This involves having the results created by a developer reviewed by others, used by friends, previewed by some users, shown to a supervisor, or A/B tested in production to see which pattern is better. This process updates the creator's vision, which then feeds back into the specifications for the fastest loop. So, Karpathy organizes this by saying that we are actually working in a way that involves multiple nested loops with different time axes: the green loop where AI works rapidly, the blue loop where an individual supervises the AI, and the purple loop that emerges through interaction with others. This is how we are actually working, he suggests. As expected of a researcher, he is someone who can organize and explain what is happening very well. One other interesting point from Karpathy's talk is why humans need to remain in the loop. Karpathy states that it's not because of human intuition, which is a valuable resource. He says it's not that things won't be good without human intuition. Humans simply know things about users or the context in which a product will be used that AI does not. Humans are simply bridging the gap in information between themselves and AI. Therefore, there is a need for an element that inputs this knowledge, which AI does not know, into the system. Karpathy hypothesizes that this part cannot be automated. He has introduced the concept of loops. Designing these loops is about deciding where to place humans within these nested three loops and how to operate the AI. It's about the design itself. It's not about leaving everything to AI, nor is it about humans doing everything. It's about carefully considering the boundaries. This is the essence of loop engineering. So, today I have discussed three points. First, the way we interact with AI is shifting from prompt engineering to context engineering, then to harness engineering, and finally to loop engineering. The focus is gradually expanding outwards, towards engineering for larger tasks. Second, within this structure, many people are saying, "Don't write prompts, write loops." Upon closer examination, it seems to be about designing multiple loops with different speeds. Third, loop engineering is still in its early stages. People on the front lines are still exploring it, so there will likely be many updates. However, knowing the concept of loop engineering itself will be useful for both software engineers and non-software engineers. For example, let's consider secretarial work. Instead of creating software, imagine delegating secretarial tasks to AI. However, there are still things like tests. For example, someone only works until 7 PM and goes home after that. Or someone is raising children and cannot work after 5 PM. If you schedule an appointment for them after 5 PM, it will be rejected by the test. The rule "do not schedule appointments after 5 PM for this person" will reject it. If there is a harness mechanism that detects such things, then we can trust the AI even if it makes schedule adjustments automatically. In that case, it would be good to create a mechanism that can interact with a database of working hours, perhaps a time and attendance system, and detect rule violations. This kind of loop exists not only in software engineering but also in secretarial work, legal work, and even parliamentary work, where the concept of harness or loop engineering can be applied. For example, consider meetings. When you have a meeting, and it's transcribed, you might identify tasks that need to be done from the transcription. Tasks that someone needs to do. When a task arises, for example, after a meeting ends, the AI automatically starts up and identifies what tasks arose during the meeting from the transcription. This can be done as a form of loop mechanism. If there is a task that AI needs to perform, for example, "Person A and Person C need to discuss this, and it needs to happen within three days." If such a task arises, and the AI has the ability to manipulate calendars, it can coordinate a meeting between Person A and Person C and send calendar invitations to each of them. Then, Person A and Person C will click to accept the meeting invitation. This is a state where humans are involved in the workflow. This is not just a software engineering issue, but by combining existing technologies, it can be realized. Some companies have already achieved this level. Creating an environment where AI can work within a company is becoming extremely important. Therefore, if you found this video about the concept of loop engineering to be educational, please leave a comment, a like, and subscribe to the channel. That's all for today's video. Goodbye. [Music] [Music] [Music]