提供了AI代理开发的系统性方法论，展示了闭环设计如何释放人类开发者的创造力
“循环工程”是最近社交媒体上热门的术语，源于Boris Cherny（Claude Code的创建者）和Peter Steinberger（OpenClaw的创建者）的提及。循环现在是我们让AI代理进行长时间迭代以构建软件的关键部分。在这篇文章中，我想分享我构建0到1产品的三个关键循环（如下图所示）。这些循环不仅指导我如何构建软件，还指导我如何决定构建什么软件。
代理编码循环：给定一个产品规格和可选的评估数据集（即用于衡量性能的数据集），我们可以让AI代理编写代码，测试其工作，并不断迭代，直到代码无错误并满足规格要求。这个闭环思想在去年年底开始流行，并成为让编码代理在无需人工干预的情况下长时间高效工作的游戏规则改变者。例如，上周末我为女儿开发一个练习打字的应用，我的编码代理可以轻松地连续工作一个小时，使用网络浏览器多次检查所构建的内容，然后再回报给我，而无需我介入。
工程循环执行得很快。每隔几分钟，编码代理可能会构建和测试软件的新版本。我经常听到开发者们寻找新的方法来设计更有效的工程循环。这是一个积极创新的领域！
开发者反馈循环：在这个循环中，开发者检查当前产品并引导编码代理进行改进。去年，许多开发者（包括我自己）都在充当我们编码代理的质量保证功能，手动查找错误然后要求代理修复。但随着编码代理越来越能自行测试代码，我们在这个环节花费的时间显著减少。这使我们能够做出更高层次的产品决策，例如提供哪些关键功能、用户界面需要改进等。
开发者反馈循环在几分钟到几小时的时间间隔内运行——这是开发者可能审查产品并提供反馈的频率。在打字应用的案例中，我多次改变主意关于视觉设计、她可以通过学习解锁哪些猫咪服装（她喜欢猫），以及成人登录并引导孩子学习体验的用户流程。
当开发者对要构建的内容有清晰的愿景时，将愿景转化为编码代理可实现的规格仍然是一项工作。此外，在看到实现后，开发者可能会更新（或澄清）规格以引导其朝向目标。如果你发现系统反复遇到某些问题，为代理构建一组评估数据集会很有用。
越来越多的AI原生团队开始使用AI来帮助塑造产品方向，例如自动收集和分析使用数据、总结书面和口头客户反馈，或进行竞品分析。然而，对于我参与的大多数产品，我认为人类在上下文方面具有显著优势——我们比AI系统知道更多关于用户和产品运行环境的信息——因此人类在其中扮演着关键角色。许多人将这种人类贡献描述为“品味”，但我更倾向于认为是人类拥有上下文优势，因为这为帮助AI系统提升提供了更清晰的路径。这也说明了为什么这一步不能自动化：只要人类知道AI不知道的信息，就需要人在环中注入这些知识。
外部反馈循环：这包括各种策略，如向朋友征求反馈、向α测试用户发布，或将代码投入生产环境进行A/B测试。这些策略通常较慢，很少在几小时内完成，有时需要几天甚至几周。这一数据反馈给开发者的愿景，进而继续驱动详细的产品规格，最终驱动编码代理。
随着编码代理加快软件开发速度，越来越多的工程师开始扮演部分产品管理角色。对于许多正在成长为此角色的工程师来说，最难的部分是塑造产品愿景，并在构建（弥补愿景和规格之间的差距）和获取用户反馈以演化愿景之间找到平衡。两者都很重要！
我将在未来的文章中更多地讨论如何做到这一点，但目前我发现，工程师扮演着扩展角色（就像产品经理和设计师现在做更多工程工作一样）是令人鼓舞的。
[原文：The Batch]
代理编码循环：给定一个产品规格和可选的评估数据集（即用于衡量性能的数据集），我们可以让AI代理编写代码，测试其工作，并不断迭代，直到代码无错误并满足规格要求。这个闭环思想在去年年底开始流行，并成为让编码代理在无需人工干预的情况下长时间高效工作的游戏规则改变者。例如，上周末我为女儿开发一个练习打字的应用，我的编码代理可以轻松地连续工作一个小时，使用网络浏览器多次检查所构建的内容，然后再回报给我，而无需我介入。
工程循环执行得很快。每隔几分钟，编码代理可能会构建和测试软件的新版本。我经常听到开发者们寻找新的方法来设计更有效的工程循环。这是一个积极创新的领域！
开发者反馈循环：在这个循环中，开发者检查当前产品并引导编码代理进行改进。去年，许多开发者（包括我自己）都在充当我们编码代理的质量保证功能，手动查找错误然后要求代理修复。但随着编码代理越来越能自行测试代码，我们在这个环节花费的时间显著减少。这使我们能够做出更高层次的产品决策，例如提供哪些关键功能、用户界面需要改进等。
开发者反馈循环在几分钟到几小时的时间间隔内运行——这是开发者可能审查产品并提供反馈的频率。在打字应用的案例中，我多次改变主意关于视觉设计、她可以通过学习解锁哪些猫咪服装（她喜欢猫），以及成人登录并引导孩子学习体验的用户流程。
当开发者对要构建的内容有清晰的愿景时，将愿景转化为编码代理可实现的规格仍然是一项工作。此外，在看到实现后，开发者可能会更新（或澄清）规格以引导其朝向目标。如果你发现系统反复遇到某些问题，为代理构建一组评估数据集会很有用。
越来越多的AI原生团队开始使用AI来帮助塑造产品方向，例如自动收集和分析使用数据、总结书面和口头客户反馈，或进行竞品分析。然而，对于我参与的大多数产品，我认为人类在上下文方面具有显著优势——我们比AI系统知道更多关于用户和产品运行环境的信息——因此人类在其中扮演着关键角色。许多人将这种人类贡献描述为“品味”，但我更倾向于认为是人类拥有上下文优势，因为这为帮助AI系统提升提供了更清晰的路径。这也说明了为什么这一步不能自动化：只要人类知道AI不知道的信息，就需要人在环中注入这些知识。
外部反馈循环：这包括各种策略，如向朋友征求反馈、向α测试用户发布，或将代码投入生产环境进行A/B测试。这些策略通常较慢，很少在几小时内完成，有时需要几天甚至几周。这一数据反馈给开发者的愿景，进而继续驱动详细的产品规格，最终驱动编码代理。
随着编码代理加快软件开发速度，越来越多的工程师开始扮演部分产品管理角色。对于许多正在成长为此角色的工程师来说，最难的部分是塑造产品愿景，并在构建（弥补愿景和规格之间的差距）和获取用户反馈以演化愿景之间找到平衡。两者都很重要！
我将在未来的文章中更多地讨论如何做到这一点，但目前我发现，工程师扮演着扩展角色（就像产品经理和设计师现在做更多工程工作一样）是令人鼓舞的。
[原文：The Batch]
展开原文
“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]
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]
❤ 8.2k · 🔁 1.6k · 💬 351 · 👁 56.8w
热门回复 4
@AvaGrace_AI @AndrewYNg 智能循环释放产品创造力和动力。
@AndrewYNg Smart loops unlock product craft and momentum.
@ElleiraGF @AndrewYNg 我觉得这有些过度解释了。为什么要将开发者循环和外部反馈循环放入循环工程的背景下呢？难道我们在“循环工程”之前不就已经有这两个循环了吗？我们只是没有特别将它们称为“循环”而已。将它们合并并不会提供更多见解。
@AndrewYNg I feel it is over explained. Why putting the developer loop and external feedback loop into the loop engineering context? Isn’t that we have these two loops before the “loop engineering”? We just don’t call it specifically as “loop”. Put them together doesn’t give more insight.
@JiangL17208 @AndrewYNg 老实说，内循环是魔法发生的地方（也是计算账单的主要来源）。大家都关注外层反思步骤，但开发者循环才是区分‘氛围编码玩具’和真正可投放产品的关键。
@AndrewYNg honestly the inner loop is where most of the magic (and most of the compute bill) happens. everyone focuses on the outer reflection step but the developer loop is what separates vibe-coded toys from stuff that actually ships
@NimishaChanda @AndrewYNg 得知这些循环知识是这周的事，作为一个从未考虑过此类问题的非技术人员，这真是一种诅咒。顺便说一句，好文章。每天都在学习新东西。
@AndrewYNg got to know about the loops - this week and it's a curse to be a non-tech person who never thought of any such thing. gread read, btw.
learning something new everyday.
learning something new everyday.