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!
>
<!-- deep-read:sections start -->
## 🧭 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.
#### OSPO
- Policy & Governance: Set a rule that autonomous agent loops in project infra require an independent completion check, not the agent's own say-so.
- Security Management: Treat scheduled, many-turn agent runs as a new attack/abuse surface; require turn/token caps and branch isolation.
- Strategic Alignment: Track the "harness matters more than the model" claim against your own benchmarks before betting roadmap on it.
#### Community
- Maintainers: Adopt the "separate reviewer opens a PR if clean, flags a human if not" pattern for any bot that drafts fixes.
- Contributors: Pair sessions on writing loops, not just prompts, for repo automation.
#### WordPress
- Core: Evaluate whether CI auto-fix loops fit any flaky-test or lint-fix workflow, gated by deterministic checks.
- Core Performance: Autonomous loops resend full context each turn — measure token cost before adopting; a long loop can cost many times a single prompt.
- Core AI: Use this as a reference framing for responsible-AI guardrails — real completion checks and turn caps as required guardrails, not nice-to-haves.
- **Core Program Team:** Add "who runs the outer loop, and what are its brakes" to any AI-automation proposal review.
- Meta: If .org adds agent-driven automation, require the separate-reviewer + caps pattern by default.
- CLI: A scriptable loop wrapper (trigger → run → check → cap) is a natural CLI scaffold candidate.
- Documentation: Capture the context-hygiene tactics (compaction, offloading to files, sub-agents) as a docs note for contributors building automations.
#### The WPCC
- Programs: Consider a maintainer clinic on loop engineering vs prompt engineering for project bots.
#### FAIR
- Technical independence: An autonomous loop needs its own memory and provenance store once the human leaves the loop — design it as a first-class artifact, not an afterthought.
## 🧪 Hypotheses
- Holding the model fixed and improving only the harness/loop produces larger benchmark gains than swapping in a stronger model.
- Autonomous loops with a deterministic completion check finish correct work more often than loops that trust the agent's self-declared "done."
- Context-trimming strategies (compaction, offloading, sub-agents) reduce the doom-loop degradation rate measurably over long runs.
- Removing the human from the outer loop increases throughput but lowers operator understanding of the system over time.
- Per-turn full-context resends make long loops cost super-linearly relative to task length.
## 📊 Methodology
- Run a fixed model across a coding-agent benchmark, varying only harness/loop code, and measure rank movement to test the harness-over-model claim.
- A/B autonomous CI loops with vs without a deterministic completion gate; measure rate of false "done" merges.
- Instrument long runs to log context size vs decision quality to quantify context rot and the effect of trimming tactics.
- Survey operators before/after loop automation to measure self-reported system understanding against ownership of outcomes.
- Log token spend per turn across loop length to model cost growth.
### ❓ Questions
- What's the right signal for "done" when no deterministic test exists for the task?
- How do you preserve project memory across many-turn runs without re-rotting the context?
- Who's accountable when an autonomous loop merges a wrong fix the reviewer model approved?
- At what loop length does cost outweigh the human-time saved?
- Can a separate reviewer model be gamed by the same failure mode as the worker model?
### 🔮 Future Research
- Standard patterns for outer-loop memory stores that survive compaction.
- Deterministic-vs-model completion checks: when each is appropriate.
- Cost-aware loop schedulers that cap spend, not just turns.
- Operator-understanding metrics for human-out-of-loop systems.
- Generalizing the CI worked-example to non-test-gated domains (docs, design, ops).
### 💡 Implications
- Practice: Teams should invest in harness and loop code, not just prompt wording.
- Policy: Autonomous loops need mandated brakes (caps) and independent checks before production use.
- Security: Scheduled many-turn agents widen the abuse surface and need isolation.
- Education: "Loop engineering" deserves its own curriculum slot distinct from prompt engineering.
- Funding models: Long loops cost real money per turn; budget governance matters.
### 🧠 Learning Styles Assessment
- Reading level estimate: Flesch-Kincaid Grade ~8–9. Short declarative sentences, concrete analogies, minimal jargon beyond named patterns (ReAct, context rot).
#### 👀 Visual learners
- Present: The "Model → tools → context → repeat" shorthand; a referenced video/diagram that "could not be imported."
- Improve: Add an architecture diagram of inner vs outer loop and a before/after of the CI flow.
#### 🔊 Aural learners
- Present: None (text thread).
- Improve: A 2–3 minute audio summary contrasting prompt vs loop engineering.
#### 🗣️ Verbal learners
- Present: Strong analogies (while-loop, doom loop, brakes) and plain definitions.
- Improve: A short glossary (ReAct, harness, context rot, compaction).
#### 🧩 Kinesthetic learners
- Present: The CI walkthrough is near step-by-step.
- Improve: A runnable repo implementing the loop and reviewer.
#### 🧠 Logical learners
- Present: Clear cause-effect chains (context grows → decisions worsen → context rots).
- Improve: A decision tree for stop conditions and a cost model.
#### 🧑🤝🧑 Social learners
- Present: Two-author dialogue (Avi quoting Akshay), shared Boris/Peter source.
- Improve: Discussion prompts on where humans should stay in the loop.
#### 🧘♀️ Solitary learners
- Present: Self-contained reasoning a reader can absorb alone.
- Improve: Reflection prompts on your own per-turn workflows.
#### 🌿 Naturalistic learners
- Present: Ecosystem-style "layers wrap layers" framing.
- Improve: Lifecycle view of a loop from trigger to teardown.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: Plain text reads linearly.
- Improve: The embedded video needs a text alternative; "some content could not be imported" leaves a gap.
#### Keyboard navigation
- Present: N/A for a text thread on a platform.
- Improve: Ensure any linked breakdown page is keyboard reachable.
#### Contrast and readability
- Present: Platform default contrast.
- Improve: Not controllable in-thread; the linked write-up should meet 4.5:1.
#### Text resizing and reflow
- Present: Thread reflows on mobile.
- Improve: Ensure code/diagrams in the linked post reflow at 200% zoom.
#### Media and captions
- Present: A video is referenced.
- Improve: Add captions and a transcript; the video tag has no described fallback.
#### Forms and interactions
- Present: N/A.
- Improve: N/A.
#### Standards reference
- Gaps map to WCAG 2.2 AA: 1.2.2 Captions, 1.2.3/1.2.5 Audio Description, 1.1.1 Non-text Content (the un-imported video content).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Technical examples are culture-neutral (CI, tests).
- Improve: Examples beyond software (ops, research) would broaden reach.
#### Inclusive language
- Present: Neutral, jargon mostly defined.
- Improve: Define ReAct and "context rot" inline for newcomers.
#### Neurodiversity support
- Present: Chunked, consistent "hard part N" structure.
- Improve: More headings and icon+text labels in the long middle.
#### Representation
- Present: Cites named practitioners (Avi, Akshay, Boris, Peter).
- Improve: Range of voices is narrow (a few practitioners); add diverse sources.
#### Psychological safety
- Present: Respectful, non-hype tone that names downsides.
- Improve: N/A.
### ✅ Logical Validity
#### Strong reasoning
- Analogical (strong): "an agent is a while loop" maps the abstraction to a familiar programming primitive and holds up through the CI example. Clarify by noting where the analogy breaks (non-determinism of the model's tool requests).
- Causal (strong): the context-rot → worse-decision → more-noise chain (Akshay section) is a clear, plausible feedback loop. Strengthen with measured degradation curves.
- Inductive (moderate): "the harness now matters more than the model" generalizes from unnamed teams jumping benchmark ranks. Cite the benchmark to firm it up.
#### Fallacies
- Appeal to authority: "Boris Cherny... said it plainly: 'I don't prompt Claude anymore.'" (Akshay section). One expert's workflow is used to anchor a general claim; weakness is that one practitioner's habit isn't evidence the pattern generalizes. Fix: pair with outcome data across teams.
- Bandwagon: "Half your feed is suddenly saying the same thing." (Akshay opener). Popularity is cited as a reason to take it seriously; weakness is consensus-as-proof. Fix: lead with the mechanism (which the thread does) rather than the feed.
- Hasty generalization: "Every serious agent framework lands on roughly these six lines." Sweeping "every/nobody" framing on the loop being solved; weakness is no survey backs "every." Fix: qualify to "most popular frameworks."
#### Tone of voice
- Explanatory, measured, lightly contrarian. Example: "None of that comes for free though, as expected" — sets up an honest accounting of tradeoffs rather than hype.
### 🛡️ DARVO Analysis
- Not applicable to this source — it's an explanatory technical thread with no accusation, denial, or victim/offender dynamic to analyze.
## 🎯 Conclusion
- Bottom line: The inner agent loop is a solved while-loop; the real engineering is the outer loop around it and everything you must rebuild — stop conditions, memory, and an independent reviewer — once you take the human out.
- Practical next steps: When automating a loop, layer real stop conditions (caps + deterministic completion check), keep context lean (compaction, offloading, sub-agents), and never let the agent grade its own work — wire in a separate checker. This is the maker/checker discipline applied to agent loops.
## 🔄 Refactor Appendix — Prompt engineering & loop engineering, clearly explained!
> Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4).
> Defaults: 3 Literature, 1 Permanent.
### 📚 Literature Atoms (H3)
#### [H1] An agent is a while loop solved by ReAct
> [!quote] ID:rw_h1
> At its core, an agent is a while loop... ReAct described this form of loop back in 2022-23, and almost every agent/framework runs a similar implementation of this.
**Context & use**:
- Opening of the thread.
- Establishes the inner loop as old and settled, setting up the outer-loop pivot.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
#### [H2] The unsolved part is the loop around the loop
> [!quote] ID:rw_h2
> What wasn't solved is the loop around the above loop, and this is what Boris/Peter talked about recently.
**Context & use**:
- The pivot of the whole thread.
- Names Boris/Peter as the shared source both Avi and Akshay cite.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
#### [H3] In the common setup you are the outer loop
> [!quote] ID:rw_h3
> In the most common setup, you are the loop around the loop.
**Context & use**:
- Frames the human as the current outer loop: write prompt, read turns, write next prompt, repeat.
- The thing loop engineering tries to automate away.
**Tags**: #xref #aphorisms
<!-- atomicity: 1 idea ✓ -->
#### [H4] Taking yourself out keeps ownership but loses understanding
> [!quote] ID:rw_h4
> But one big downside of taking yourself out is that you keep the ownership, but would likely lose the understanding.
**Context & use**:
- The core tradeoff of automating the outer loop.
- Directly relevant to Courtney's loop-engineering OS: who understands the fleet once humans leave the loop.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
#### [H5] The agent can't check its own work
> [!quote] ID:rw_h5
> Lastly, the agent can't be the one to check its own work, since it will pass whatever it wrote.
**Context & use**:
- The maker/checker rule stated plainly — a separate model or deterministic test must give the signal.
- Direct evidence for the maker/checker discipline in the loop-engineering OS.
**Tags**: #xref #aphorisms
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] A loop needs an external stop signal because the maker can't judge its own done
**Claim** (one sentence, Courtney's voice): An autonomous loop only stops correctly when a checker outside the worker — a deterministic test or a separate model — decides "done," because the worker passes whatever it wrote.
**Evidence pointer**: [[#H5]]
**Scope & conditions**: Holds wherever an agent both produces and self-evaluates work; breaks only when the task has no verifiable completion condition at all.
**Links**:
- [[Loop-engineering OS]] — because applies-in the maker/checker fleet
- [[ReAct inner loop]] — because contrasts on inner (solved) vs outer (open) loop
- [[Context rot]] — because evidence-for why long loops degrade
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Reconcile this thread with the Akshay thread — same Boris/Peter source, two write-ups; consider one merged literature note. #fleeting #inbox
- [F2] Source excerpt cuts off at "Hard part 3: tools the agent can actually use" — fetch the full Akshay breakdown to complete the tools section. #fleeting #inbox
### → Things 3 (max 2 actions)
- [ ] Map the four stop conditions onto the loop-registry checker rows — context loop-engineering OS #things
- [ ] Pull the full Akshay companion thread to capture "Hard part 3" before finalizing — context readwise #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Tweets/Prompt Engineering & Loop Engineering, Clearly Explained!.md|Prompt Engineering & Loop Engineering, Clearly Explained! by Avi Chawla]]
## Highlights
- ReAct described this form of loop back in 2022-23, and almost every agent/framework runs a similar implementation of this. ([View Highlight](https://read.readwise.io/read/01kw3drapfp3a91r98g0fsza19))
- Note: The inner agent loop isn't new — ReAct described it in 2022-23.
- Tags: atom/literature/h2
- What wasn't solved is the loop around the above loop, and this is what Boris/Peter talked about recently. ([View Highlight](https://read.readwise.io/read/01kw3drcve3rphxdywat3mycnj))
- Note: The unsolved part: the outer loop (the loop around the loop) — what Boris/Peter mean by loop engineering.
- Tags: atom/literature/h1
- In the most common setup, you are the loop around the loop. ([View Highlight](https://read.readwise.io/read/01kw3dre06s8ap7p1jcebmfy2n))
- Note: Today the human IS the outer loop: write prompt, read turns, write next prompt, repeat.
- Tags: atom/literature/h1
- But one big downside of taking yourself out is that you keep the ownership, but would likely lose the understanding. ([View Highlight](https://read.readwise.io/read/01kw3drfpswv2e7g33kd6jwj9c))
- Note: Tradeoff of full automation: keep ownership, lose understanding.
- Tags: atom/zettel/z1
- Lastly, the agent can't be the one to check its own work, since it will pass whatever it wrote. ([View Highlight](https://read.readwise.io/read/01kw3drh8qswp1a2j8nmx7x4w4))
- Note: Independent-checker rule again: the agent can't grade itself — it'll pass whatever it wrote. (Converges with the h100envy "self-assessment is an echo" claim.)
- Tags: atom/literature/h1