Heidelberg AICurriculum

The Creators of Claude Code and OpenClaw don't Prompt Their Agents Anymore?!

Cole Medin ·2026-06-18 ·2 min read

Summary written by us from the video's transcript. The video, and everything in it, is Cole Medin's work.

Learn how loop engineering works for AI coding assistants, its drawbacks, and practical ways to make loops reliable and cost‑effective using tools like Arkon and a custom dashboard.

Takeaways

  • Loop engineering automates repetitive prompting but can quickly become token‑hungry and context‑heavy.
  • Claude Code’s built‑in `/loop`, `/goal` and `/routines` let you schedule tasks, yet they often run in a single agent session causing scalability issues.
  • Arkon breaks work into deterministic steps, isolates sessions, and lets you mix models to reduce cost.
  • Storing workflow state externally (e.g., Neon/Postgres) provides durability and the ability to resume after crashes.
  • A dashboard that logs token usage and loop decisions gives visibility needed to manage reliability and expenses.

What Loop Engineering Is

Loop engineering means writing **loops** that repeatedly prompt an AI coding assistant instead of manually prompting each time. In Claude Code you can use commands such as `/loop` (run a prompt on a schedule), `/goal` (keep the agent working until a condition is met) and `/routines` (scheduled jobs). The idea is to give a high‑level spec, let an orchestrator set up the loop, and have the AI work through tasks incrementally.

Basic Example in Claude Code

A simple use case is setting `/loop` to check GitHub issues every five minutes. Claude wakes itself, fetches new issues, processes the first unchecked task, validates it, then sleeps until the next wake‑up. The orchestrator loads the loop skill automatically and runs each task one at a time, reporting back when all tasks are done.

Why Loops Can Be Problematic

Loops can become **expensive**: a single run may consume over a million tokens because the orchestrator repeatedly reasons, spawns workers, and passes context back and forth. They also risk **context bloat**, as the same coding‑agent session accumulates all prior interactions, overwhelming the model. Finally, many implementations keep everything in one agent session, making it hard to scale or run tasks in parallel reliably.

Making Loops More Reliable with Arkon

Arkon is a harness that lets you build deterministic workflows composed of multiple coding‑agent sessions. A typical workflow (e.g., fixing a GitHub issue) extracts the issue number, classifies it, researches, implements, validates, and creates a PR—each step runs in its own session. You can choose different models per step (small model for classification, Claude Code for implementation, Codex for review), mixing providers to cut costs. Arkon stores logs and state in an external Postgres/Neon database, giving durability and the ability to resume after failures.

Parallelism, Work Trees, and Human‑in‑the‑Loop

Arkon can launch several workflows in parallel (e.g., four simultaneous GitHub issue fixes). Each workflow runs isolated work trees so agents don’t step on each other’s code or database changes. You can pause any node for manual review, preventing the “run‑and‑forget” problem that often produces low‑quality output.

A Custom Dashboard for Observability and Cost Tracking

The author built an open‑source dashboard that records every loop event, token usage, and state change in Neon. The orchestrator reads this external state, decides the next actions, and dispatches workers. The UI shows full run histories, token counts per round, and lets you inject human decisions before the next iteration. This adds durability, observability, and a way to keep costs under control while still using powerful models like Pi’s Kimmy K2.7 for critical steps.