Loop engineering moves the person to the checkpoint

This connects to my recent experience with Codex. When I was writing that goal article, I was more focused on the matter of “completion criteria”: what the goal is, where the boundaries lie, what to use for verification, and when something counts as done.

Looking back after the conference, “goal” is only a small but crucial part of loop engineering. It addresses how a single task can keep moving forward without constant human reminders. The bigger questions are: which tasks are worth handing over to a loop, which checkpoints must remain with humans, which judgments can be built into the system in advance, and which responsibilities cannot be pushed onto AI.

I now think there are two scenarios that fit best.

One is performance optimization. It naturally comes with metrics, and it’s best if it can also automatically retest. You tell the agent: the interface P95 needs to be reduced to a certain value, the first-screen rendering needs to be controlled within a certain number of milliseconds, the bundle size needs to be reduced to a certain number of KB, and regression tests must not fail. After each round of changes, it runs a benchmark, profile, or stress test; if the target isn’t met, it continues to look for bottlenecks. Here, the human’s value is not to check which line was changed each time, but to first provide verifiable acceptance metrics, and then judge at key checkpoints whether “this optimization has changed the business semantics.”

Another one is UI refactoring. The premise is having clear design specs, ideally achieving a 1:1 restoration. Without design specs, people keep getting pulled back into trivial judgments like “this margin is off,” “this color feels wrong,” “this interaction doesn’t feel right.” With design specs, AI’s loop can converge around screenshots, DOM, styles, and visual differences. People don’t need to chase every CSS adjustment, but they are responsible for the final interface.

The common ground between these two scenarios is that the deliverable is not just a vague “do it better.” Performance optimization has numbers, UI redesigns have design mockups. The loop works not because the AI is more obedient, but because the task itself has comparable goals.

Multica Is Like a Collaboration Board

At the conference venue, I also ran into people from the open-source community introducing their projects, among which Multica was quite interesting. When I looked it up afterward, I found that it isn’t a brand-new monolithic coding agent, but rather a layer that connects tools such as Claude Code, Codex, GitHub Copilot CLI, OpenCode, Gemini, Kimi, and Cursor Agent into a unified task collaboration layer.

In its README, agent is described as a teammate: it can be assigned issues, report blockers, update status, and also appear on the kanban board, in comments, and across the task lifecycle. More specifically in the docs: agent is a first-class member of the workspace, can be assigned issues, speak in comments, and be mentioned with @; when creating an agent, you can choose the underlying AI coding tool behind it, and configure instructions, model, environment variables, CLI arguments, visibility, and concurrency limits.

This turns “which model to use” from a temporary choice in a single prompt into a role configuration in team collaboration.

The most interesting aspect of it is not the phrase “multi-agent” itself, but rather the ability to assign different roles to different agents. For example, one agent can use a cheap model to handle repetitive fixes, another can use a more powerful model to make architectural judgments, and a third can focus solely on code review without making any changes; combined with mechanisms like Squad, a leader agent can route tasks to the appropriate members based on the content of the issue.

I haven’t run through Multica end to end, so it can only be treated here as a sample that can be cross-checked against publicly available material. But this design direction belongs to the same class of problem as loop engineering: rather than letting a single AI do everything, you put tasks, roles, models, review, and state transitions all into the same loop.

If a company is really going to implement AI to write code, this difference matters.

Now model prices vary, and so do their capability boundaries. Using the most expensive closed-source model for every task doesn’t necessarily keep costs under control; using cheap models for every task may push costs to the back end through rework and missed reviews. A more realistic approach is layering: low-risk, repetitive, clearly bounded work goes to cheap models first; critical changes, architectural trade-offs, and final review are reserved for stronger models or humans.

Using closed-source strong models for review is, I think, a good position. Review is not just “picking out grammatical errors” — it requires examining whether requirements have been corrupted, whether boundaries have been crossed, whether tests only cover the surface, and whether commit messages conceal risks. This type of task demands more judgment, but the call frequency may not be as high as during the implementation phase, making the cost accounting easier to accept.

Less Human Involvement Does Not Mean Less Human Accountability

There’s a point from the roundtable discussion that I really agree with: the code is written by AI, but the code is submitted by humans.

This sentence sounds like a reminder of responsibility, but it is also a principle of process design. AI can write code, modify code, run tests, generate PR descriptions, and even have another model review it first. But the person who ultimately merges the code into the main branch cannot say, “This was written by AI, it has nothing to do with me.”

What a company needs is not who is typing characters on a keyboard, but who takes responsibility for the result. Once you submit, it means you are willing to take responsibility for the business semantics, risk boundaries, test evidence, and rollback plan of this change. The deeper AI’s involvement, the less ambiguous this matter can be.

So loop engineering is not about completely removing people from the process. It’s more about rearranging where people fit in:

{{< relref “/post/2025-03-15-llm-app-engineering/” >}}

• Before the task begins, humans clearly define the goals, boundaries, and acceptance criteria.
• During the loop, the system and the agent handle repeated attempts, testing, fixing, and state synchronization on their own.
• At critical checkpoints, humans review the evidence, the differences, and the risks, rather than chasing every line of the AI’s output.
• When submitting code, humans take responsibility for the outcome and cannot use AI as an excuse to avoid accountability.

This is also why I connect seemingly scattered elements such as goals, performance metrics, design specs, and Multica together. They all advance, externalize, and structure human judgment. Humans participate a little less, but in more critical positions.

If this isn’t done well, it turns into another kind of inefficiency: AI produces a lot, humans can’t review it all, and the team ends up merging code based on “it feels about right.” When something goes wrong, the blame gets pushed onto AI. That’s not engineering—that’s just chaos with a different producer.

The loop that’s really worth pursuing is not about letting AI keep writing, but about making sure that every round of writing, modification, testing, and review can come back to the same acceptance checklist. Human work shifts from “watching it write” to “defining what counts as good, checking whether the evidence is sufficient, and taking responsibility for submissions.” That might be exactly where the term loop engineering has kept me thinking.

References

• Multica GitHub README
• Multica Docs: Agents
• Multica Docs: Create and configure an agent
• Multica Docs: AI coding tools matrix
• Multica Docs: Squads