Loop engineering: from prompts to /goal

Prompting is excellent for one-shot work: a draft, an explanation, a translation. You ask, it answers, and you move on. But real work rarely ends there. You inspect the result, find what missed, feed that back, and ask again.

That is a loop, and it is usually running on the person at the keyboard. The session's central idea was simple: move the mechanical part of that loop onto the machine, while keeping the human judgment in the definition of what good looks like.

A useful AI loop does not just receive a list of steps. It receives a finish line it can check: act, test whether the goal has been met, adjust if it has not, then stop only when the test passes or a limit is reached.

The important shift is from 'make a nice report' to something a machine can evaluate, such as 'the report has no missing dates and every total reconciles.' The first is a preference; the second gives the loop a way to know whether its work is done.

We put loop engineering in context with the other skills that make AI useful. Prompting gives the model a clear ask. Context engineering gives it the right material. Loop engineering gives it a checkable goal and room to iterate. Harness engineering adds the rails: the tools it may use, what it must not touch, how it reports, and when it must stop.

The model can be the same at every layer. What changes is the quality of the setup around it, which is why two people can get very different results from the same tool.

The useful property of a loop is also its risk: it keeps going. Every pass has a cost, and a loop without a stop condition can spend money, time, and attention long after it has stopped learning anything new.

So a good loop earns its exit. It has a maximum number of passes, a no-progress condition, and permission to say it could not find an answer. An honest 'not found, here is what I checked' is more useful than a confident invention.

To keep the idea concrete, we pointed a goal-driven loop at Oslo Bysykkel's live station feed. The problem is familiar in a hilly city: people ride downhill into the centre, leaving some stations full and uphill stations empty. Rebalancing bikes is a real operational task, and the live data changes every few seconds.

The loop looked for a simple, checkable pattern: an empty station close to another station with at least three free docks. It narrated each pass, stopped after a fixed budget or when the data stopped changing, and reported either the evidence it found or that the network looked balanced at that moment.

The same pattern applies wherever someone repeatedly checks a list, reconciles a record, or follows up on a routine task. Small non-profits are a strong example: donor spreadsheets, volunteer records, grant reports, and participant confirmations all contain recurring checking work, often without an engineering team to automate it.

Vibe coding makes that work more reachable. You can describe the finish line in plain language, have AI help create the loop, and still keep an audit trail of what it checked. The goal is not to remove people from mission work; it is to return some of their time to it.

Start with something you already re-check by hand. Write the definition of done, the maximum effort you will allow, and what the loop should report back. The exercise is less about installing a particular tool and more about learning to turn judgment into a testable finish line.