I Guess We're Writing Loops Now?  🔗 **Source:** [I Guess We're Writing Loops Now?](https://www.youtube.com/watch?v=iJVJwmCKW9o#transcript) > [!note]+ Document Notes > tags: [loop-engineering, ai-agents, agentic-coding, developer-workflow, autonomous-agents, token-economics] > author: Theo Browne > source: Theo - t3.gg (YouTube) > reference: https://www.youtube.com/watch?v=iJVJwmCKW9o > date created: 2026-06-19 09:30 > > # 🏷️ Title: I guess we're writing loops now? > <!-- 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 - [Theo - t3.gg (YouTube channel)](https://www.youtube.com/@t3dotgg) - [Pete Koomen / "writing loops" discourse on X](https://x.com) - [Anthropic — recursive self-improvement post](https://www.anthropic.com) - [Magic Patterns (sponsor)](https://soy.link/magicpatterns) - [Loop Engineering (The New Stack)](<obsidian wiki note — cross-reference>) - [The Maker Should Not Grade Its Own Homework (Permanent note)](<obsidian wiki note — cross-reference>) ## 📝 Summary - **What happened.** Theo Browne (t3.gg) reacts to the "you should be designing loops, not prompting agents" discourse seeded by Pete (Koomen) and amplified by figures like Boris Cherny and Addy Osmani. Initially skeptical — the Ralph loop "massively increased the error rate" — he describes converting himself by actually building looping setups: agents that monitor PRs, spin up review threads, address feedback, re-review, merge, and trigger the next stacked PR. The headline anecdote: he asked Codex/Claude to *build a workflow that builds loops*, set it off at 2:29 a.m., and woke to "four stacked PRs reviewed to hell and back all merged." - **Why it matters.** This is a working developer's field report on loop engineering, not a manifesto. It validates the core "design the loop" thesis while puncturing the most extreme claims (fully autonomous, no-oversight code generation is "stupid"). It also surfaces the real binding constraint: token cost and rate limits, not capability. - **Key stakeholders.** Solo developers and small teams on $200 subscription plans; agent-harness vendors (Claude Code, Codex, Cursor, his own T3 Chat/T3 Code); code-review tools (CodeRabbit, Reptile, Macroscope); and the broader "agentic coding" discourse crowd. - **Risks and tradeoffs.** Loops burn 5–10x more tokens and can run *eight hours / three million tokens* to fix three small comments; a wrong path runs longer before correction; not safe for "real production codebases that have millions of users… at least not yet." Subscription pricing (not API pricing) is the only thing that makes it economical. - **Bottom line.** Pay attention to what *you* do after the agent finishes — running, verifying, committing, pushing, collecting review comments, fixing — and prompt yourself out of each step. The distinctive value isn't autonomy; it's *dynamically shaped* loops that fit the problem instead of forcing work into a static agile-sprint shape. ## 📖 Main Content - **The conversion arc.** Theo opens contrarian — "this memo didn't make it to me" — and recounts that earlier loop experiments (the Ralph loop) were "really cool, but they didn't seem that productive" because error rates climbed. He was the loop: manually shuttling context from plan → build → review → fix. Over the video he concedes Pete was right, but adds his own qualifier: "the majority of your agent runs should probably not be running with prompts that you wrote." - **The recursive-self-improvement frame.** He borrows Anthropic's framing of how the human↔model loop tightened over time: human-copies-paste-from-chatbot → IDE/terminal editing directly → workflows and sub-agents → agents that audit their own work and re-run. He places himself one notch short of full autonomy: "I am not at the fully autonomous loop point yet." - **Against pre-defined personas.** A distinctive contrarian thread: he mocks the practice of hardcoding adversarial-reviewer / security-reviewer / explorer "personas" in markdown skills as missing the point — agents are *dynamic* and should build the context they need on the fly. He likens pre-built persona scaffolds to a project template where every file already exists and you just edit them: "It's stupid." - **The build-up of looping.** He describes concrete steps: a big refactor PR where Opus chose its own sub-agent breakdown; telling the agent to *monitor the PR for comments* from review bots and address them (running 6+ hours); having Claude run Codex for feedback then fix it; using HTML plans (credited to "Thoric") he can read on his phone. - **The loop that builds loops.** The pivotal prompt asked whether a workflow could (1) spin a thread to make the PR, (2) spin another to review it, (3) loop the first on review comments until approvals, (4) merge and trigger the next piece. The agent built a heartbeat-polling workflow (every 5–10 min) and executed it overnight across four stacked PRs. His framing: "I asked the model if I could make this loop and it made a loop that makes sub loops dynamically." - **The dynamic-shape thesis (his real addition).** He contrasts this with the "agile waterfally" sprint structure where "we kind of had to force our work to fit that shape." The cool part is that "the shape of the loop… can be dynamically generated based on the shape of the work that you're doing." This is the developer-practitioner's distinctive contribution to the discourse. - **The "looking at the code too early" claim.** His spiciest take: "If you are reading the code your agent put out before another agent read it and gave feedback on it, you're wasting your own time." Let agents catch the obvious errors first; the human comes in for the hard stuff. - **The cost reality.** The honest counterweight: loops burn tokens hard. One example ran 8 hours / 3M+ tokens to address three small comments. "If you're paying API prices, you probably shouldn't be doing loops yet." On a $200 plan, though, he's at 29% of a weekly limit; he reframes unused limit as "thousands of dollars of inference… that I could have done that I didn't do" — treat limits as challenges to max out. His June usage: ~$6k on one machine, ~$10k across machines, on three $200 plans. - **Cross-reference — loop engineering.** This is the same "write loops" discourse covered in **[[Loop Engineering (The New Stack)]]**. Theo's contribution is empirical and skeptical: he confirms the productivity claim *only* under subscription economics and *rejects* the no-oversight version Boris-style advocates push. - **Cross-reference — maker/checker.** His "another agent must read the code before you do" workflow is a live instance of the maker/checker split in **[[The Maker Should Not Grade Its Own Homework]]** — but note the tension: his reviewer agents are *spun up by the same orchestrator* that ran the maker. Whether that satisfies "a checker never re-reads the maker's draft, it re-derives from source" is contestable; his loops re-derive from the PR diff and external review bots, which leans toward genuine independence. ### 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=0) Opening skepticism - "Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." - Ralph loop helped him think about agents doing more over time, but "massively increased the error rate." - He *was* the loop — manual handholding from part one to part two. #### ⏱️ [00:01:04](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=64) Conceding Pete was right - After building with loops himself, he accepts the thesis but adds: "the majority of your agent runs should probably not be running with prompts that you wrote." - Frames Pete as an "experimental figure… figuring out what the future looks like in a weird jank duct tape version." #### ⏱️ [00:04:50](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=290) Recursive self-improvement framing - Borrows Anthropic's account of the tightening human↔model loop: copy-paste → IDE editing → workflows/sub-agents → self-auditing re-runs. #### ⏱️ [00:05:56](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=356) Against hardcoded personas - Mocks predefined adversarial/security/explorer personas: "that made no [expletive] sense… The idea of predefining personas to go do things in your codebase fundamentally misses the cool part of agents." - Agents are dynamic; pre-building context is "stupid." #### ⏱️ [00:07:35](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=455) Not fully autonomous — and that's deliberate - "I am not claiming the same things people like Boris are claiming where they're writing the loop and now the code is just happening by itself with no oversight. That is stupid." - Monitors PR for review-bot comments; agent ran 6+ hours making improvements. #### ⏱️ [00:11:55](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=715) The loop that builds loops - The single most impactful prompt: a workflow that spins PR thread → review thread → comment-fix loop until approvals → merge → trigger next. - Heartbeat polling every 5–10 min; ran Sunday 2:29 a.m., "broke everything in my editor pretty aggressively at 6:50 a.m." - Woke to "four stacked PRs reviewed to hell and back all merged. It was [expletive] awesome." #### ⏱️ [00:14:38](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=878) Dynamic shape vs. agile waterfall - Traditional agile forced work into a static shape; "the most productive teams… build their own alternative shape around the problems." - "The shape of the loop… can be dynamically generated based on the shape of the work that you're doing." #### ⏱️ [00:16:50](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=1010) Prompt yourself out of every post-build step - Run dev server → verify → commit → push → file PR → collect review → fix → merge: tell the agent to do each. - "We are looking at the code too early… you're wasting your own time." #### ⏱️ [00:18:30](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=1110) Cost is the catch - "You will burn many more tokens." API prices → don't loop yet. - 8-hour / 3M-token run to fix three small comments. #### ⏱️ [00:20:43](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=1243) Subscription economics - ~29% of weekly limit on $200 plan despite five concurrent loops; treat limits as challenges to max out. - /goal primitive (linear never-ending loop) vs. dynamic workflow distinction; 12-hour Hermes-in-Rust goal running. - June usage ~$10k across machines on three $200 plans — "shitload of value… given relatively cheaply." #### ⏱️ [00:24:02](https://www.youtube.com/watch?v=iJVJwmCKW9o&t=1442) Closing - "Ask your agent to do the next step and see if it impresses you." ## 📚 References - [Theo - t3.gg](https://www.youtube.com/@t3dotgg) — channel - [Pete Koomen "writing loops" thread](https://x.com) — the post that "started this new era of looping discourse" - [Anthropic — recursive self-improvement essay](https://www.anthropic.com) — the loop-tightening framing he cites - [Magic Patterns](https://soy.link/magicpatterns) — sponsor (AI front-end design tool) - [CodeRabbit](https://coderabbit.ai) — one of the review bots watching his PRs - [T3 Chat / T3 Code](https://t3.chat) — his own products ## 🗣️ Paraphrase - Theo starts skeptical of the "design loops, stop prompting" memo but, after building looping setups himself, concedes it's right — and goes further, arguing most agent runs shouldn't use prompts you personally wrote. - He frames the shift via Anthropic's recursive-self-improvement story: the human↔model loop has steadily tightened from copy-paste to self-auditing agents. - He rejects hardcoded reviewer "personas" as missing what makes agents valuable — their ability to build context dynamically. - His breakthrough was asking an agent to build a workflow that itself spins up PR, review, fix, merge, and next-piece sub-loops; it ran overnight and merged four stacked PRs. - His real conceptual addition: the *shape* of the loop can be generated to fit the work, unlike static agile sprints that force work into a fixed shape. - He insists this isn't full autonomy — no-oversight code generation is "stupid" — and that the binding constraint is token cost, survivable only on subscription plans, not API pricing. ## 📰 Newsletter **"I guess we're writing loops now?" — Theo's field report on loop engineering** If you've been side-eyeing the "stop prompting, start designing loops" discourse, Theo Browne (t3.gg) is the skeptic who went and tried it. His verdict: the hype is mostly right, the most extreme version ("write the loop, walk away, ship to prod") is "stupid," and the real catch nobody leads with is *cost*. The fun centerpiece — he asked his agent to build a workflow that builds loops, kicked it off at 2:29 a.m., and woke to four stacked PRs reviewed and merged. The transferable lesson is gentle and practical: watch what *you* do after the agent finishes (run, verify, commit, push, collect review comments, fix), and prompt yourself out of each step one at a time. His sharpest line for WordPress and any team shop: "we are looking at the code too early" — let a second agent review before a human burns attention on obvious mistakes. This pairs directly with the maker/checker rule (a maker shouldn't grade its own homework) and the broader loop-engineering thread — Theo's contribution is the empirical, opinionated, subscription-economics-aware version. Bonus: his "loops should be shaped like the work, not forced into agile sprints" framing is genuinely useful. Just don't run it on your million-user production site yet. ## ✅ Action Items #### DevRel - Developer advocacy: build a talk/demo on "prompt yourself out of the post-build checklist" using a real PR-monitor loop. - Education: workshop comparing /goal linear loops vs. dynamic workflow-of-loops, with cost guardrails. - Developer experience: ship a reference "PR-watch → review → fix → merge → next" workflow template and document the heartbeat-polling pattern. - Developer marketing: clip the "loop that builds loops" anecdote and the "looking at the code too early" line as evergreen content. - Community management: host a discussion on when *not* to loop (production, API-price accounts). - Internal/external/cross-project: share dynamic-loop patterns and connect them explicitly to maker/checker discipline. #### OSPO - Policy & Governance: contribution policy for autonomously merged AI PRs (review-bot gating, human sign-off thresholds). - License Compliance: provenance review for code produced by long unattended loop runs. - Security Management: guardrails for agents with merge rights; embargo/secret-handling in autonomous loops. - Software Inventory: track which loops touch which repos/work-trees as part of the SBOM/ownership picture. - Developer Support: consultation on subscription vs. API economics for agentic CI. - Community Engagement: fund a "when not to loop" rubric for maintainers. - Strategic Alignment: KPI for token cost per merged change. #### Community - Maintainers: release-hygiene rules for AI-authored stacked PRs (review depth, rollback plans). - Contributors: onboarding note on dynamic workflows vs. hardcoded persona scaffolds. - Sponsors: Not applicable to this source. - Ecosystem: coordinate shared review-bot conventions (CodeRabbit-style) for autonomous loops. #### WordPress - Core: Not directly applicable — no WordPress-specific content in this source. - Core Performance: Not applicable to this source. - Core AI: document the "apply loops with oversight, not full autonomy" stance for contributor tooling guidance. - **Core Program Team:** consider cross-team norms for AI-assisted PR review loops. - Mobile / Playground / Photos / TV / Openverse / Tide / Themes / Plugins: Not applicable to this source. - Community: meetup talk on agentic coding loops for plugin/theme devs. - Training: lesson on maker/checker discipline using Theo's PR-review-loop as a worked example. - Marketing: Not applicable to this source. - Support: Not applicable to this source. - Design: Not applicable to this source (sponsor segment touches AI design but is ad content). - Documentation: examples-first guide to building a PR-watch loop safely. - Polyglots: glossary for "loop engineering," "work tree," "/goal primitive," "heartbeat polling." - Accessibility: ensure agent-authored UI code is checked against WCAG in the review loop. - Meta: Not applicable to this source. - CLI: Not applicable to this source. - Hosting: Not applicable to this source. #### The WPCC - Programs: Not applicable to this source. - Projects: documentation sprint on safe autonomous-loop patterns. - Funding experiments: Not applicable to this source. ### FAIR - Technical independence: Not applicable to this source. - Policies and covenants: governance covenant for autonomously merged code. - Productized governance artifacts: a "when to loop / when not to loop" scorecard. ## 🧪 Hypotheses - H1: Dynamically generated workflows-of-loops produce lower change-error rates than the fixed Ralph-loop pattern for multi-PR work. - H2: Loop-based agentic development is economical only under flat-rate subscription pricing; at metered API prices the token burn makes it net-negative for most tasks. - H3: Requiring a second agent to review code before any human reads it reduces total human review time without increasing defect escape rate. - H4: Dynamically shaped loops (fit to the work) outperform static agile-sprint structures on throughput for decomposable refactors. - H5: Hardcoded persona sub-agents perform no better — or worse — than letting the orchestrator build context dynamically. - H6: Autonomous merge loops are unsafe (higher incident rate) on high-traffic production codebases relative to low-stakes/side projects. ### 📊 Methodology - H1/H4: controlled comparison across matched multi-PR tasks (Ralph loop vs. dynamic workflow vs. static sprint), measuring error rate, rework, and wall-clock. - H2: cost-instrumented runs logging tokens-per-merged-change at API vs. subscription pricing; break-even analysis. - H3: A/B on review order (agent-first vs. human-first), tracking human minutes and escaped defects. - H5: benchmark persona-scaffolded vs. dynamic-orchestrator agents on identical codebases. - H6: incident-rate tracking for autonomous-merge loops segmented by codebase traffic/criticality. ### ❓ Questions - Does an orchestrator spinning up its own reviewer threads genuinely satisfy maker/checker independence, or is it the maker grading its own homework with extra steps? - At what task complexity does loop overhead (tokens, time) stop paying for itself? - How do you bound a loop that "goes down the wrong path for longer to burn more tokens"? - What's the real defect-escape rate of overnight autonomous merges on non-toy projects? - Will subscription economics survive once providers price loop-heavy usage realistically? ### 🔮 Future Research - Empirical defect-escape and cost curves for dynamic workflows-of-loops vs. linear /goal loops. - A formal "independence test" for whether co-spawned reviewer agents count as a real checker. - Tooling for cost/time circuit-breakers on runaway loops. - Study of dynamic-shape workflows vs. agile sprints on team (not solo) throughput. ### 💡 Implications - **Practice:** Shift attention from prompt-craft to designing the post-build loop; let agents review before humans look. - **Policy:** Autonomous-merge rights demand explicit governance (gating, rollback, human sign-off thresholds). - **Security:** Long unattended loops with merge access widen the blast radius of a wrong path; secrets handling and guardrails matter more. - **Education:** Curricula should teach loop/workflow design and maker/checker discipline, not just prompting. - **Funding models:** Subscription vs. API pricing is now a first-order strategic variable for agentic dev economics. ### 🧠 Learning Styles Assessment - Reading level estimate: spoken-monologue transcript; Flesch–Kincaid Grade ~8–10, Flesch Reading Ease ~60–70. Casual, profane, jargon-dense ("work tree," "/goal primitive," "stacked PRs," "heartbeat polling"). #### 👀 Visual learners - Present: he references a "kind of broken diagram" the agent produced and HTML plans, but the transcript itself has no visuals. - Improve: a workflow diagram of the loop-that-builds-loops; a before/after timeline of the overnight run; a token-cost chart. #### 🔊 Aural learners - Present: strong — it's a narrated video with a clear conversational voice. - Improve: a 3-minute audio recap; chapter markers. #### 🗣️ Verbal learners - Present: vivid analogies ("movers and packers" isn't here, but "duct tape version," "race to the bottom" energy, "looking at the code too early"). - Improve: a glossary callout (work tree, /goal, dynamic workflow, heartbeat). #### 🧩 Kinesthetic learners - Present: implicit "go try it yourself" framing throughout. - Improve: a step-by-step lab to build a PR-watch loop on a throwaway repo with a cost cap. #### 🧠 Logical learners - Present: clear cause→effect (manual handholding → dynamic loops → freed human attention) and a cost tradeoff model. - Improve: a decision tree for "should I loop this?"; an error-budget/cost-budget table. #### 🧑‍🤝‍🧑 Social learners - Present: direct address ("let me know how it goes"), discourse-reactive format referencing Pete/Boris. - Improve: discussion prompts for dev peer groups on autonomy thresholds. #### 🧘‍♀️ Solitary learners - Present: reflective "pay attention to what you do next" self-observation prompt. - Improve: a journaling worksheet to log post-build steps and which to automate. #### 🌿 Naturalistic learners - Present: none — no ecosystem/sustainability framing. - Improve: tie token burn to compute/energy cost; lifecycle thinking on runaway loops. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: YouTube provides a title and auto/manual captions; transcript is structured by timestamp. - Improve: ensure human-corrected captions (transcript has [music]/garbled tokens); descriptive chapter titles. #### Keyboard navigation - Present: YouTube player is keyboard-operable by default. - Improve: verify any embedded demo links have visible focus and labels. #### Contrast and readability - Present: standard YouTube UI meets contrast norms. - Improve: ensure on-screen code/diagram segments meet 4.5:1 and are large enough to read on mobile. #### Text resizing and reflow - Present: captions scale with player settings. - Improve: confirm on-screen terminal/code text reflows or is narrated, not just shown. #### Media and captions - Present: captions/transcript available (WCAG 1.2.1, 1.2.2). - Improve: add audio descriptions for the on-screen diagrams and editor breakage he references; downloadable transcript. #### Forms and interactions - Present: Not applicable — no forms in the video. - Improve: sponsor link/CTA should have accessible label text. #### Standards reference - Maps to WCAG 2.2 AA: 1.2.1 Audio-only/Video-only, 1.2.2 Captions (verify accuracy), 1.2.5 Audio Description (gap — on-screen diagrams not narrated), 1.4.3 Contrast, 2.4.6 Headings/labels. ### 🌍 DEIB Assessment #### Cultural breadth - Present: minimal — single US-based creator, niche dev-culture references. - Improve: acknowledge non-subscription / lower-budget contexts where this economics doesn't apply (Global South, hobbyists, students). #### Inclusive language - Present: casual but frequent profanity (bleeped); jargon largely unexplained. - Improve: define terms inline; offer a non-profane summary for broader/professional audiences. #### Neurodiversity support - Present: long, fast, tangent-heavy monologue with few signposts. - Improve: chapter markers, chunked summaries, and a written outline reduce working-memory load. #### Representation - Present: one voice; name-drops peers (Pete, Boris, Thoric) — all industry insiders. - Improve: include perspectives from devs who can't afford $200×3 plans or who work under enterprise/API constraints. #### Psychological safety - Present: encouraging "try it and see if it impresses you" tone; honest about failures and breakage. - Improve: temper the "you're wasting your own time" framing, which may shame more cautious reviewers; add explicit "when not to loop" guidance for risk-averse contexts. ### ✅ Logical Validity #### Strong reasoning - **Inductive (personal experiment → recommendation):** he generalizes from hands-on runs ("I've shipped a lot of code using these types of loops"). Strong as lived evidence; clarify by reporting defect/rework rates, not just vibes. - **Causal (manual handholding → freed attention):** well-mechanized — automating each post-build step removes a human bottleneck. Clarify with measured time saved. - **Analogical (recursive self-improvement / loop-tightening):** the Anthropic framing is apt and clarifying for how the human role recedes step by step. - **Concession-based credibility:** he explicitly bounds his claim ("not fully autonomous," "not on million-user prod"), which strengthens the rest of the argument. #### Fallacies - **Hasty generalization** — *Quote:* "If you are reading the code your agent put out before another agent read it and gave feedback on it, you're wasting your own time." *Location:* [16:50–17:58]. *Weakness:* generalizes from his low-stakes/side-project context to all reviewing; ignores domains where early human review prevents costly direction errors. *Fix:* scope to non-critical work and tasks where a review bot reliably catches the obvious class of errors. - **Sunk-cost / inverted-waste framing** — *Quote:* "that's just money you're losing if you're not… thousands of dollars of inference… that I could have done that I didn't do." *Location:* [22:22–22:54]. *Weakness:* treats unused prepaid capacity as a loss to be "recovered" by manufacturing work, which can incentivize low-value token burn. *Fix:* judge loops by value delivered, not by limit utilization. - **Anecdotal evidence** — *Quote:* "I woke up the next day with four stacked PRs reviewed to hell and back all merged. It was [expletive] awesome." *Location:* [13:31–14:04]. *Weakness:* a single vivid success; no base rate of failed overnight runs. *Fix:* report success/failure ratio and rollback frequency. - **Appeal to novelty** — *Quote:* "the idea of letting agents do more is unbelievably powerful." *Location:* [24:35]. *Weakness:* power/novelty asserted as virtue without cost-benefit bound. *Fix:* pair with the cost and risk caveats he raises elsewhere. #### Tone of voice - Opinionated, contrarian, profane, enthusiastic-but-self-aware. Swings from skeptic ("this memo didn't make it to me") to convert ("Pete's right") while keeping guardrails ("That is stupid" about no-oversight autonomy). Confessional about cost and breakage, which reads as candor rather than salesmanship. ### 🛡️ DARVO Analysis - Deny: Not applicable — there is no accusation being deflected. He openly admits failures (broke his editor, 3M tokens for three comments). - Attack: Mild rhetorical jabs at the "hardcoded persona" crowd and at Boris-style no-oversight claims ("that is stupid"), but these are critiques of ideas, not attacks on accusers undermining credibility. - Reverse victim/offender: Not applicable — no victimhood reframing present. - Overall: DARVO does not apply. The closest emotional rhetoric is the "you're wasting your time" provocation, which is a persuasion tactic, not a defensive maneuver. ## 🎯 Conclusion - **Bottom line.** Theo confirms the loop-engineering thesis from the practitioner's chair while refusing its maximalist form: design loops, let agents review before you do, and let the loop's *shape* match the work — but keep a human in the loop, stay off million-user production, and respect that token cost (survivable only on subscription plans) is the real constraint. His standout move is the loop that dynamically builds sub-loops; his standout caution is that limits, not capability, gate the practice. - **Next steps for readers.** (1) Log what you do after each agent finishes and automate one step at a time. (2) Insert an agent reviewer before your own review (maker/checker — but verify the reviewer re-derives from the diff, not the maker's narration). (3) Cap loops with token/time circuit-breakers. (4) Only run autonomous-merge loops on low-stakes repos until defect-escape data exists. (5) Treat subscription-vs-API pricing as a deliberate economic choice, not an afterthought. ## 🔄 Refactor Appendix — I guess we're writing loops now? > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults applied. Resonance filter on. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Design loops that build loops, dynamically shaped to the work > [!quote] ID:rw_pending > "I asked the model if I could make this loop and it made a loop that makes sub loops dynamically." **Context & use**: - [13:31–14:04] The overnight run that merged four stacked PRs. - The distinctive addition vs. existing loop-engineering notes: the *shape* of the loop is generated to fit the work, not forced into a static sprint. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H2] Let an agent review code before any human reads it > [!quote] ID:rw_pending > "If you are reading the code your agent put out before another agent read it and gave feedback on it, you're wasting your own time." **Context & use**: - [16:50–17:58] Reserve human attention for hard problems after agents clear obvious errors. - Live instance of maker/checker — but note the independence caveat (reviewer co-spawned by the orchestrator). **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H3] Token cost, not capability, is the binding constraint on loops > [!quote] ID:rw_pending > "If you're paying API prices, you probably shouldn't be doing loops yet." **Context & use**: - [18:30–19:03] 8-hour / 3M-token run to fix three small comments; survivable only on $200 subscription plans. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### [H4] Reject no-oversight autonomy; keep a human gate > [!quote] ID:rw_pending > "I am not claiming the same things people like Boris are claiming where they're writing the loop and now the code is just happening by itself with no oversight. That is stupid." **Context & use**: - [07:35] The skeptic's bound on the loop-engineering hype; not for million-user production "at least not yet." **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A loop's structure should be generated from the work's structure **Claim** (one sentence, Courtney's voice): The most effective agentic workflows let the agent generate the loop's shape from the specific problem rather than forcing the work into a pre-built, static process template. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for decomposable, multi-stage engineering work with reliable review feedback. Breaks where the work is small/atomic (loop overhead dominates) or where regulatory/production risk demands fixed, auditable process. **Links**: - [[Loop Engineering (The New Stack)]] — because extends - [[The Maker Should Not Grade Its Own Homework]] — because contrasts on reviewer independence - [[Agile sprint structure]] — because contrasts on static vs. dynamic process shape <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Resolve the tension: does an orchestrator-spawned reviewer thread satisfy maker/checker independence, or is it the maker grading its own homework? — connect to [[The Maker Should Not Grade Its Own Homework]] #fleeting #inbox - [F2] Open question: what token/time circuit-breaker design bounds a loop that "goes down the wrong path for longer"? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Add Theo's "review before you read" + dynamic-loop-shape take to the loop-engineering note as a practitioner cross-reference — #things - [ ] Draft a "when not to loop" rubric (production risk + API pricing) for the loop registry — #things ``` Processed: I guess we're writing loops now? (Theo - t3.gg) - Literature atoms: 4 / 5 cap - Permanent candidates: 1 / 3 cap - Fleeting items: 2 - Things 3 actions: 2 / 2 cap - Konik tags used: #xref, #addendum, #aphorisms, #articleseed - Triage callouts populated: n/a (Refactor Appendix emit form) - Quality gates: verbatim quotes ✓ | atomicity markers ✓ | link annotations ✓ | no [MISSING] ✓ | xref to existing notes ✓ - Override conditions triggered: 4 Literature atoms (4th is the distinctive skeptic bound — load-bearing for the cross-reference) ``` <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/I Guess We're Writing Loops Now.md|I Guess We're Writing Loops Now? by Theo - t3.gg]] ## Highlights - not claiming the same things people like Boris are claiming where they're writing the loop and now the code is just happening by itself with no oversight. That is stupid. But I wanted a taste. I wanted to get an idea of how this could work so I could play with it myself and see what benefits exist. So I started to play a bit. I started to do stuff like this. I had Claude Code spin up a PR for a pretty big refactor. I used sub agents a bunch to go address specific concerns and take over specific parts of the ([View Highlight](https://read.readwise.io/read/01kvga76vhqya6kxwt48cxsdqg)) - Note: H4 — the skeptic's bound on the Boris/Osmani loop hype: unattended "code happens by itself with no oversight" is "stupid." - Tags: loop-engineering, atom/literature/h4 - requests that need their own reviews and cycles and loops because that's the craziest thing here. I asked the model if I could make this loop and it made a loop that makes sub loops dynamically. This isn't a hard-coded every time I make a change I spin up one reviewer that reviews it and then they go back and forth. This is a dynamic workflow that was created based on the specific needs of this specific problem I was solving. My loops created loops and they did a great job at it. This was real code that landed and sadly I couldn't ([View Highlight](https://read.readwise.io/read/01kvga6ykwtb9b8pezxgv3hee9)) - Note: H1 — Theo's distinctive addition: loops whose *shape* is generated to fit the specific problem (loops that spawn sub-loops dynamically). - Tags: atom/literature/h1, loop-engineering - before another agent read it and gave feedback on it, you're wasting your own time. That's time that the agent could have spent instead that you could have used to find other work worth doing or to relax a little or go spin up a side project. I don't know what you're going to do with your free time, but I have had far too many instances where I read agent code. was like, "That's obviously wrong." And then told it to go fix it. They can figure that [ \_\_ ] out themselves, too. And now when the human comes in, all the [ \_\_ ] is gone and you can focus on the hard stuff. It's so much more fun. Try to find where you have to be involved and see what it ([View Highlight](https://read.readwise.io/read/01kvga73ma67eqhga9xkj388hd)) - Note: H2 — live maker/checker instance (let a 2nd agent review before you read it). Spicy practitioner claim; scoped to low-stakes work, else over-generalized. - Tags: maker-checker, atom/literature/h2, fallacy/hasty-generalization - more money. If you're paying API prices, you probably shouldn't be doing loops yet. That said, you might be surprised how far you can go with them. Remember that loop I mentioned earlier that I was using Opus and Claude code for where it's watching the PR and updating it constantly? Not only is it doing that, I've noticed that every time it gets feedback, it spins up a workflow with eight steps or more to address all of it. I had one agent spend under 10 minutes leaving feedback. And based on that feedback, the Opus workflow ran for ([View Highlight](https://read.readwise.io/read/01kvga7anv9byskaqpypp4n0mh)) - Note: H3 — cost, not capability, is the binding constraint: loops are only viable on flat-rate subscription plans, not API pricing. - Tags: ai-cost, atom/literature/h3 ## Links - [[The Maker Should Not Grade Its Own Homework]] — applies-in: review loops gain credibility by separating production from checking. - [[A Nondeterministic Check Breaks the Loops Stop Condition]] — contrasts: a dynamically shaped loop still needs a trustworthy stopping signal.