@xiaogaifun: Andrew Ng explains Loop Engineering in just a few words. Andrew Ng is remarkably sharp. In his Newsletter a couple of days ago, he clearly laid out the essence of this new term—Loop Engineering—in just a few sentences. Just finished reading his article, so here’s my take on it. …

Andrew Ng put Loop Engineering in a nutshell in just a few words.

Andrew Ng is truly impressive. In his recent newsletter, he used just a few sentences to clearly explain the essence of the new term “Loop Engineering.” After reading his article, let me share my understanding.

1. In a nutshell, Loop Engineering discusses how to make AI work like an engineer — coding, verifying, and reworking until the requirements are met.

A standard coding workflow for a programmer is: write code, run the program, find bugs, modify the code, and test again until it works.

Now, more and more AI coding agents can complete this process on their own.

Give it a product requirements document (Spec) and a set of evaluation criteria (Eval), and the agent will enter a loop: write code → run tests → find issues → modify code → test again.

If the test fails, it continues to fix. If the feature doesn’t meet the requirements, it continues to fix. No human intervention is needed throughout the process.

2. The term “Loop Engineering” sounds intimidating, but the core idea is actually quite simple.

In the past, when we gave requirements to AI, we mostly described what we wanted to do. Now, we also need to tell it in advance what counts as success, what counts as completion, and how to automatically determine whether it’s done.

That’s the purpose of Spec and Eval. With these standards, the agent can write code, test itself, and fix bugs on its own, forming a true closed loop.

3. Andrew Ng believes that when viewed within the entire software development process, the Loop Engineering that everyone has been discussing recently is only a small part.

That’s why he specifically drew the diagram below, breaking down software development into three nested loops.

Outside the Coding Loop, there is a second loop called the Developer Feedback Loop.

Simply put, it’s the process where developers continuously adjust the product. The agent implements the requirements, and the developer corrects the requirements.

When we actually see a feature built, we often realize that what we initially thought we wanted isn’t what we truly want.

So the developer revises the requirements and hands them back to the agent for further development. This loop is typically much slower than the Coding Loop, happening every few tens of minutes or even hours.

But it determines what the product will look like. Essentially, this part is about the builder deciding what to build and how the product should look.

For example, whether a button should be placed on the left or right — the agent can help implement it, but the judgment is still ours.

4. There’s also a misconception about this loop: many people think that as long as the developer has a clear product vision in mind, everything else can be left to the agent. That’s not true at all.

Initially, we write a rough Spec and hand it to the agent to implement.

After the first version is built and we actually use it, we often discover: “Ah, this is not what I really wanted.” Haha, I experience this all the time.

So we go back and revise the Spec, adding details we hadn’t thought through or articulated clearly, and then let the agent continue development.

If we find that the agent keeps making the same mistakes — for example, a certain user flow always fails, or a certain type of input is never handled well — we need to supplement with an Eval, establishing those error-prone scenarios as mandatory tests for every future development run.

In other words, the second loop is about continuously calibrating our own understanding and gradually embedding that understanding into the system.

5. I remember an event last year where we discussed a topic: if AI’s taste keeps improving, will we eventually just need to say an idea, and it will build the entire product with almost no human involvement?

Andrew Ng said he doesn’t really like the word “taste.” He thinks the real advantage humans have over AI is not taste, but more context.

For example, we know who the users are, what their real usage scenarios are, and what problems they are actually frustrated by. Much of this information is not in the model’s context.

As long as humans have information that AI doesn’t know, someone must participate in the loop and continuously inject that critical information into the system. Therefore, the Developer Feedback Loop is hard to fully automate.

6. The outermost loop, in plain terms, is about gathering feedback from the real world. The first two loops address implementation issues.

At this level, the focus is on whether the product direction is correct and what features we should build next.

By collecting user feedback, analyzing data, or studying competitor products, we continuously refine our product judgment.

For example, is this feature really necessary? Is the user’s real pain point this? Should the product use a different interaction method? Or did we even choose the wrong direction from the start?

Real-world feedback constantly influences the developer’s judgment. The developer then updates the Spec with new understanding and hands it back to the agent for further development. That’s the relationship between the three loops.

7. Very insightful. Anyone confused about Loop Engineering should read this article. I’ll put the article link in the comments.

Finally, just to add one more point — I feel that these new terms are really just a different way of saying things. The reason they become popular is that they precisely capture the changes happening in the AI industry right now.

If you ask me, Loop Engineering is just recursive self-improvement. Keep Building.