Loop Engineering Explained

Detailed Summary

Introduction to Loop Engineering (0:00 - 01:59)

The current coding workflow often involves repetitive manual steps: prompting, running tests, pasting errors back to the agent, and reviewing every minor change. This 'babysitting' prevents developers from focusing on high-level thinking. Loop engineering is presented as the solution, allowing agents to loop with themselves to reach a final output, cutting down manual steps by half.

The Industry Shift (01:59 - 03:34)

Leading figures at Anthropic and the creator of Open Claw have shifted from prompting agents to writing the loops that prompt the agents. This is not a simple cron job; it is a system where the LLM acts as the decision-maker. The agent looks at the current state, chooses an action, checks the result, and decides whether to continue, retry, or stop based on reward signals.

Triggers and Verifiable Goals (03:34 - 05:49)

For a loop to be effective, it requires two foundational elements:

• Triggers: Events like pull requests, failing CI runs, or Slack messages that start the process.
• Verifiable Goals: Conditions that tell the model when to stop, such as green CI tests or a reviewer model confirming the UI matches a specification. Without these, the system simply consumes tokens without achieving a reliable result. The focus has shifted from the prompt itself to the context, tools, and failure handling surrounding it.

The Five Pieces of a Loop (05:49 - 08:35)

Following a framework by Addy Osmani, a loop consists of five components plus memory:

1. Automations: Mechanisms that allow the loop to wake up independently.
2. Worktrees: Parallel environments that allow agents to explore different solutions without overwriting each other.
3. Skills: Reusable markdown files containing project rules and conventions to prevent the agent from 're-learning' the project every run.
4. Connectors: Plugins that allow the agent to interact with GitHub, Linear, or databases.
5. Sub-agents: Separating the 'writer' from the 'judge' to ensure quality.

Practical Implementation and Automation (08:35 - 10:08)

A practical loop might run every morning to read CI failures, open a worktree to draft a fix, and use a second agent to review the code against project skills. If tests pass, it opens a PR; if they fail, it feeds the error back. This imitates an engineer's workflow rather than just running a static script, offering much higher flexibility than traditional automation.

Risks: Fuzzy Goals and Token Costs (10:08 - 12:16)

Loop engineering faces two major hurdles:

• Fuzzy Goals: If a task is subjective (e.g., 'make this script good'), the loop may optimize toward a 'fake' goal or rewrite indefinitely.
• Runaway Costs: Continuous self-prompting can burn millions of tokens. Developers must implement 'hard breaks,' such as maximum iteration counts and daily dollar budgets, to prevent financial drain.

Conclusion: Staying the Engineer (12:16 - 14:23)

Autonomy should only be added when it pays for itself. For one-off tasks, manual prompting remains superior. The leverage point of software engineering has moved from writing code to prompting, and now to designing loops. Regardless of the level of automation, the human must remain the engineer by defining stop conditions, writing skills, and understanding the final output.

Notable Quotes

"My job is to write loops."
— Boris Turney, Anthropic

"If you did not build a loop, you just built a very confident token furnace."
— Louis François

"The takeaway here is not that prompt engineering and the other engineering types are dead. It's that the leverage point moved." — Louis François