Loop Engineering: Design the Loop, or be the Loop
SubscribeSign in
Loop Engineering: Design the Loop, or be the Loop
Claire Tsao<br>Jul 05, 2026
Share
“You are absolutely right!” Again. I stopped counting how many apologies I got from AI every day. The chat feels endless even when I only want to fix a small bug.<br>The moment I felt I had to change it was when I talked to AI to create a config table edit webpage in TypeScript. I asked AI to follow existing patterns to create a new config table page for me. I had to talk to AI back and forth for over 10, maybe 20, rounds to get everything right. I had to run the build and test myself and report back to AI “This is the error message.” AI changes something. I test, and report. AI changes code again. And again. I’m in a loop. Or I should say, I’m the loop.<br>I was tired. They were repetitive work with clear patterns. Why couldn’t we get it right, or at least almost right, the first time? I only learned recently that this chase has a name now: loop engineering.<br>One prompt, one pass
The config tables have roughly the same layout, varying in column names, data type setup, and some buttons based on customer requirements. Writing a program to autofill takes time, but a prompt for AI to fill the page setup should be fast. It was mostly mechanical work. It took a few rounds to fine-tune the prompt until it filled the page setup and passed the build on the first attempt. It was such a pleasant experience that I was completely free from page creation. It got everything right with one prompt call, something human engineers rarely manage. We, or at least I, usually make a typo, forget to copy a dependency, forget to rename a variable, and so on when doing copy-paste-replace work like this.<br>That was the story behind my Zero Touch or Die piece on LinkedIn back in January. Looking back now, as Loop Engineering gets loud in the developer community, the Zero Touch philosophy is right at the center of Loop Engineering: we want to create a good design so it can run autonomously and complete its work without human intervention.<br>A stronger model won’t save you
People might think a stronger model can save the 20-round conversation. Yes, a stronger model can capture your intention better and achieve the goal smarter and faster, but a stronger model can’t know what I never told it. The missing context is usually what makes an output good or bad. The prompt is the magic itself. Writing a proper prompt, or designing an autonomous agent in today’s buzzword, is the key to getting AI to work for you without too many extra inputs stealing your time.<br>The split of AI and code is important. For deterministic work, where the same inputs always produce the same output, a script tool call is the right home. AI is a probabilistic machine by definition. If you have data verification that can be done with SQL or Python/Pandas code, set it up as a tool for AI to call. For judgment and analysis, outsource it to AI. Reasoning is what we want to use AI for. It can read results 10x, 100x faster than us, summarize them, and find errors or common patterns. Newer models are increasingly designed to identify gaps, so use them on their strongest dimension.<br>The AI/code boundary can blur sometimes. In my config table story, repetitive config tables definitely feel like script work, but considering PRs, where the script should live in the repo, unit tests, and so on, a quick prompt, or a skill in today’s AI toolbox terms, is a faster way to reach the goal.<br>Don’t write prompts, design them
The paradigm shifts from writing prompts to designing them. I don’t write prompts anymore. Instead, I tell AI what it should do, what stays in code, what the end goal is, how it should iterate, and when to call a human to judge. Then I let AI draft the prompt for me. I don’t even look too closely at the prompt. I only ask another AI to check if all behaviors meet my requirements. I then verify that the AI’s behavior is as expected, just like in programming tests. The rare time I go check the prompt is when something obviously goes wrong and seems to come from inaccurate prompt wording.<br>The loop is the product
Loop becomes the final product of our design. When you clearly define the boundaries, the loop knows its job and can run without humans most of the time. We don’t have to go 20 rounds with AI every time we create a simple config table webpage anymore. Outsource your job to AI when you can. It’s better than chatting with AI and babysitting it for every task. Chats feel good because it feels like something is moving forward. But we can always go further: design a loop so AI does it for you instead of working on it with you.
For simple tasks, zero touch is not a fantasy. When AI takes on more responsibility, check-ins are inevitable. Fortunately, it can be “touch once” for each error if we do it correctly. I observe where the prompt fails and edit it accordingly. For example, in the config table case, AI always tried to...