Prompt Engineering & Loop Engineering, Clearly Explained!  🔗 **Source:** [Prompt Engineering & Loop Engineering, Clearly Explained!](https://twitter.com/_avichawla/status/2070443217850671526/?rw_tt_thread=True) > [!note]+ Document Notes > --- > tags: [loop-engineering, ai-agents, react-pattern, agentic-workflows, autonomous-loops] > author: Avi Chawla > source: Twitter/X > reference: https://twitter.com/_avichawla/status/2070443217850671526/?rw_tt_thread=True > date created: 2026-06-26 00:00 > --- > # 🏷️ Title: Prompt engineering & loop engineering, clearly explained! > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [Avi Chawla thread (source)](https://twitter.com/_avichawla/status/2070443217850671526/?rw_tt_thread=True) > - Akshay Pachaar (@akshay_pachaar) companion thread, quoted inline — "Stop prompting your agents, start engineering loops." > - ReAct (Yao et al., 2022-23) — the reason-and-act inner-loop pattern this thread credits. > - Boris Cherny (built Claude Code) and Peter — the recent discussion both threads cite as the trigger. > - LangChain framing: "Agent = Model + Harness." > ## 📝 Summary > - What happened: Avi Chawla explains that an agent is a plain while-loop (model runs, requests tools, results return to context, repeat), that this inner loop was solved years ago by ReAct, and that the new frontier is the outer loop — the loop around the loop. Akshay Pachaar's quoted thread frames the same shift as "loop engineering" and names Boris Cherny's claim that he no longer prompts, he writes loops. > - Why it matters: It reframes where the work lives. The prompt is one small piece. The harness and the autonomous outer loop now carry more weight than the model itself. > - Key stakeholders: Agent framework builders, people running coding agents in CI, and anyone trying to take themselves out of the per-turn loop. > - Risks and tradeoffs: Removing the human from the outer loop keeps ownership but loses understanding. You also have to rebuild what the human provided — the stop decision, project memory, and an independent reviewer. > - Bottom line: The inner loop is trivial and finished. Loop engineering is everything you build around the model so it can run many turns toward a goal without you in every step. > ## 📖 Main Content > - Core claim 1: An agent is a while-loop. The model runs, requests tool calls, results return to context, the model runs again until it stops requesting tools. ReAct described this in 2022-23, so it's old news and already solved. > - Core claim 2: What's unsolved is the loop around that loop. In the common setup, you are that outer loop — you write a prompt, read the turns, write the next prompt, and repeat, catching failures as they run. > - Core claim 3: People are now trying to let the system run the outer loop too, so you can take yourself out. It starts on a schedule or event, runs many turns with no prompt between them, decides on its own when it's done, and comes back only when something needs you. > - Worked example (CI): Today you paste an error into the agent, read the fix, run tests, and paste the next failure back in — every turn goes through you. The loop version triggers on a schedule, reads the failure, drafts a fix on a branch, runs tests, feeds the next failure back as a turn until they pass or it hits a turn limit. A separate reviewer checks the fix, opens a PR if clean, flags a human if not. > - The tradeoffs aren't free: Sitting in the outer loop gave you the ability to stop, project memory, and the reviewer role. Each of those now has to exist in the system. Sitting in the loop was slow but you understood the system; taking yourself out keeps ownership but likely loses understanding. > - Three failure modes (mostly via Akshay's companion): knowing when to stop (a terminal message ends the turn, not the task — so you need real completion checks plus a turn/token cap); context rot (context grows every turn and the model degrades, so trim, summarize, offload to files, split into sub-agent runs); and the agent can't check its own work (a separate model or a deterministic/binary test must give that signal). > - Cost note: Every turn resends the whole context, so a long loop can cost many times what a single prompt would. > - Contested/uncertain: "The harness now matters more than the model" is presented as a finding ("teams kept the model fixed, changed only the code, jumped into the top five") but no benchmark is named in the excerpt — treat as a strong claim pending citation. > ### 🗒️ Notes > - The thread's center of gravity: work keeps drifting away from the model — prompt → context → harness → loop engineering, each layer wrapping the one before. > - LangChain's compression: "Agent = Model + Harness. If you're not the model, you're the harness." > - Both Avi and Akshay cite the same Boris/Peter discussion as the source. This thread overlaps heavily with the Akshay thread on the same topic — they're two takes on one conversation. > - The honest part: the piece names what you lose. Stop authority, memory, and review were free when a human sat in the loop; automating the loop means rebuilding all three. > - "Context rot" + "doom loop" framing: a rotted context produces a worse decision, which adds noise, which rots context further. > - Stop conditions stack: max iterations, budget/time limits, no-progress detection (same call, same args), and a real completion check that carries the weight. > - The excerpt cuts off mid-"Hard part 3: tools the agent can actually use" — the tools section is incomplete in the source. > ## 📚 References > - [Avi Chawla thread](https://twitter.com/_avichawla/status/2070443217850671526/?rw_tt_thread=True) > - ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) — the inner-loop ancestor. > - Akshay Pachaar (@akshay_pachaar) — quoted companion thread on loop engineering. > - LangChain — "Agent = Model + Harness" framing. > ## 🗣️ Paraphrase > - An agent is just a loop: the model thinks, asks for a tool, gets the result, and goes again until it's done asking. That part is old and settled. The interesting question is who runs the loop that wraps it — and right now that's usually you, reading turns and writing the next prompt. > - The push now is to hand that outer loop to the machine: let it run on a schedule, take many turns alone, judge its own stopping point, and only ping you when it has to. The catch is that everything you quietly provided — the brakes, the memory, the review — now has to be built, and you keep the responsibility while losing the firsthand understanding. > ## 📰 Newsletter > - Light OSS/DevRel bridge: This is the clearest short explanation of "loop engineering" worth linking in a WordPress contributor or DevRel digest — the framing (prompt → context → harness → loop) maps directly onto how teams are wiring AI coding agents into CI. The CI worked-example (trigger → read failure → fix on a branch → run tests → reviewer opens a PR) is a concrete pattern any project automating its test-fix cycle can borrow. Pair it with the maker/checker rule: the agent can't grade its own work, so a separate deterministic check has to gate "done." No direct WordPress plugin hook here, but the autonomous-loop-plus-independent-reviewer shape is exactly the discipline a Core or Meta automation should adopt before it ships. > ## ✅ Action Items > #### DevRel > - Developer advocacy: Use the prompt → context → harness → loop ladder as a talk/demo spine; it's a clean mental model for explaining where agent work actually lives. > - Education: Build a workshop around the CI worked-example — turn the human-in-every-turn flow into an autonomous loop with a separate reviewer. > - Developer experience: Document the four stop conditions (max iterations, budget/time, no-progress detection, real completion check) as a reusable checklist. Prompt engineering & loop engineering, clearly explained! At its core, an agent is a while loop: * The model runs * It requests tool calls * The tool results return to the context * The model runs again until it stops requesting tools ReAct described this form of loop back in 2022-23, and almost every agent/framework runs a similar implementation of this. So loops aren't a new thing at all, and the above implementation of loops was solved a long time ago. What wasn't solved is the loop around the above loop, and this is what Boris/Peter talked about recently. In the most common setup, you are the loop around the loop. * You write a prompt * Read the turns the agent runs * Write the next prompt * And repeat, catching failures as it runs Now there are attempts to let the system run the outer loop too, so that you can eliminate yourself. * It starts on a schedule or an event * It runs for many turns with no prompt in between * It decides on its own when it's done * It comes back only when something needs you Consider a failing test in CI to understand this. In the current way, you paste the error into the agent, read the fix, run the tests, and paste the next failure back in until they pass. So every turn goes through you. The loop runs those same turns on its own. It triggers on a schedule, reads the failure, drafts a fix on a branch, runs the tests, and feeds a failure back in as the next turn, until they pass or it hits a turn limit. A separate reviewer checks the fix, opens a PR if it's clean, and flags it for a human if it isn't. So the inner loop was always automatic. The part being automated now is your involvement in that loop. None of that comes for free though, as expected. > > Sitting in the outer loop gave you the flexibility to stop, possess project memory, and be the reviewer. But each of those now has to exist in the system. > > Also, while sitting in the loop was slow, you understood the system. > > But one big downside of taking yourself out is that you keep the ownership, but would likely lose the understanding. > > Inherently, a loop doesn't know when to stop on its own either. It will take the agent's word that the work is done and stop on a fix while the tests still fail, so the stop has to be a real check, plus a turn or token cap to avoid infinite loops. > > The context grows every turn, and the model gets worse as its context fills up. > > So the loop should trim it and keep summaries instead of full history, move large outputs to files, and split subtasks into separate runs. > > Lastly, the agent can't be the one to check its own work, since it will pass whatever it wrote. > > A separate model or a binary/deterministic test should provide that signal. And the cost for all this adds up fast since every turn sends the whole context again, so a long loop can spend many times what a single prompt would. If you want to dive deeper, my co-founder wrote a full breakdown, from the loop above to a run that finishes on its own, with the code behind each part. Read it below. Your browser does not support the video tag.  [Akshay 🚀](https://twitter.com/akshay_pachaar) [@akshay\_pachaar](https://twitter.com/akshay_pachaar)  Half your feed is suddenly saying the same thing. Stop prompting your agents, start engineering loops. Boris Cherny, the person who built Claude Code, said it plainly: "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." The person who builds one of the most popular coding agents on earth doesn't prompt it. So what is he doing instead? That's the whole idea behind loop engineering. Now let's break down why it's harder than it looks. ### First, the loop itself An agent isn't a magic box. At its core, it's a plain loop: Some content could not be imported from the original document. [View content ↗](https://twitter.com/_avichawla/status/2070443217850671526/?rw_tt_thread=True) The model reads the context. It asks to call a tool. You run the tool and feed the result back. The model reads again, and this repeats until it stops asking for tools. **Model → tools → context → repeat.** Here's the part that surprises people. **This loop is already solved.** Every serious agent framework lands on roughly these six lines. Nobody is competing on the while statement. So if the loop is trivial, what is everyone actually engineering? ### The work moved outside the model The center of gravity in AI keeps drifting away from the model itself. * **Prompt engineering.** The words you send. * **Context engineering.** Everything the model sees, not just your instructions. * **Harness engineering.** The code around the model that runs tools, tracks state, and handles errors. * **Loop engineering.** The autonomous cycle that drives the whole thing toward a goal. Each layer wraps the one before it. You didn't stop caring about prompts. You just realized the prompt is one small piece of a much bigger system. LangChain puts it cleanly. **Agent = Model + Harness. If you're not the model, you're the harness.** And here's the finding that should reorder your priorities. **The harness now matters more than the model.** Teams have kept the model fixed, changed only the code around it, and jumped from the middle of a benchmark into the top five. Same brain, different loop. Loop engineering is the discipline of building everything that brain runs inside. Let me show you the parts that actually break. ### Hard part 1: knowing when to stop This is the problem nobody warns you about. When an agent stops asking for tools, it has ended its turn. That is not the same as finishing the job. Picture a coding agent. It writes some code, glances around, sees that progress was made, and announces it's done. The tests still fail. It declared victory anyway. **A terminal message ends the turn, not the task.** Confusing those two is the most common way loops go wrong. Good loops stop for the right reasons, so you layer several brakes: * **Max iterations.** A hard cap so a stuck agent can't run forever. * **Budget and time limits.** A ceiling on tokens, money, and seconds. * **No-progress detection.** If it repeats the same call with the same arguments, it's spinning. * **A real completion check.** An automated condition proving the job is done. That last one carries the weight. "Done" should mean the tests pass, not the agent feeling good about its work. ### Hard part 2: keeping the context clean Long loops rot from the inside. The more turns an agent takes, the more junk piles into its context, like old tool outputs, dead ends, and stale reasoning. Model performance drops as that pile grows. The field calls it **context rot.** A loop makes it spiral. A rotted context produces a worse decision, which adds more noise, which rots the context further. People call this the doom loop, and you've felt it. The agent gets dumber the longer it runs. You fight it by treating context as a budget, not a bucket: * **Compaction.** Summarize the conversation when it gets long, then continue from the summary. * **Offloading.** Push huge outputs to a file and keep only the slice you need. * **Sub-agents.** Hand a messy subtask to a separate agent and let only its clean result return. The instinct is to keep everything, just in case. The skill is knowing what to throw away. ### Hard part 3: tools the agent can actually use [Posted Jun 22, 2026 at 6:00PM](https://twitter.com/akshay_pachaar/status/2069118430582866051), Prompt Engineering & Loop Engineering, Clearly Explained!, Avi Chawla, 01kw33ya1fffpq9azc0brkcjvm.