Ask a coding agent to implement a well-defined task and it will usually do it well. That stopped being remarkable some time ago. What is still hard — and what most teams have not solved — is everything around that task: turning a vague backlog issue into something an agent can act on, checking that what came back is actually correct, getting it deployed, and telling QA what is left to verify. As long as a human has to do all of that by hand, the agent is a fast typist inside a slow process.

Loop engineering is the discipline of fixing the process instead of the typist. It means designing a system with a small number of deliberate human checkpoints — someone approving a refined issue, someone promoting a build — and a set of automated gates that stop everything the moment something fails. Between those checkpoints, the loop runs on its own: refine, plan, implement, review, verify, ship. An issue goes in at one end and code deployed to a test environment comes out the other.

This is not "using AI to write code". It is a different job for the engineer, and this post is about what that job looks like.

Anatomy of the loop

A loop is a chain of stages, each one an agent running against the team's board and repository. The exact tooling varies, but the shape is remarkably consistent across the teams doing this well.

  1. Refine the backlog. An agent takes a raw one-line issue and checks it against the real repository — it never invents a path or a behaviour, it reads the code. It leaves behind a clear title, a user story, observable acceptance criteria, technical details and a manual QA checklist. When several issues are queued, it also computes a cross-impact map: which issues block each other, which touch the same files and cannot run in parallel, which are fully independent.
  2. Human approval. The refined issue and the impact map go to a person. Only after that approval is an issue "ready to develop". This is the most important checkpoint in the loop, because everything downstream is only as good as the acceptance criteria written here.
  3. Plan. A second agent writes an implementation plan for one refined issue before touching a line of code.
  4. Implement. It codes against the approved plan and opens the pull request.
  5. Review, then verify. An automated code review hunts the PR for correctness, security and convention bugs — and for acceptance criteria with no test behind them. A separate agent then re-reads the real code for each finding and confirms it is real before anything gets fixed. The second pass is what keeps the loop from spending a fix commit on a false positive.
  6. Local quality gate. Lint, typecheck, tests and build run on the machine that just did the implementation — pre-commit and pre-push hooks, plus one command that runs the same checks by hand. A cold CI runner cannot compete with a warm local cache, and the agent gets its answer in seconds with no queue. Continuous integration is reserved for the one thing a laptop genuinely cannot do: the deploy.
  7. Ship and hand off. Merge, wait for the deploy, move the issue to QA, and tick off only the checklist items an automated test actually proved. Anything that needs a real device or a human eye stays unchecked, on purpose, and the loop ends with a plain-language note for QA: for every issue, exactly what is still left to verify by hand.

Notice how little of that is "write code". Most of the loop is verification, and the two places a human still steps in are both about judgement, not typing.

The right model for each step

A loop that uses one model for everything is either too expensive or too sloppy. The stages have very different demands, and the teams getting good results route them deliberately: reasoning-heavy work — the implementation plan, the review, the independent verification of each finding — goes to the strongest model available, often at high reasoning effort and read-only. Volume work that is already channelled by an approved plan — refining issues, writing the code, applying the fixes the review asked for — goes to a faster, cheaper one.

This is an architecture decision, and it belongs to the engineer. Which steps deserve deep reasoning, which can be channelled, where a second independent opinion is worth the cost — those are exactly the kind of trade-offs a good system designer makes, just applied to a pipeline of agents instead of a pipeline of services.

What changes for the engineer

The loop does not replace the engineer. It changes, quite drastically, what the engineer spends the day on.

From writing code to designing the loop. Where do the human checkpoints go? What does the gate check, and in which order? Which model runs which stage? What happens when a review finding cannot be verified? These are system design questions, and the engineer who answers them well multiplies the output of every agent in the chain.

From "looks right" to pass/fail. Acceptance criteria used to be a courtesy to QA. In a loop they are the specification the agent implements against, the thing the review checks for missing tests, and the checklist that decides what gets ticked. A criterion that a test — human or automated — cannot answer with pass or fail is a criterion the loop cannot enforce. Writing them well is now a core engineering skill.

From reviewing diffs to prioritising findings. The agent review will surface more than a human reviewer ever did. The engineer's value is deciding which findings actually matter for this product, which are noise, and which reveal a gap in the criteria that the refinement stage should have caught.

From knowing a stack to understanding the system. Because the agents handle the framework-specific implementation, the engineer's leverage comes from the layer above syntax: data modelling, service boundaries, failure modes, what a sane transaction looks like, what "done" means for the user. That is the same conclusion we reached in AI multi full-stack engineers — the loop simply makes it unavoidable.

In short: less and less writing code line by line; more and more designing the loop itself, calibrating what counts as an acceptance criterion, and deciding which review finding actually matters.

What it looks like in practice

None of this is theoretical. We run this loop with Claude Code across our own projects at DIZENZ, the studio behind Archicise, and we published the numbers from the project we have run it the longest on — a multiplayer racing game for live events, from its first scaffold on 28 February 2026 through August 2026:

  • 160 issues → 160 PRs → 160 squash merges. Every PR that was opened got merged; zero abandoned.
  • ~46,000 lines of application and test code in Go and TypeScript.
  • 2,368 automated test cases — 463 in Go, 1,656 in Vitest, 249 in Playwright.
  • Median PR: 456 lines across 7 files. 65 merges in the single busiest week; 51 merges landed between midnight and 6am.

Two caveats we state in the open: "shipped" here means merged and deployed to a test environment, ready for QA — not shipped to production. And these are the numbers from a project with a single human engineer coordinating the loop. That last point is the whole story: one engineer, doing the job described above, is running the output of a team.

Our write-up goes through the exact stages, which model runs each one and why, and why the quality gate moved off CI onto the developer's machine. It is the most concrete description of a working loop we have put together, and it is worth reading in full.

How to get your team there

The tooling for loop engineering is available to everyone. What is scarce are engineers who can do the human part of it well: design a system of agents and gates, write acceptance criteria that a machine can enforce, judge whether generated code is subtly wrong, and decide what deserves a human checkpoint. Those are architecture, product and AI-engineering skills — and they are built by practising on real problems with specific feedback, not by watching a demo.

That is what Archicise is for:

  • Exercises across the three disciplines — system, database and API design, domain modelling, product discovery and scoping, agent and LLM application architecture — stated as real-world problems, independent of any language or framework.
  • AI coaching on every submission — specific, actionable feedback and a score, so engineers know exactly what to improve.
  • Visibility for the company — progress per engineer and per discipline, so you can see where the loop-engineering skills are being built and invest where it matters.

If you want your engineers to be the ones designing the loop rather than being replaced by it, register your company and start practising today.