Council Post: Loop Engineering Is The Most Important New Software Skill: The Hard Part Is Teaching The Loop To Say No

Yunhao Jiao is the CEO of a company building AI-powered testing solutions for modern development teams.

getty

​Watch how a growing number of developers actually work now. They're no longer typing a prompt, reading the answer or typing the next one. They write what "done" looks like, kick off a coding agent and go get coffee. When they return, the agent has written code, run it, found three things broken, fixed two and left a note about the third. A year ago, this sounded like a tall tale. Today, it's just another ordinary workday.

Something structural has shifted. The unit of work is no longer the prompt; it's the loop.

This went from nowhere to everywhere in about one month. OpenClaw steward Peter Steinberger's argument to stop hand-prompting and start designing the loop that prompts the agent took off almost overnight. Google Chrome engineering leader Addy Osmani gave the pattern a name and structure. Claude Code creator Boris Cherny says he no longer writes prompts; he writes the loop. AI pioneer Andrew Ng framed the same idea as three nested loops: an agentic coding loop measured in minutes, a developer feedback loop in hours and an external feedback loop over days or weeks.​

Why The Loop Matters More Than The Prompt

​So why now? Because the generator finally got good enough that the interesting problem moved. When a model can produce a decent first attempt most of the time, the leverage is no longer in crafting the perfect prompt. It’s in building a system that can give the agent a goal, let it act, check the result and decide what to do next.

The industry has moved toward that problem one layer at a time: prompt engineering, then context engineering, then harness engineering and now loop engineering. Each shift pushes more of the work beyond the keyboard. At its simplest, a loop is just a system that acts, checks a real signal, decides what to do next and repeats until the goal is met, without a human having to supervise every turn.

​​But here's the part that decides everything. A loop that only generates isn’t a loop; it’s a firehose. What closes the loop is a mechanism that can say, “not done yet.” The rest is increasingly cheap and interchangeable. Models get better and cheaper, and orchestration is becoming routine. The scarce, load-bearing piece is the verifier, and its quality determines the quality of the loop. Give a fast loop a weak verifier, and you’ve built an efficient machine for producing confident, broken software.

The failure mode is easy to spot. An open loop with no meaningful check simply drifts. It can report “done” even when the code doesn’t work because nothing in the system is allowed to disagree. Closing the loop means giving the agent a signal from reality that it can’t argue with. Getting that signal right is harder than it looks.

​A verifier that only reads source code is easy to fool. Code that looks correct can still fail in practice. An image tag might have perfect, accessible alt text but a dead source URL. It passes every static check and fails the only test that matters: can a person actually see the image?

The checks that matter in an autonomous loop judge behavior. They open the running software, use it as a person would and report what actually happened. They also have to resist gaming, because an agent will happily satisfy a loose check rather than the underlying goal. And they need to preserve what already works, so fixing today’s bug doesn’t reintroduce last week’s.

Get that block right, and something surprising happens to an assumption the industry has treated as settled. We’ve spent two years assuming better software requires a better, more expensive model. Inside a strong loop, the model matters less than the feedback around it. A cheaper model can close the gap with a frontier model on the metric that counts: whether the software works. An expensive model may produce the better first draft, but a rigorous verifier can turn a mediocre draft into something shippable. Once the loop is strong enough, quality becomes less tied to the price of the model. The leverage shifts from the generator to the gate.

​And notice where all of this happens: the terminal. That’s why the command line, of all things, is suddenly cool again. Developer tools are no longer used only by humans. Increasingly, agents are the primary users. An agent can’t click through a dashboard or glance at a chart, but it can reliably run a command and read the result. The command line is almost tailor-made for that interaction: the agent sends text and gets text back.

Who would have thought that Unix conventions from the 1970s would become such a natural interface for autonomous agents in 2026? Each part of the loop can become a command the agent runs on its own, without a human clicking “run.” It can run headlessly in CI, unattended at 3 a.m. or continuously around the clock.

That’s the point of the loop. The terminal didn’t return because developers got sentimental. It returned because it’s a natural habitat for agents—and the loop lives wherever the agent can act and get a reliable signal back.​

Conclusion

The last two years have been about making the generator better. The next stretch is about the loop around it, and the one block inside it that's allowed to refuse. The model writes the code now. The scarce, decisive work is designing the loop and building a check the agent can't game, one that reliably keeps saying "not done yet" until the software actually works. Most of that work happens one command at a time in a terminal window that a lot of people had written off.​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?