人的判断并未离开软件工厂，它只是转移了位置。

软件工厂是围绕软件工作的一个可重复循环。如果你正在构建软件工厂，那么即使是已经足够可以发布的代码，仍然需要人的品味和责任感。我们将讨论这一点，包括你是否现在就需要一个工厂。A software factory is a repeatable loop around software work. If you’re building a software factory, code good enough to ship still needs human taste and ownership. We’ll discuss this including whether you need a factory just yet.

如果是这样：If so:

• 你很可能需要在前期引入人工参与，以决定产品意图、系统设计（如果你在意的话）以及你的质量标准。

  You’ll likely need humans in the loop upfront for deciding on product intent, system design (if you care) and your quality bar.

• 要进行代码审查（灯亮工厂），但要有针对性地把精力放在最需要的地方。我发现你需要留意自动化反压失效的地方，或者需要在可维护性上做出取舍的地方。

  Do review code (lights-on factory) but be intentional with where it’s needed the most. I’ve found you want to watch out for where automated back-pressure breaks. Or where maintainability trade-offs need to be made.

• 尽量让质量检查尽早并尽可能持续地进行。并非所有检查都必须如此，但这包括类型系统、自动化测试、变异测试、安全扫描器以及针对架构规则的 lint 检查。

  Aim for quality checks to happen as early and continuously as possible. Not all of them have to, but this includes type systems, automated tests, mutation testing, security scanners and linting for architecture rules.

• 检查次数不等于质量。你很可能需要尝试不同的检查方式，找出能给你带来最佳信噪比的方案。要准备好有意识地收紧或放宽你的约束。

  Number of checks != quality. You’ll likely need to experiment with what checks give you the best signal to noise ratio. Be ready to tighten or relax your constraints deliberately.

你希望构建你的工厂，使人类品味的某些方面被编码进环境中，智能体会向你提供其工作正确的证据，以及人类仍然“拥有”哪些会被部署到生产环境中的内容。You want to build your factory so some aspects of human taste get encoded in the environment, the agent gives you evidence of its work being right and where a human still “owns” what ships to production.

你真的需要一个软件工厂吗？Do you really need a software factory?

根据我的经验，你用现成的编码框架其实能走得相当远！也就是 Claude Code 或 Codex，多个会话，带有内置验证和约束的高质量 SPEC。你甚至可以把一批 GitHub issue 丢给它们，并附上实现和人工介入标准，但当这个系统需要可重复、事件驱动时，工厂就会很有帮助。In my experience, you can get surprisingly far with your stock coding harness! i.e. Claude Code or Codex, multiple sessions, good SPECs with verification baked in and constraints. You can even throw a batch of GitHub issues at them with implementation and human-involvement criteria, but it’s when this system needs to be repeatable and event-driven that a factory is helpful.

所以我一开始说，软件工厂就是围绕软件工作的一个可重复循环。我们实际上可以看一个提示词，它在这里展示了一个非常小的工厂循环：So I started off by saying a software factory is a repeatable loop around software work. We can actually look at a prompt that demonstrates a very small factory loop here:

Read GitHub issue #123 and the repository instructions before changing code.

Implement only the stated acceptance criteria. Do not modify authentication,
billing, migrations, or existing test assertions. Work in a branch and keep the
diff reviewable.

Run npm run lint, npm test, and npm run build. If a required check cannot run,
stop and explain why. Open a draft pull request with the checks you ran, the
remaining risks, and any decision a human still needs to make. Do not merge.

一个目标可以让这个流程持续推进，直到检查通过；我们还可以每天早上轮询 GitHub issues，查看任何特定标签，或者审查开放的 pull requests。分支保护可以强制执行合并边界，而人类可以通过选择哪些内容变为就绪、进行审查并做出最终合并决定等方式保持在流程中。A goal can keep this moving until the checks pass and we can poll GitHub issues for any specific labels or review open pull requests each morning. Branch protection could enforce a merge boundary and the human can stay in the loop by choosing what becomes ready, reviewing and making the final merge calls etc.

当你需要一个事件驱动的工作队列（例如 Slack 触发、GitHub issues、Linear、待办积压）在隔离的云环境中运行，以便在有人明确看护的情况下处理分诊、实现和测试时，可以添加一个软件工厂。有些流程会以一个监控代理结束，由它监视生产环境并提交问题，然后再进行分诊。Add a software factory when you need an event-driven queue of work (e.g. Slack triggers, GitHub issues, Linear, a backlog) to run in an isolated cloud environment to handle triage, implementation and testing with some explicit human babysitting. Some end their loop with a monitor agent watching production and filing issues which triage again.

根据我的经验，当难点在于让不同运行保持一致行为、在代理之间交接工作、避免不同会话认领同一个问题、保留证据，以及在人为审查跟不上的时候停止生产时，工厂就变得有用了。In my experience, the factory becomes useful when the hard part is making your different runs behave consistently, handing work off between agents and avoiding different sessions from claiming the same issue, preserving evidence and stopping production when human review is falling behind.

解决这个问题的方法听起来可能有点无聊。比如，Warp 提到会把每个新进来的 issue 分流到四种状态之一——ready-to-implement、ready-to-spec、needs-info、wait-to-implement——而标签就是触发下一个 agent 的东西。What solves this might sound a little boring. For example, Warp mention triaging every incoming issue into one of four states - ready-to-implement, ready-to-spec, needs-info, wait-to-implement - and the label is what fires the next agent.

这个标签一次承担了几项工作：它既是队列，也是锁，而且由于一个会话只会取走标记为就绪的内容，所以人也可以把东西先放在这里，而不必永久拒绝。This label does a few jobs in one go: it’s the queue, the lock and since a session only picks up what’s marked ready, it’s where a human can park stuff without saying no permanently.

从工作流程上看，与仅使用 Claude/Codex 相比，有一些相似之处和不同之处：Workflow wise, there are a few similarities and differences to just using Claude/Codex:

• 引导：代理需要纠正方向时，你可以提供输入并将其重新引导

  Steering: agent needs course-correction, you can give input and redirect it

• 通知：工厂如何表示它被阻塞了。这可能是因为某个要求含糊不清，它启动了某些有风险的事情，或者它需要人工输入（引导）

  Notifications: how the factory says its blocked. This can be because a requirement was ambiguous, it started something risky or it needs human input (steering)

• 交接：在云工厂/另一个代理/人工审阅者之间转移任务、其状态和上下文。良好的交接会记录已经发生了什么、还需要完成什么，以及为什么需要进行交接。

  Handoff: move the task, its state and context between the cloud factory/another agent/human reviewer. Good handoffs will keep track of what happened, whats left to be done and why the handoff is needed.

在一个好的工厂里，人类并不只是在最后阶段审查并批准最终的 diff。他们可以在早期塑造工作，在实施过程中引导它，推动它完成交接，或者阻止它发布到生产环境。In a good factory, the human isn’t limited to just reviewing and approving the final diff at the very end. They can shape the work early on, steer it during implementation, get it through a handoff or stop it shipping to production.

验证是负责任的工厂会花费大量时间的地方。我们稍后会更详细地讨论这一点。Verification is where a responsible factory spends a lot of its time. We’ll cover this more later.

如果你决定确实需要一个软件工厂，搭建它并不是唯一的选择。为扩展一个工厂而建立基础设施可能会非常费工夫，你也许需要考虑买现成的而不是自己构建。Factory、Warp 和 HumanLayer 都在做这方面的工作。If you decide you do need a software factory, building it isn't the only option. Standing up the infra to scale a factory can be a lot of work and you may want to consider buying vs. building. Factory, Warp and HumanLayer are all working on this.

我现在的一天是这样的What my day looks like now

过去一年里，我对软件开发的日常体验发生了很大变化。我一直在谈越来越多地与智能体并行开展大量工作，朝着建立一个全天候运转的软件工厂迈进。很多人一直在问我，比如，这些到底是什么意思？你在构建什么？你会把这些东西用在什么样的项目上？大致就是这样：My day-to-day experience of software development has changed a lot over the past year. I’ve been talking about increasingly doing a lot of parallel work with agents, moving towards having a lights-on software factory. And a lot of people have been asking me, like, what do these things actually mean? What are you building? What are the kinds of projects that you’re using these things on? It’s a lot of this:

所以在一个非常普通的日子里，我会有一个更简单的、开着灯运转的软件工厂。我可以有一些在云端运行的任务。其中一半任务可能是在处理生产环境中的客户端应用，这些应用来自我合作的一些小公司。它们会有真实用户，会有真实的身份验证、支付、订阅，以及你需要小心应对的、非常严峻的风险。你不能只是说，哦，代理，去把这些事情做了吧，而不先建立好测试、约束和质量检查。So on a very average day, I have a simpler lights-on software factory. I can have tasks that are running in the cloud. Half of these tasks might be working on production client applications with smaller companies that I’m working with. They’re going to have real users. They’re going to have real authentication, payments, subscriptions, real beefy risks that you need to be careful with. You can’t just say, oh, agent, just go and do this stuff without having tests and constraints and quality checks in place.

我可以做我的开源项目。我可以为我的书搭建配套网站。我可以开发工具。我可以构建我自己的应用。而且这些都是我在做的、非常非常不同类型的应用。有时候它们唯一的共同点，可能只是我用来开发它们的工具，对吧？也许我在做一次迁移。其他时候，我可能在做真正大量的功能开发。而且这项工作的影响范围也可能非常非常不同。I could work on my open source projects. I could be building out companion sites for my books. I could be working on tools. I could be building apps of my own. And these are all very, very different kinds of applications that I’m working on. And sometimes all they have in common is the tool that I’m using to work on them, right? Maybe I’m working on a migration. Others, I might be doing actual beefy feature work. And the blast radius of the work might also be very, very different.

因此，当你开始思考如何达到这样一个阶段：我们越来越多地并行开展大量工作，我们试图提升速度，我们试图提高生产力，我们也试图增强自主性——这意味着要把系统推进到一个我们更信任它的状态——你确实必须思考，哪些地方绝对需要人工代码审查和人工介入。So as you begin to think about getting to a place where we’re increasingly doing a lot of parallel work, we’re trying to improve velocity, we’re trying to improve productivity, and we’re trying to improve autonomy, which means getting the system to a place where we trust it more, you do have to think about what are the places that absolutely require human code review, human input.

而且其中很多工作都需要在前期完成，对吧？当你在定义你的规格、你的需求时，产品的设计会是什么样子？产品的意图会是什么样子？然后你又如何验证这些代理实际上已经把工作正确完成了？你如何验证他们没有破坏现有的系统？你如何确保它达到了你的质量标准？And a lot of that is going to be required up front, right? When you’re defining your specification, your requirements, what is the design of the product going to look like? What is the intent of the product going to look like? And then how are you verifying that the agents have actually gotten the work done right? How are you verifying that they haven’t broken the existing system that has been in place? How are you making sure that it’s meeting your quality bar?

因此，生成代码未必是你最需要担心的部分。只要有足够的上下文，智能体就可以为我们编写实现、运行测试、检查失败并修改代码。我们需要达到这样一种状态：环境中已经编码了足够多的人类品味，让我们能够信任正在构建的东西，这样我们的人的注意力就可以集中在最需要它的地方。And so generating code is not necessarily the part that you need to worry about the most. Given enough context, agents can write the implementation and run the tests and inspect failure and revise code for us. We need to get to a place where we feel like there is enough of human taste encoded in the environment that we can trust what is being built, so that our human attention can be focused on the places where it’s needed most.

现在，有些人提出反对意见，说，嘿，我不认为你能把很多这类工作都自动化掉。并不是说我们要把所有东西都自动化掉，对吧？但考虑到生成的代码量，我认为让人类把所有代码都读一遍并不现实，尤其是在很多时候我们并不是在造火箭，对吧？我们在构建 UI，我们在构建全栈应用。Now, there is pushback from folks saying, hey, well, I don’t buy that you can just automate away a lot of this stuff. It’s not to say that we’re automating away all of it, right? But given the volume of code that’s being generated, I don’t think that it’s realistic for humans to be reading all of it, especially when we’re not building rockets a lot of the time, right? We’re building UI, we’re building full stack applications.

我们的判断力、我们的品味，最好集中在最需要它的地方。比如，系统里最有风险的部分是什么？我们需要把人的品味应用到哪里？这可以是在前端，也可以是在系统的运作方式上。没必要覆盖 100%。Our judgment, our taste is best focused on the places where it’s needed the most. Like, what are the riskiest parts of the systems? Where do we need to apply human taste? And that can be in the front end. That can be in how the system works. It doesn’t have to be 100% of it.

我的认知带宽不会随着代理数量而扩展My cognitive bandwidth does not scale with the agents

现实情况是，没错，我们现在可以并行启动几十、几百、几千个代理，但你自己的认知带宽并不会以同样的方式扩展。这会导致我之前提到过的认知债务或理解债务。The reality is, yes, we can now fire up dozens, hundreds, thousands of agents in parallel, but your own cognitive bandwidth does not scale in the same way. This can feed into cognitive or comprehension debt which I’ve talked about before.

如果你回想五年、十年前，工程界曾经有很多关于上下文切换及其成本的讨论。我们会谈到，人们多么讨厌在自己正忙着做某项任务时，同事或别人走到你的桌前来打断你。然后你就要花很长时间才能重新进入心流状态，因为你得重新找回思路，比如：我刚才做到哪了？我在做什么？即使你脑子里还留有一点印象，还是会花时间。If you remember back to just five, ten years ago, there was a lot of discussion in the engineering community about context switching and the cost of it. We would talk about how people hated when a colleague or someone would walk up to your desk when you were in the middle of a task. It would then take you so long to get back into your flow state because you had to catch back up in terms of like, where was I? What was I doing? Even if you had a little bit of residue there, it still took you time.

我们现在的上下文切换比以前还要多。任何一天，如果我不在软件工厂里工作，我可能会同时和代理一起处理五到十个不同的项目，或者在同一个项目上同时处理五到十个不同的功能。你可以说，我实际上可以同时有五到十个不同的会话。We’re now context switching even more than we did before. On any given day, if I’m working outside of a software factory, I can be working on five or ten different projects with agents at a single time, or five or ten different features on a single project at a time. I can have five or ten different sessions, you can effectively say.

这意味着我必须能够至少持续跟进其中的几项。如果我有信心自己已经把任务定义得足够清楚，已经定义了结果，以及它将如何验证是否完成得足够好，那么我有可能提高我赋予某些任务的自主性。但也会有一些任务，我可能并不一定有这种感觉，而且其中涉及更多风险或更多细微差别。我就必须加以留意。That means that I have to be able to stay on top of at least a few of those. It is possible that I’m going to be able to increase how much autonomy I give some tasks if I have trust that I’ve defined the task well enough, I’ve defined the outcome, how it’s going to verify that it’s done well enough. But then there are going to be tasks where maybe I don’t necessarily feel that way and there’s more risk involved or more nuance. I’m going to have to pay attention.

考虑为你的审阅者优化软件工厂。鉴于这些方法中的每一种最终都还是把输出交到一个人的注意之下，你应该问问，这个工厂到底让你仍然必须做出的那些决策便宜了多少。Consider optimising the software factory for your reviewer. Given every one of those approaches still routes its output to one person's attention, you should ask how much cheaper the factory is making the decisions you still have to make.

一个项目错误的失误A wrong-project mistake

我记得我和我的代理一起并行处理多个项目的时候，有些时候我会不小心做出这样的事：比如我在做一个网页应用，想给它加上深色模式，所以我脑子里已经想好了，嗯，这个功能的结构应该长这样。但我不小心切到了另一个项目的会话里，然后我开始输入同样的提示。I remember when I’ve been working on multiple parallel projects with my agents, and there have been times when I’ve accidentally done things like, maybe I was working on a web app where I wanted to add in a dark mode, and so I had in my head, okay, well, this is what the shape of this needs to look like. But I accidentally went to the session for a different project, and I started putting in that same prompt.

所以我开始为一个完全不需要它的东西实现深色模式。这样我就会犯那个错误。我不希望我的软件工厂犯这种错误。So I began implementing dark mode for something that absolutely didn’t need it. And so I can make that mistake. I don’t want my software factory making that kind of mistake.

你需要真正从系统的角度来思考这件事。你实际上是在试图把一种软件工程文化、一种团队文化编码进一个系统里，使它具备同样的行为方式，使它有归属到某个地方的责任，使仍然有人对发生的事情负责，而且你要非常明确地表达你是如何看待这些事情的。You need to think about this really in terms of a system. You are effectively trying to encode a software engineering culture, a team culture, into a system so that it has those same kinds of behaviors, so that it has ownership that belongs somewhere, so that someone is still on the hook for what happens, and you’re being very explicit about how you think about those things.

当绿色具有误导性When green is misleading

即使在这些系统里，你也要非常小心，对吧？我们很多人都见过，当你让 AI 帮你通过一个测试时，比如我们说的是编程测试、单元测试，它可能会修改单元测试来满足那个条件，或者它可能会改变代码逻辑来通过那个条件。但这并不意味着它真的按照你的意图去做了，从而同时对齐功能行为以及测试本来应该验证的内容，对吧？Even in these systems, you want to be very careful, right? Many of us have seen that when you have asked AI to help you pass a test, like we’re talking about a programming test, a unit test, it can change the unit test to satisfy that condition, or it can change the logic of the code to pass that condition. That doesn’t mean that it’s actually followed your intent in order to align both the functional behavior and what the test was supposed to be testing, right?

仅仅因为一个软件工厂显示一切都是绿色，并不意味着它实际上就是绿色的，尤其是在一开始你搭建这些东西的时候。你需要非常注意，确保你的检查、你的验证，以及所有这些，都以正确的方式构建。它们要按你期望的方式运行。你不希望它们产生误导。Just because a software factory is showing that everything is green doesn’t mean that it’s actually green, especially at the start when you’re setting these things up. You need to pay a lot of attention to make sure that your checks, your verifications, all of those are shaped the right way. They’re doing what you expect them to be doing. You don’t want them to be misleading.

你不希望出现这样的情况：测试告诉你，嘿，其实我已经改了支持哪些认证提供商。比如你让我添加 GitHub 作为认证提供商，但嘿，我的界面只够放三个，所以我就删掉了另一个。顺便说一句，那个被删掉的恰好是你的客户真正想要的那个。所以你只需要非常明确地说明你希望这些系统如何工作。You don’t want a situation where you had tests that said, hey, actually, I have gone and changed what authentication providers are supported. You asked me to add GitHub for example, as an authentication provider, but hey, my UI only had space for three, so I’ve gone and I’ve dropped one of the other ones. And hey, by the way, that happened to be one that your customers actually wanted. So you just need to be very explicit about how you want these systems to work.

顺便说一下，安全也非常重要，而且如果你的工厂会读取不可信输入，比如 GitHub issue/Slack 消息，那它可能是对抗性的，并包含供应链攻击之类的问题。所以，一些对软件工厂的探索，比如 Vercel，会把它们的 agent 运行在隔离的沙箱中，只保留某个任务所需的秘密。这样，即使某次运行被攻破，也无法接触到该作业不需要的内容。你的防御最终会变成分层的。Btw security is super important too and if your factory reads untrusted input like a GitHub issue/Slack message it might be adversarial and include problems like supply chain attacks. So some explorations into software factories, like Vercel, run their agents in isolated sandboxes holding just the secrets a task needs. That way a compromised run can’t reach what the job doesn’t need. Your defense ends up being layered.

哪些旧项目值得重获新生？Which old projects deserve another life?

我也认为，如今我们工作方式的很大一部分，就是决定什么应该存在。回想很多年前，在 AI 出现之前，有那么多被搁置的软件工程项目，那么多被搁置的周末项目、个人项目，它们就是无法发布，因为我们没有时间把它们做完。我们没有足够的精力去优先把它们推向市场，因为它们对我们来说并没有那么重要，或者我们找不到时间。I also think that a big part of how we work these days is deciding what should exist. If you remember back to many years ago before AI, there were so many abandoned software engineering projects, so many abandoned weekend projects, personal projects where they just wouldn’t launch because we didn’t have the time to finish them. We didn’t have the bandwidth to prioritize getting them out the door because they just weren’t that important to us or we couldn’t find the time.

现在我们完成这些项目已经相当容易了，但同样会出现人类判断的问题。这些项目值得存在吗？它们应该被推出吗？因为一旦你把它们发布到世界上，即使只有五个用户，你也可能必须维护它。也许你现在有一个想要维持的质量标准。Now it’s fairly trivial for us to complete those projects, but the same human judgment question comes in. Do those projects deserve to exist? Should they be launched? Because you put them out into the world and even if it has just five users, maybe you have to maintain it. Maybe you have a quality bar now that you want to maintain.

我知道这些年来我有很多 GitHub 项目，现在有了一个代理后，我做的第一件事就是先把它构建起来。因为，当然，你把它克隆下来后，它现在却构建不了，因为所有依赖都已经变了。差不多一半的东西都过时了，或者到处都有安全漏洞，所以你得把这些更新掉。I know that I’ve had so many GitHub projects from over the years where now that I have an agent, the first thing I do is get the thing building. Because, of course, you clone it and now it doesn’t build because all the dependencies have changed. Half the things are out of date or have security vulnerabilities all over them, so you have to update that.

然后，如果你之前没有测试，就必须补充测试，这样你就能知道，在以某种方式升级项目，或者把它迁移到更现代的语言、框架之类的东西时，这种行为至少还会存在。Then you have to add tests if you didn’t have tests so that you know that behavior is at least going to be there if you’re upgrading the project in some way, or if you’re migrating it to a more modern language or framework or thing like that.

然后你开始问自己，嗯，也许举个有点傻的例子，但也许我当年为这个用了 Twitter Bootstrap，可现在大家都在用 Tailwind 和 shadcn，所以我得重新实现这个 UI。你会发现，突然之间这就花了你更多时间，对吧？是的，agent 确实能更快地完成很多这些工作，但你现在还必须把产品感觉、审美以及所有这些因素都考虑进去。Then you start to ask yourself, well, maybe, a silly example, but maybe I used Twitter Bootstrap back in the day for this, but now everybody is using Tailwind and shadcn, so I have to re-implement the UI. And what you’ll notice is that suddenly this is taking you more time, right? Yes, the agent can get a lot of this done quicker, but you’re now having to factor in product sense and taste and all of these things.

你还是会问，好吧，这到底是给谁的？它有市场吗？是给我自己的吗？是给其他人的吗？如果我要把它发布到世界上，考虑到现在任何人都能这么快把这些东西搭建起来，它还会一样有趣吗？You still question, well, who is this for? Does it have a market? Is it for myself? Is it for other people? If I’m putting it out into the world, is it still going to be as interesting given that now anybody can spin these things up as quickly?

所以我认为，人类的问题是：这些东西值得存在吗？我们该如何把我们的品味和判断纳入考量？我觉得这些东西仍然极其重要。人类注意力这种稀缺资源，真正还是在这里发挥作用。过去，我们一天只有有限的时间。我们要开会。我们必须为设计、编码等等预留时间。So I think that human question of do these things deserve to exist? How do we factor in our taste and judgment? I feel like those things continue to be extremely important. That’s where that scarce resource of human attention still really comes in. Back in the day, we only had a finite number of hours in the day. We had meetings. We had to budget in time for design and coding and so on.

现在我们有了代理来帮助我们，我认为你真的必须非常明确地说明你把时间花在了哪里，以及为什么。Now that we have agents to help us, I think that you have to really just be very explicit about where you’re spending your time and why.

当我构建一个示例时发生了什么What happened when I built a sample one

所以我要讲一下这次 82 分钟的工厂运行。很长一段时间以来，人们一直在问我，你知道，“我该怎么搭建一个软件工厂？”或者，“我已经习惯使用 Claude Code 或 Codex 了。我该如何把我的配置升级为使用软件工厂？”So I’m going to talk about the 82-minute factory run. People have been asking me for quite some time, you know, “How do I build a software factory?” Or, “I’m used to using Claude Code or Codex. How do I evolve my setup to using a software factory?”

所以我一直在说的第一件事是：“你可能没问题。你的工作实际上可能完全没问题，不需要工厂。”但我确实想给大家提供一个可以参考的配置，方便他们去看看。所以我整理了一个名为 Factory 的仓库，你可以去查看。我还做了一个演示应用和一个工作坊。So the first thing that I’ve been saying is, “You may be fine. Your work may actually be totally fine without needing a factory.” But I did want to give people a reference setup that they can check out. So what I put together is a repository called Factory that you can go and check out. I also put together a demo application and workshop.

在过去几年里，我很多事情的首选演示应用一直是一个电影应用。我是个非常喜欢电影的人。我喜欢看电影，我一直都在看电影，所以我有一个演示应用，它最初其实只是一个非常简单的电影应用。而我希望工厂能够做的，就是继续去实现一些功能。有几个不同的功能。我想要一个收藏功能。我希望它也许能够支持搜索，而且我可能还想要一个深色主题之类的这些功能。Now, for the last couple of years, my go-to demo application for a lot of things has been a movies app. I’m a big movies fan. I love watching movies. I watch movies all the time, and so I have a demo application, which really starts off as a very simple movies app. And what I want the factory to be able to do is go ahead and implement a number of features. There’s a few different features. I want a favorites feature. I want it to be able to maybe do search, and maybe also want a dark theme in there as well, those types of things.

所以我让我的工厂开始处理这些东西。你可以看看实现。它的一个好处其实是能捕捉到真实问题。如果我只是让它一次性实现，可能就不会发现这些问题。So I have my factory go and begin working with these things. You can check out the implementation. One of the benefits of it was actually catching real problems. These problems may not have been things that I would have caught if I had just asked it to do a one-shot implementation.

也许在 60 分钟左右的时候，我感觉“哇，这进展得异常慢。”我通过工厂问我的 harness：“为什么事情进展得这么慢？”它说：“其实完全没问题。所有的 verifiers 还在运行。”Maybe around the 60-minute point, I was feeling like, “Wow, this is going unusually slow.” I asked my harness using the factory, “Why are things going slow?” It said, “This is actually totally fine. All the verifiers are still running.”

你可能原本以为单个任务只需要 10 分钟、15 分钟、20 分钟，但一旦开始把验证、重试、浏览器检查、人工审核以及这些额外延迟都算进去，它们可能会花费两到四倍的时间。You might have expected individual tasks to take 10 minutes, 15 minutes, 20 minutes, but they can take two to four times as long once you begin to include verification, retries, browser checks, human review, any of those extra delays.

我确实认为，这些可以累积起来，带来更好的质量和对系统更高的信任。从衡量的角度来看，你可以把每个合并 PR 的成本和代码保鲜期之类的指标，视为理解债务指标。I do think that these can add up to better quality and better trust in the system. From a measurement perspective, you might look at metrics like cost per merged PR and code shelf life as comprehension debt metrics.

你还需要思考什么是有用的延迟，什么是工厂开销。就我而言，验证器确实发现了一些真正的问题。有一部分时间也许是花在生成我想要的证据上了。其中一些则是工厂运行中的开销。我其实并没有花任何时间去优化它，但一个只是运行大量你并不觉得有价值的检查的工厂，并不意味着它就是高质量的。You also need to think about what is useful delay versus factory overhead. The verifiers, in my case, caught some real problems. A little bit of the time was maybe sunk into producing evidence that I wanted. Some of it was overhead in the factory running. I didn’t really spend any time optimizing it, but a factory that just runs a lot of checks that you’re not finding valuable does not mean it’s a high quality one.

你想研究的是，对于任何重复检查，它们是否无关紧要？它们是否只是噪音？它们是否真的让系统更安全？You want to study how, for any repeated checks, are they irrelevant? Are they noisy? Are they actually making the system safer?

验证预算A verification budget

我对验证预算的理解，基本上就是我们现在在谈的这个东西。我们谈的是一个验证预算。我对它的看法，和我过去看待性能预算的方式是一样的。The way that I think about the budget for verification, this is basically what we’re talking about. We’re talking about a verification budget. I think about it in the same way as I’ve historically thought about performance budgets.

在软件开发生命周期的早期，你可以运行某些类型的检查；而有些检查虽然非常耗时，但它们能带来极高的价值，因此你会希望在后期再运行它们。有一些快速检查，例如 linting、类型检查。这些都是相对较快、可以在早期运行的检查。There are going to be certain kinds of checks that you can run early on in your software development lifecycle, and there are going to be some things that are so heavy, but they offer so much value that you will want to run them later on. There are some kinds of fast checks, linting, for example, type checking. These are relatively fast checks that you can run early on.

我们完整的测试套件可以在草拟 PR 即将整理完成之前或之后更接近地运行。这可以包括变异测试、浏览器测试、安全检查，以及类似的内容。Our full suite of tests can be run closer to right before a draft PR is being put together or after that. That can include mutation testing, browser testing, security checks, anything like that.

我认为你不一定想把这些都替换成仅仅是摘要。你想要真正的测试，但你只需要确保把它们的预算安排在正确的地方，因为你不想拖慢你的开发循环。我当然从不想拖慢我的开发循环。保持快速的迭代循环对我很重要，但我也希望仍然保留那些制衡机制。I think that you don’t necessarily want to replace these with just summaries. You want real tests, but you just need to make sure that you’re budgeting for them in the right places because you don’t want to slow down your development loop. I certainly never want to slow down my development loop. Having a fast iteration loop is important to me, but I also want to still have those checks and balances.

当一次运行没有发布时When a run doesn’t ship

我上面写的很多内容都涉及这些检查。A lot of what I’ve written above concerns the checks.

在他们的软件工厂里，Vercel 会把每次代理运行标记为“成功”、“有缺陷”、“受阻”或“人工处理”，只有“成功”才会发布到生产环境。其余的会重新进入系统。我一直在用类似的方式思考这些运行。In their software factory, Vercel marks every agent run as “success”, “flawed”, “blocked” or “manual” and only “success” ships to production. The rest re-enter the system. I’ve been thinking about runs in similar terms.

“有缺陷”在这里是指实现了错误的东西，或者可能没有完整的上下文，所以必须修复。Blocked 表示环境可能缺少某个凭据，因此你需要提供它。Manual 是一个边界，工厂可能还不被允许越过它。“Flawed” here means the wrong thing was implemented or maybe it didn’t have full context, so that has to be fixed. Blocked means the environment may have been missing a credential so you have to provide it. Manual is a boundary the factory may not be allowed to cross it yet.

这里的三件事中有两件可能有机械性的修复，而最后一件关乎信任。Two of the three things here may have mechanical fixes and the last one is about trust.

虽然这很好，但排序没有显示给你的是成本。BWhile this is great what sorting doesn't show you is cost. B

回到我在 TMDB 应用中的工厂实现，那个没有任何拒绝的快速查找花了 7 分钟。收藏项，经历了两次拒绝和中间一次人工决策，花了 56 分钟。都是同一个工厂。所以我会把分类法和各阶段计时配对起来，否则你只知道一次运行结果有问题，却不知道查明问题花了多少成本。另一件我会修正的是边界处的交接：我的示例工厂在第一个问题上停止，并把它移到 factory:needs-info，这本身是对的，但我不知道该把我的回答放到哪里。一次人工运行并不是在工厂停止时结束，而是在人工知道下一步该做什么时才结束。ack to my factory implementation with the TMDB app, the quick finder with no rejections took 7 minutes. Favorites, with two rejections and a human decision in the middle, took 56. Same factory. So I'd pair the taxonomy with per-stage timing, otherwise you know a run came back flawed without knowing what finding out cost you. The other thing I'd fix is the handoff at the boundary: my sample factory stopped issue the first issue and moved it to factory:needs-info, which was right, but I didn't know where to put my answer. A manual run isn't finished when the factory stops but when the human knows what to do next.

自主性不是单一设置Autonomy is not a single setting

我在几周前写了一篇关于智能体自主性以及如何看待自主性的文章，因为自主性不会是适用于每个项目的单一设置。I wrote a couple of weeks ago an article about agentic autonomy and how to think about autonomy because autonomy is not going to be a single setting for every single project.

验证能为你赢得信任，也能让你有能力赋予你的代理更多自主权。所以，比如说，如果我正在处理一个非平凡的改动，但我已经设置了多项检查，一切都能正确通过验证，而且也许我自己还手动检查过。下次我在同一个项目里再做类似的任务时，也许我就会更放心地给代理多一点自主权。Verification buys you trust, and it buys the ability to grant more autonomy to your agents. So if, for example, I am working on a non-trivial change, but I have a number of checks in place, everything gets verified correctly, and maybe I’ve hand checked it myself. The next time I’m going to do a task like that in the same project, maybe I’ll feel comfortable giving the agent a little bit more autonomy.

这就是你在构建这些软件工厂时会想到的事情。你的验证会随着风险而变化。你的目标是获得最佳的信噪比。你不只是想有一份很长的检查清单去执行。That’s the thing that you think about when you’re building these software factories. Your verification is going to change with risk. Your goal is the best signal to noise ratio. You don’t just want to have some large checklist that you’re running.

我不得不重新学习的功能The feature I had to relearn

有一个功能我一直拖着没做，那天我同时在用 Claude 的多个会话，而且我一次在处理几个不同的项目，每个项目又同时在做几个不同的功能。于是 Claude 实现了我正在做的那个功能。看起来测试都通过了。我并没有花很多心思去做验证，但测试通过了，所以我以为它是可用的。我就把它合并了。There was a feature that I’ve been putting off on a day when I’ve been using multiple sessions with Claude, and I was working on a few different projects at a time, a few different features at a time per project. And so Claude had implemented the feature that I was working on. It looked like the tests were passing. I hadn’t put a lot of thought into verification, but the tests passed, and so I thought it worked. I merged it.

所以这是一个收藏功能。我觉得这其实挺不错的。我试着在浏览器里看了一下。看起来还可以，但几天后，我又回到代码里，因为我觉得这里还有一些地方可以调整。And so this was a favoriting feature. I thought that this was actually pretty good. I tried to check it out in the browser. It seemed like it was okay, but a couple of days later, I actually returned to the code because there were some tweaks that I thought I might make to this.

我不想只是让我的代理去做这些改动，因为它的工作方式只是有点微妙。你点一下图标，它在点击时不会显示正确的效果，所以我想稍微调整一下。我想弄清楚它是怎么工作的，这样我就能正确地指导我的代理。I didn’t want to just ask my agent to make the changes, because it was just a subtle way that it worked. You tap on the icon, and it would not show the right effect on tap, and so I wanted to just tweak it. I wanted to understand how it worked so I could guide my agent correctly.

我回到代码里，却没法向你解释这个功能是怎么工作的。这个仓库是我的，对吧？我批准了这次改动。我理解其中很多部分是怎么工作的，仓库里的很多东西我都懂，但我的理解已经跟不上不断堆积起来的那些代码了。I returned to the code, and I couldn’t explain to you how the feature worked. This repository was mine, right? I’d approved the change. I understood how a lot of it worked, a lot of the repo worked, but my understanding hadn’t kept up pace with all of the code that had been building up.

我没能理解的是，这个新增的功能实际上是如何工作的，UI 是如何工作的，以及它对 UI 的影响是怎样的。我不得不重新做这个功能，并且真的一步一步来，“这是怎么运作的？我该怎么理解它？”What I failed to absorb was how this feature that had been added actually worked, how the UI worked, how the effect on it worked. I had to redo this feature and actually go step-by-step, “How does this work? How can I understand it?”

并行工作对理解的影响What parallel work does to understanding

当你在进行并行工作时，这会放大整个问题；而当你在软件工厂里这样做时，这种放大效应会更明显。当你同时进行五个或十个会话时，它们带来的不只是评审量的问题。它们会形成多个心智模型，而当你在别处工作时，这些模型最终可能会变得相当冷却。When you’re doing parallel work, it amplifies this overall problem, and it gets even more amplified when you’re doing it in a software factory. When you’re doing five or 10 sessions, they create much more than just a review volume problem. They create several mental models that can end up going pretty cold while you’re working elsewhere.

我们过去一直在谈论上下文切换带来的挑战，而一旦聊天被压缩，你就会排除某些方法，尝试不同的东西，你在和代理结对协作时，要想记住会话中发生的所有事情会很困难。We’ve historically talked about the challenges with context switching, and as soon as chat compacts, you reject some approaches, you try out different things, you’re pairing with the agent, you’re going to have a difficult time remembering everything that happened in your session.

你可以向上滚动，而且随着压缩一直在发生，你不会把所有内容都保留在那里，也不可能把它们全都记在脑子里。代码往往保留的是一个已经做出的决定，但并不保留当初为什么做出这个决定。You can scroll up, and as compaction has been happening, you’re not going to have everything there, and you’re not going to be able to store it all in your head. Code often preserves a decision that was made, but not why the decision was made.

我认为这对你来说可能是一个有用的经验：在重要的时候，可以考虑让你的代理实际存储关于其轨迹的信息，或者它在解决问题时采用方法的一些有趣经验，这样你之后就可以回头查看。This is something that I think can be a useful learning for you, where it’s important, consider asking your agent to actually store information about its trajectory, or interesting lessons about how it approached a problem so that you can go back to it later.

这可以是你决定是否提交到仓库的内容。你可以把它保留在本地，如果你愿意，也可以和团队共享，但它也可以成为之后可供查阅的东西。这样就不必依赖它可能还在某个会话里，或者你之后也许还能想起来。This can or can’t be something that you decide to commit to a repo. You can keep it local if you want, you can share it with a team if you want, but that can be something that can then be consulted later on. Rather than you relying on it maybe being in a session, or you maybe remembering about it later.

所有权不会消失Ownership doesn’t disappear

这一切背后有一个更广泛的原则。There is a broader principle underneath all of this.

人类亲手输入的代码比例可能会大幅下降。我不认为人类的主导权也必须随之下降。The percentage of code physically typed by humans may fall dramatically. I don’t think human ownership needs to fall with it.

• 仍然有人选择这个问题。

  Someone still chooses the problem.

• 仍然有人在选择架构。

  Someone still chooses the architecture.

• 总有人在设定质量标准。

  Someone still sets the quality bar.

• 有人决定哪些验证信号值得信任。

  Someone decides which verification signals deserve trust.

• 有人决定何时证据足以发布。

  Someone decides when the evidence is sufficient to ship.

而当最终的系统失败时，“是代理写的”并不能作为借口。这就是为什么我不认为软件工程的未来最适合被描述为人类退出闭环。相反，人类的判断正在被重新安置。And when the resulting system fails, “the agent wrote it” doesn’t cut it. This is why I don’t think the future of software engineering is best described as humans leaving the loop. Instead, human judgment is being relocated.

我们应该把人从机器能够产生更强、更快、更确定性信号的循环环节中移除。同时，我们应该把人集中在那些上下文、品味、风险和长期所有权最重要的地方。We should remove people from the parts of the loop where machines can produce stronger, faster, more deterministic signals. At the same time, we should concentrate people around the places where context, taste, risk, and long-term ownership matter most.

最好的软件工厂不会由它们在多大程度上彻底消除人的参与来定义。The best software factories will not be defined by how completely they eliminate human involvement.

它们将由他们放置它的智慧程度来决定。They will be defined by how intelligently they place it.

在人类判断上游把关意图、系统形态和质量标准。审查那些自动化反压变弱或后果变得主观的代码。尽可能尽早且持续地将每一个确定性信号推入循环中。随着系统赢得或失去信任，有意识地收紧或放松约束。Keep human judgment upstream on intent, system shape, and the quality bar. Review code where automated back-pressure becomes weak or the consequences become subjective. Push every deterministic signal as early and continuously into the loop as possible. Tighten and relax constraints deliberately as the system earns or loses trust.

最终仍然得由人来对最终发布的代码负责。足以发布的代码也仍然是从那里开始的。A human still has to own what code ultimately ships. Code good enough to ship still starts there.