Loop Engineering: how complex builds actually get delivered

What it is

Loop engineering grew up in software delivery.

Instead of an engineer typing every line, the work runs as a cycle: set a goal, act, look at what happened, adjust, go again, until the work is finished and verified. An agent does the repetitive part and an engineer designs and supervises the cycle. This is how a good deal of software now gets delivered, including ours.

The immediate consequence is speed. The second one is more interesting. Because the cycle is designed rather than improvised, delivery becomes something you can inspect. A well designed loop leaves a trace of what it tried and why.

The hard part is stopping

The difficult problem is not getting an agent to do work. It is getting it to know when it is finished, and to show it.

Termination, verification and budget become design problems in their own right. A system that cannot tell when it is done is not a productivity gain. It is an overnight bill.

Done well there are several independent exits. The goal is verified. Or an iteration limit is reached. Or the budget runs out. Or the system notices it has stopped making progress and stops rather than trying the same failed approach again.

And the verification is deterministic, which is the word that matters. Tests, schema checks, type checks: things that pass or fail, rather than the system assessing its own work and reporting that it is satisfied. Self assessment is a weak check however confident it sounds.

What bad looks like

The system announces it has finished and nobody checks. It hits a failing test and deletes the test rather than fixing the code, which is a real and documented behaviour. It burns budget retrying an approach that was never going to work. Or it produces a great deal of output that nobody fully understands, which is fine until something breaks.

None of those are exotic. They are the usual outcomes when a loop is built without the discipline described above.

Build the simple ones, buy the hard ones

These principles are not only for engineers. Somebody setting up a task that runs every morning, tidies its own output and flags anything odd is building a loop, and everything in this article applies to them: know when it stops, know how you would spot a wrong answer, and cap what it can spend and touch.

Those are worth encouraging. It is where a lot of the everyday value sits, and it teaches people more about what these systems can and cannot do than most training will.

The point to bring in people who do this for a living is when a loop starts touching real systems, real money or real customers. Partly because it becomes technically harder, and mostly because the cost of it being quietly wrong stops being an inconvenience.

Two things follow.

First, the shape of a good delivery relationship has changed. It is reasonable now to expect faster iteration and to see progress more often. If you are being quoted timelines that assume the old shape, that is worth a conversation.

Second, there is one question worth asking anyone who builds for you, and it is the only technical question in this series worth memorising.

How do you verify the work is right?

A strong answer describes checks that pass or fail, where they run, and what happens when one fails. A vaguer answer, along the lines of the system reporting that it is finished or a review at the end, is worth following up on rather than taking at face value.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple. Next: Graph Engineering, structure and control for bigger outcomes.