How is loop engineering different from prompt engineering?

Prompt engineering optimises a single model call. Loop engineering optimises the cycle the agent runs repeatedly — what context it receives, what action it takes, how it verifies the result, and when it stops. For coding agents the loop dominates: a well-instrumented repository with a mediocre prompt reliably outperforms a beautifully worded prompt against a repo the agent cannot verify work in.

Is this specific to one agent or harness?

No. The curriculum covers loop design principles that apply across harnesses, with hands-on work in whichever the team actually uses. The transferable skill is designing verification and stop conditions, which outlives any particular tool.

Does this require changing our codebase?

Usually yes, and that is the most valuable part. Module two produces a specific list of changes — faster test subsets, clearer type boundaries, machine-readable conventions, better failure messages — that improve agent convergence. Nearly all of them improve the experience for human engineers too.

How do we know if it is working?

The curriculum defines measurable signals: first-attempt convergence rate, iterations to green, token cost per completed task, and rate of runs hitting the iteration ceiling. Teams establish a baseline during the programme so later changes can be evaluated against it rather than assessed by feel.

Is this useful if we already use coding agents daily?

Typically more useful, not less. Teams already using agents have concrete failure patterns to bring to the triage module, and usually have a repository that has never been deliberately instrumented for agent use.

Loop Engineering for Coding Agents

Teaches engineering teams to design the verification loops coding agents run inside, which matters far more than prompt wording for agent reliability.

Who it's for: Software engineers, tech leads, and platform teams adopting coding agents
Format: 2 days, instructor-led, in-person or remote
Prerequisites: Working knowledge of a codebase, version control, and CI. Prior agent experience helpful but not required.

Discuss this curriculum See the modules

Illustration of a closed circular loop tightening toward a target point, representing feedback loops that make coding agents converge

By the end

What your team walks out with.

Explain why loop design, not prompt wording, is the dominant factor in coding agent reliability
Instrument a repository so an agent can verify its own work without a human in the inner loop
Design stop conditions and iteration budgets that prevent expensive thrashing
Diagnose a failing agent run by identifying which part of the loop broke
Set up a repository so agents converge on first attempt more often — tests, types, linting, and docs as agent-facing infrastructure

4 modules

How the programme runs.

01The loop is the product: context, action, verification
Half day
A shared model of the agent loop and where real failures originate.
02Making repositories agent-legible
Half day
A concrete list of changes to the team's own repo that improve agent convergence.
03Verification design: tests, types, and fast signals
Half day
A verification layer an agent can run unattended, with runtime budgets that keep loops tight.
04Stop conditions, budgets, and failure triage
Half day
Written iteration limits and a triage procedure for diagnosing failed agent runs.

The common diagnosis when a coding agent underperforms is that the prompt was wrong. Usually it is not. The agent was dropped into a repository where it could not run the tests quickly, could not tell whether its change worked, received a wall of unfiltered output when something failed, and had no defined point at which to stop trying.

That is a loop problem, and loops are engineered, not prompted. This curriculum treats the cycle an agent runs — gather context, act, verify, decide whether to continue — as the actual unit of design, and the repository as infrastructure that either supports that cycle or fights it.

Why the loop dominates

A coding agent does not produce a correct change in one shot. It produces a candidate, checks it, and revises. Everything that matters about reliability lives in the checking step: how fast it is, how specific its signal is, and whether the agent can run it without asking a human.

This reframes a lot of familiar engineering advice. A test suite that takes eleven minutes is a mild annoyance to a human who context-switches while it runs. To an agent iterating five times, it is a fifty-five minute loop that will likely be abandoned or truncated. A cryptic assertion failure is something a human engineer decodes from experience; to an agent it is a low-information signal that produces a guess rather than a fix.

Who this is for

Engineering teams actively adopting agents, ideally with a tech lead or platform engineer who can act on the repository changes identified in module two. Groups of eight to twenty work well. Teams bring their own repository — the entire second module is worked against real code, not a sample project.

What the two days cover

Day one — the loop and the repository

The morning builds the model: context, action, verification, stop condition. Participants map their current agent usage onto it and identify which stage their failures actually originate in. This is usually clarifying, because most teams have been attributing verification failures to the model.

The afternoon is the repository audit. Teams examine their own codebase for agent-legibility: how long the fastest meaningful verification takes, whether a single module's tests can be run in isolation, whether failure output is specific or a wall of noise, whether conventions are written down anywhere machine-readable, and whether a fresh agent can determine how to build and test the project without guessing. The output is a prioritised change list, ordered by improvement per unit of effort.

Day two — verification and control

The morning builds the verification layer. The design target is a fast, specific signal an agent can run unattended — usually a tiered arrangement where the inner loop runs in seconds (types, lint, a focused test subset) and the expensive full suite runs only at the end. Teams learn to treat inner-loop runtime as a hard budget rather than something that grows unchecked.

The afternoon covers control and triage. Agents that cannot tell they are stuck will spend real money demonstrating it, so teams set explicit iteration ceilings, define what happens when one is hit, and practise a triage procedure: given a failed run, determine whether context, action, verification, or the stop condition was the culprit. Each has a different fix, and teams that cannot tell them apart tend to reach for a different model when the actual problem was a slow test suite.

Signals worth measuring

Teams establish a baseline during the programme so changes can be evaluated rather than guessed at:

First-attempt convergence rate — how often the agent gets to green without human intervention
Iterations to green — the loop count on successful runs
Inner-loop runtime — the single most actionable number in the whole set
Ceiling-hit rate — proportion of runs exhausting their iteration budget
Token cost per completed task — the honest economic measure, rather than cost per call

Agent harness engineering is the natural companion — loops are what the harness runs, and most teams take both. Non-engineering colleagues are better served by Claude for work.

Sessions are delivered by explainx.ai and run against the team's own repository and agent harness.

Common questions

How is loop engineering different from prompt engineering?: Prompt engineering optimises a single model call. Loop engineering optimises the cycle the agent runs repeatedly — what context it receives, what action it takes, how it verifies the result, and when it stops. For coding agents the loop dominates: a well-instrumented repository with a mediocre prompt reliably outperforms a beautifully worded prompt against a repo the agent cannot verify work in.
Is this specific to one agent or harness?: No. The curriculum covers loop design principles that apply across harnesses, with hands-on work in whichever the team actually uses. The transferable skill is designing verification and stop conditions, which outlives any particular tool.
Does this require changing our codebase?: Usually yes, and that is the most valuable part. Module two produces a specific list of changes — faster test subsets, clearer type boundaries, machine-readable conventions, better failure messages — that improve agent convergence. Nearly all of them improve the experience for human engineers too.
How do we know if it is working?: The curriculum defines measurable signals: first-attempt convergence rate, iterations to green, token cost per completed task, and rate of runs hitting the iteration ceiling. Teams establish a baseline during the programme so later changes can be evaluated against it rather than assessed by feel.
Is this useful if we already use coding agents daily?: Typically more useful, not less. Teams already using agents have concrete failure patterns to bring to the triage module, and usually have a repository that has never been deliberately instrumented for agent use.

Make it fit your team

Shape this curriculum around your work.

Every session is adapted before delivery — to your tools, your data constraints, and the tasks your team actually does. Tell us the context and we will come back with a scoped outline.

Our practitioners’ training experience

Platforms our practitioners teach on

Udemy

Coursera

Codecademy

Other curricula

Agent Harness Engineering

Teaches teams to evaluate and operate agent harnesses as production infrastructure, covering tool design, permissions, sandboxing, and observability.

AI Research Methods for Nonprofits

Teaches nonprofit staff to evaluate AI tools and claims rigorously on a constrained budget, rather than to build models.

AI Safety and Guardrails for Healthcare Teams

Teaches healthcare teams to find and contain AI failure modes before deployment, with escalation paths designed around clinical risk rather than model accuracy.

ChatGPT for Work

Teaches teams to convert ad-hoc ChatGPT use into shared, reviewable workflows using custom GPTs, projects, and data analysis.