Loop Engineering For Everyone
Loop engineering is clearly where we're heading. The missing piece is making it simple enough and affordable enough that every engineer can actually use it.
The Rise of Loop Engineering
Over the last two months, a remarkable consensus has emerged: the future isn’t prompting agents; it’s building systems that prompt them.
Started as ralph loop five months ago, and lately, pushed to the center of agentic engineering as Andrej Karpathy published loop.md. Andrew Ng described loop engineering as the next step in how we build software. Addy Osmani wrote: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Peter Steinberger put it even more directly: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” And Boris Cherny, the creator of Claude Code, described his own workflow: “I don’t prompt Claude anymore. I have loops running that prompt Claude... My job is to write loops.”
The ideas are compelling. The implementations are still largely invisible. We know what loop engineering is. Much less has been shared about how these systems are actually built and how well they actually work in reality. Recently, Claude Code published its own guide to loop engineering. It’s the closest thing we’ve seen to a public implementation. The guide introduces primitives like /goal, /loop, /schedule, dynamic workflows, custom skills, and a growing collection of building blocks for orchestrating agents. As a user, you still have to decide how many workers to spawn, how they communicate, when they hand work off to each other, how they evaluate one another, how they recover from failures, and what files to persist in the disk. And that’s before you think about cost. Running multiple frontier models in iterative loops can quickly tenfold your token bills over a single coding agent.
The Real Bottleneck: Complexity and Cost
Loop engineering is clearly where we’re heading. The missing piece is making it simple enough and affordable enough that every engineer can actually use it.
As someone who builds and breathes coding agents every day, we’ve realized two blockers.
The first is that engineers have become slaves to coding agents. As Andrey, Boris, Andrew, Peter, and Addy have all pointed out, prompting has become the biggest part of the job. Engineers now spend 8–12 hours a day babysitting coding agents, repeating the same context over and over again, switching between coding, testing, browser automation, code review, and research, just to push the work one step further. Productivity might have increased, but the quality of engineering and the mental state of engineers may have actually degraded.
The second is cost. Teams are already struggling to justify their Anthropic bills today. Add loop engineering on top, with multiple agents, multiple rounds of iteration, browser automation, and multiple frontier models, and those costs can easily grow another 10X. If this is where the industry is heading, we also have to make sure it’s accessible to every engineer, not just the teams that can afford it.
The future isn’t every engineer becoming an expert at loop engineering. The future is that engineers shouldn’t have to think about loops at all. They shouldn’t have to think about schedulers, browser automation, evaluators, generators, model routing, or which model is best for a particular task. Those are implementation details.
An engineer’s job is to understand the business, design great systems, collaborate with teammates, and build and iterate products that users love. The job of the coding agents is to handle the complexity underneath. Just as developers no longer think about assembly language or memory allocation every day, we believe the next generation of coding agents should hide the complexity of loop engineering behind the abstraction that people actually want: an engineer they can trust with a task.
Go Beyond: Meet AdaL Engineer
There needs to be a solution so that engineers can be put back to work that matters. The next 10X productivity and quality boost cannot just come from loop engineering alone. What the world really wants is a human-level engineer agent.
But what does a human-level engineer agent actually mean?
To us, it means moving one layer above today’s coding agents. Instead of you prompting coding agents, what if an agent prompted them for you? Instead of you approving an edit or a Bash run, what if this agent clicked it for you? Instead of you coordinating coding agents, browser agents, reviewers, and researchers across the full development lifecycle, from planning to building, QA testing, code review, and iteration, what if one agent handled that coordination? Instead of you choosing which model is best for each task, what if the agent made that decision for you?
We call this agent AdaL Engineer. AdaL is in honor of Ada Lovelace, the world’s first programmer and visionary who believed that machines can create, not just calculate. AdaL represents where the agent world starts and where the world will go.
AdaL Engineer was envisioned before the term “loop engineering” was even born. We model agents as the workers and the engineer. The workers are the agents of today, it can be for deep research, planning and implementing (the normal coding agent you see), the browser use agent that can be used to close the QA loops for web apps and visual tasks like building a landing page. Then it comes to the Engineer layer. The one that glues the whole iterative dev life cycle together, freeing the real human engineers from the complexity of /model and /agent to choose and the orchestration of the communication.
Developers just type the task and the success criteria to AdaL Engineer. The Engineer is responsible for delivering the task autonomously. It will decide how many workers are needed (give them the right mode, right capability, and the right tools), define the scope of each worker, coordinate communication between them, and determine when another iteration is needed. AdaL Engineer uses a small set of persistent markdown files to keep track records and to facilitate the coordination. contract.md defines the overall objective and ties the entire task together, each worker maintain a plan doc, such as builder_plan.md and test_plan.md to guide implementation and validation, while iterative evaluation files such as eval_iter_1.md, eval_iter_2.md capture independent feedback and drive the next round of improvements. This gives every worker a shared understanding of the task while allowing each one to operate independently within its own scope. Some of these files persist across sessions for each developer, serving as a detail log for each and single developer on the team.
To achieve the highest quality, it builds up a generator and an evaluator or even code reviews. Similar to the network GANs, we let the builder and the generator do their best to complete the task and test it to its maximum, and let another separate evaluator with separate context, so that they can do their best to identify issues independently. Where the code-reviews play the same roles. This is where the whole loop can be closed and in some cases, this loop leverages different models, going through multiple iterations where human engineers are unable to go to as the cost of time, this can potentially give even better quality than human engineer could ever deliver.
That’s the first piece of AdaL Engineer: it makes loop engineering simple.
The second piece is cost. Loop engineering shouldn’t be reserved for teams that can afford to run multiple frontier models around the clock.
AdaL Engineer automatically chooses the right model for the right task, using expensive models only when they provide meaningful value and relying on significantly cheaper models whenever possible. For example, instead of running everything on Opus 4.8, we can use GLM-5.2 for the engineer and models like MiniMax M3 for browser automation at a fraction of the cost, all while still delivering excellent results. When a task is genuinely difficult, AdaL Engineer can consult the most capable frontier models for advice on an as-needed basis instead of running purely on that expensive model. The goal isn’t just to automate engineering; it is to make high-quality automation affordable.
Seeing AdaL Engineer work is like seeing the best human engineers coordinating worker agents as well as they can to deliver the task. For simple tasks, it has the flexibility to stack with other existing builders without the hard limit of one task, one worker. Because it spins off a normal, complete AdaL worker with UI, users have the ability to take over and chat with the workers directly, like going from Tesla Autopilot to manual mode when there is an emergency.
How We Use AdaL Engineer Ourselves
Because AdaL Engineer can spin off worker agents or even another AdaL Engineer dev version, it closes the loop of AdaL’s own development, approaching Lilian Weng’s harness engineering for self-improvement. We are freeing our team to spend more time researching getting it to beyond human-level engineers.
Second, we have also automated the development of the AdaL platform, where companies and developers can build and manage their agents. It is currently in preview at cloud.adal.sylph.ai. We use our in-house, model-agnostic browser-use agent to automate the web. We also like using MiniMax M3 the most, as it is 10× cheaper than Opus 4.8.
Third, we use AdaL Engineer to help us build landing pages. Instead of spending weeks and tens of thousands of dollars working with a design agency, we want to push the limits of AI designers.
How Can You Use AdaL Engineer
AdaL Engineer just came out two days ago, and people who have tried it have quickly become hooked and refuse to go back to using a normal coding agent.
See AdaL Engineer clone a six-figure landing page all on its own, achieving near-100% fidelity.
But landing pages are only the beginning. AdaL Engineer is built to automate the full web-app development loop: planning, coding, browser testing, QA, review, and iteration.
Today, humans are the ones piecing this whole workflow together. One Claude Code for coding, Codex for another coding task, another Claude Code for code review, Graphite sometimes too, plus manual browser testing. Human engineers constantly jump between multiple tabs, multiple agents, and multiple unfinished threads, while each agent only handles one piece of the development cycle.
Now, AdaL Engineer brings the entire development workflow together in one screen, coordinating multiple working windows automatically in one place.
You define the engineering tasks that matter for the day. AdaL Engineer turns them into a shared contract.md, assigns the right workers, coordinates the loop, approves edits, and pushes each task forward.
Instead of managing ten tabs, ten prompts, and ten unfinished threads, you assign the work to AdaL Engineer and focus on product direction, user taste, and the decisions only humans can make.
What Comes Next
Our team is iterating quickly toward one goal: an engineer that remembers your taste, understands your codebase and goals deeply, and lets you simply assign tasks.
We are only a small team of seven, including two interns, but that is exactly why we care so much about AdaL Engineer. We are building the system we need ourselves: an engineer that helps a small team move with the speed, quality, and ambition of a much larger one.
Human taste still matters. Agents will change how software gets built, but humans still decide what is worth building.
More soon.
interesting article! seems like bigger companies are unable to deliver the same loop engineering system while being affordable. will go check the product out!
One thing worth examining: what does the evaluator actually return?
If it returns pass/fail, the generator can't distinguish "wrong code" from "can't evaluate yet because the test environment isn't running" from "correct if another module's contract holds." All three trigger a full iteration. The loop burns tokens regenerating work that was already right.
We hit this exact problem and solved it with four return values instead of two: NO (fails, here's the named reason — accumulates as exclusions), YES (done), MAYBE (can't evaluate — evidence missing, hold until gathered), IFF (correct if a named dependency holds — bind and wait).
The exclusion list becomes the loop's memory — each NO tells the generator what not to do next time, so iterations get more constrained rather than starting from scratch.
The writeup: https://metacortexdynamics.substack.com/p/your-loop-has-two-states-it-needs
Reference implementation (zero deps, MIT): https://github.com/MetaCortex-Dynamics/verdict4