吴恩达老师讲 Loop engineering：三种反馈循环让 AI agent 持续迭代

吴恩达老师讲「Loop engineering」 把 AI agent 放进一套持续迭代、持续反馈、持续校准的循环系统里，产品成功取决于三个循环是否运转良好：代码自我迭代、开发者判断校准、外部用户反...

吴恩达老师讲「Loop engineering」 把 AI agent 放进一套持续迭代、持续反馈、持续校准的循环系统里，产品成功取决于三个循环是否运转良好：代码自我迭代、开发者判断校准、外部用户反馈。 第一层：Agentic coding loop，工程执行循环 这是最底层、最快的循环。 给 AI 一个产品规格，最好再配一组 evals 或测试标准，让它自己写代码、运行、测试、修 bug、再测试，直到满足规格。 过去 AI 写代码更像“一次性回答”；现在的 coding agent 更像一个可以连续工作的工程执行体。它能自己打开浏览器检查页面，跑测试，发现问题，再修改。这使得 AI 可以在没有人类频繁介入的情况下工作几十分钟甚至更久。 这层循环的价值是把开发中的大量低层执行工作自动化： · 写功能 · 修 bug · 跑测试 · 检查 UI · 验证行为是否符合规格 · 反复打磨实现 但它的前提是：你要给它清楚的规格、可验证的目标，必要时还要有 evals。否则 agent 只是“忙碌地迭代”，不一定朝正确方向前进。 这也是吴老师文章中很关键的一点：AI agent 的能力越强，规格和评估体系越重要。 第二层：Developer feedback loop，开发者反馈循环 这是中间层，速度比工程循环慢，通常是几十分钟到几小时一次。 开发者不再主要扮演传统 QA，手动找 bug、让 AI 修 bug。因为 AI 已经越来越能自己测试和修正低层问题。开发者的角色上移了：更多承担产品判断、体验判断、方向判断。 也就是说，开发者要回答的问题从： · “这个按钮坏了吗？” 变成： · “这个功能该不该存在？” · “这个流程是不是符合用户真实场景？” · “这个视觉风格是不是对？” · “这个产品到底应该服务谁？” 吴老师用给女儿做打字练习 app 的例子说明：AI 可以自己开发，但“猫咪服装解锁机制”“家长登录流程”“视觉设计风格”这些判断，仍然需要人来决定。 这里有一个很重要的观点：他不太喜欢只用“taste”来描述人的作用，而更愿意说是 context advantage，语境优势或上下文优势。 这比“品味”更准确。 第三层：External feedback loop，外部反馈循环 这是最慢但最接近真实世界的循环。 包括： · 找朋友试用 · alpha 测试 · 上线给真实用户 · A/B 测试 · 分析用户行为数据 · 收集客户反馈 · 做竞品分析 这个循环可能需要数小时、数天，甚至数周。但它决定产品方向是否真实有效。 前两个循环可以让你更快地“把东西做出来”，但外部反馈循环告诉你：你做出来的东西有没有人真的需要。 这是 AI 编程时代尤其容易被忽视的一点。 AI 编程时代正在经历一次角色迁移 以前的软件开发链条大致是： 产品经理定义需求，设计师设计体验，工程师实现，QA 测试，用户反馈再回流。 现在 AI agent 压缩了“实现”和“低层测试”的成本，工程师开始自然进入更上层的位置：产品定义、用户理解、体验判断、反馈分析。 工程师不会替代产品经理或设计师，但边界正在变模糊。AI 让更多人有能力从想法直接走到原型，再到上线测试。 所以未来有竞争力的人，不只是“会写代码的人”，而是能设计好这三类循环的人： · 让 AI 高效执行的工程循环 · 让人类上下文不断校准方向的反馈循环 · 让真实用户数据修正产品愿景的外部循环 Andrew Ng @AndrewYNg “Loop engineering” is a hot buzzphrase after mentions of it by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw's creator) went viral on social media. Loops are now a key part of how we get AI agents to iterate at length to build software. In this letter, I’d like to share my 3 key loops, shown in the image below, for building 0-to-1 products. These loops guide not just how I build software, but also how I decide what software to build. Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention. The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention! Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on. The developer-feedback loop operates over time intervals between tens of minutes and hours — that's how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child's learning experience. When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful. AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system. External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent. With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both! I will write more about how to do this in future posts, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering). [Original text: The Batch] 🔗 View Quoted Tweet 💬 6 🔄 1 ❤️ 4 👀 738 📊 7 ⚡