7 INSANE loops you need to try right now

What Are “Loops” for AI Software Development?

The video explains “loops” for AI software development and presents concrete automation patterns that let an AI coding agent work autonomously toward a target goal—reducing human involvement and speeding up progress.

---

What Loops Are (Core Concept)

A loop is an approach for an AI coding agent to work autonomously until it reaches a specified goal.

What a Loop Requires

1. Trigger: starts the loop via one of:

   • Manual kickoff
   • Schedule (recurring, time-based runs)
   • Action-based kickoff (e.g., when a PR is opened)

2. Goal: one of two evaluation styles:

   • Verifiable goal: deterministic, testable (e.g., measurable thresholds like coverage%)
   • LLM as a judge: the model decides when the goal is “met” (more subjective / potentially brittle)

---

Launch: “Loop Library”

The speaker is launching a free Loop Library with many ready-to-use loop examples.

• The pitch emphasizes that you can copy prompts directly and use them to build your own loops.

---

Specific Loops and How They Work (Use Cases / Tutorials)

1) Sub-50 ms Page Load Loop (Performance Target)

Goal (verifiable): Ensure every page load in the app is under 50ms.

Loop behavior:

• Continues optimizing after significant changes
• Measures performance across every page under repeatable test conditions
• Moves page-by-page until all pages meet the threshold

Trigger examples:

• Manual kickoff
• Optionally scheduled
• Optionally triggered on PR open to prevent performance regressions

Implementation detail:

• Uses a Codex/Cloud Code “/goal” style prompt directive to “continue working until the condition is met.”

Operational note:

• May take 10 minutes to hours
• Requires monitoring under token budget constraints

Demo result:

• Ran about 50 minutes, iterating until all pages met the target on production.

---

2) Overnight Docs Sweep (LLM-as-judge Documentation Completeness)

Goal (LLM judge): Ensure documentation reflects the latest code changes.

Loop behavior:

• Each night:
  • Reviews the full codebase
  • Updates documentation
  • Opens a PR with the documentation changes

Why LLM-as-judge:

• Documentation “coverage” is hard to verify deterministically, so the LLM decides completeness.

Trigger:

• Recurring nightly automation

Implementation detail:

• Set up via a Codex automation workflow (e.g., “create via chat” + paste the prompt)

---

3) Architecture Satisfaction Loop (Refactor Quality)

Goal (LLM judge): “Refactor until you are happy with the architecture.”

LLM judgment criteria can be guided, for example:

• “Be very strict about simplicity”
• “Make sure every single line of code is DRY”

Loop behavior:

• After each significant step:
  • Live tests the system
  • Auto-reviews
  • Commits
  • Tracks progress via a markdown progress file

Trigger:

• Manual or nightly run (useful after heavy day-time development)

---

4) Logging Coverage Loop (LLM Judge: Important Paths)

Goal (LLM judge): Ensure thorough logging so every important path produces useful, tested logs.

• “Important” is treated as non-deterministic, so the LLM decides what paths matter.

Trigger:

• Manual kickoff

---

5) Production Error Sweep (Log Review → Fix → PR → Notify)

Goal (verifiable-ish / concrete): No more unaddressed actionable errors remain in production logs.

Loop behavior (nightly):

• Reviews production logs for errors
• Traces to root cause
• Fixes and verifies
• Opens a PR
• Pings in Slack with findings + PR link
• If none found, pings with “all clear”

Emphasis:

• An end-to-end remediation loop driven by log signals.

---

6) SEO/GEO Visibility Loop (Web Auditing → Iterative Fixes)

Goal: Run an SEO/GEO audit and fix issues until no critical technical issues remain.

Audit coverage includes:

• Crawlability, indexation
• Page intent, titles
• Internal links
• Data and source citations
• “Answer-first content”

Loop behavior:

• Identifies rank gaps
• Fixes highest-leverage issues
• Reruns the crawl
• Repeats until critical issues are gone

Trigger suggestion:

• Weekly run

---

7) Full Product Evaluation Loop (Scenario-Based Product Testing)

Goal: All major scenarios meet an original quality bar.

Loop behavior:

• Creates N realistic scenarios covering major capabilities
• Defines success criteria and uses a consistent evaluation method (pass/fail or rubric)
• Runs scenarios under the same conditions and records evidence
• For failures:
  • Fix underlying causes
  • Rerun affected scenarios
  • Then rerun the full set
• Continues until every scenario meets the bar

Key claim:

• It can be non-deterministic because the model judges outcomes and iterates improvements—not just deterministic tests.

Cost note:

• Can take ~12 hours or more

Customization example:

• Generate 100 use cases for an LLM Q&A feature
• Judge response quality with sources
• Iterate if responses aren’t good enough

---

Caveats / Limitations (Important Analysis)

1. Not for every problem yet

   • The hard part is defining a good loop goal
   • LLM-as-judge goals can be brittle due to subjective judgment
   • Not great for “build a brand-new feature from scratch,” because the model may not reliably follow the intended direction or decide what to build
   • Caution example: cloning Excel feature parity ran for days (speaker discourages this approach)

2. Loops are expensive

   • They can consume many tokens because the agent runs until it hits the goal
   • Runs may take minutes to days, making them difficult for teams without a large token budget

---

Main Speakers / Sources

• Main speaker: the video’s primary creator (not explicitly named in the provided subtitles)
• Referenced source: Peter Steinberg (credited as someone who uses the architecture satisfaction loop)

Sponsors / partners mentioned:

• DigitalOcean (inference infrastructure sponsor)
• here.now (hosting partner for the Loop Library website)