# Software Factories, Light and Dark
**作者**: Addy Osmani
**日期**: 2026-07-21T05:43:47.000Z
**来源**: [https://x.com/addyosmani/status/2079442194449232227](https://x.com/addyosmani/status/2079442194449232227)
---
A software factory is harnessed loops at scale. You can run the loop with humans in it (light factory): trading judgment and concentration against speed and breakage. Or you can ignore the humans (dark factory) and let those agents scope, build and ship code, without anyone really reading the details. But if people stop reading, they'll stop understanding your software. Your hardest job now is knowing which checks to build and how much autonomy to delegate.
This idea of the software factory is a term that dates back to Bob Bemer's paper, "The economics of program production" given in 1968. For half a century, many have dreamed of a world in which software is a repeatable and instrumentable production process (analogous to stamping out car parts in a factory) rather than the isolated craft of individuals. Historically, this dream has generally (although not universally) fallen flat, in part because of the difficulty of stamping out ideas.
But in the last two years, things have changed dramatically enough that now it makes sense to take a fresh look at the old dream. And since some subtleties can easily be glossed over, it's worthwhile to be somewhat precise about exactly what is really new and different, and what may be recurring traps, dressed up as new opportunities.
@dexhorthy, co-founder of HumanLayer recently gave a great talk at AI Engineer World's Fair called "Harness Engineering is not Enough: Why Software Factories Fail." worth checking out on this topic.
## The loop is the atom. The factory is the loop at scale.
Structure is everything, and it all starts with small units. The whole stack is really three concepts layered on top of each other: the loop, the harness, and the factory.
A loop is one agent doing a single job on repeat: gather context, take an action, check the result, and go again until some condition is met. It is the smallest unit of agentic work, and everything above it is just loops stacked on loops.
The point of loop engineering is that you stop prompting the agent turn by turn and instead design the small system that prompts it for you.
A harness is the walls around a loop: the sandbox it runs in, the tools it can reach, the memory that survives between runs, and the gates that decide what "done" means. The loop is the behavior; the harness is the environment that behavior runs inside.
Hand a raw model no harness and it will happily spin forever. The harness is everything around it that makes it useful and safe to run.
A software factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole thing from above. It is not a bigger agent; it is an org chart made of loops.
The final paradigm shift is moving from writing code to building and running the factory that writes it. The unit of work shifts up a level, to the loop, the harness, and the flow between them, rather than the individual code diff.
Loop → harness → factory. A factory isn't a smarter agent; it's many harnessed loops feeding one review gate, with a human owning the outer loop. The factory, drawn
The central slide Dex spent most time on was brilliant because it's a clarifying wiring diagram that visualizes what otherwise is an obvious loop. Here's my take on it:
The factory is a closed loop: intent and production signals feed a queue, the harness builds, automated checks and review gate it, deploy ships it, monitoring turns prod back into signals. Intent flows from the vision of engineering leadership, and directly from engineers, into a queue of things to be done. Signals driven by incidents and user requests drive the same queue.
The harness is just the thing that picks an item from the queue and builds a change for it. Beyond the harness, we can see all the automated checks required to make changes safe enough to let into production. These automated checks run at once, effortlessly, without any conscious involvement from engineers, thanks to CI, tests, static analysis, and scanning of all kinds. The only decision point here is the review gate. After approval, changes are deployed and monitored in production, with monitoring data feeding back into the signals that kicked the loop into motion to begin with.
By and large, every box in this diagram is almost zero cost: generation, tests, scanning. They all run at scale for negligible cost. There is only one expensive box that proves stubbornly resistant to scaling, and that's the review gate. That shiny amber box is "judgment", and where the crux of the argument about whether we can make development faster and more frequent resides.
## Why we call it "dark"
A dark factory runs with the lights physically off, because the only things on the floor are machines and machines don't need light to see. A dark software factory is the same move: code ships that no human has read, verified only by other machines.
The image is borrowed from manufacturing. Its origins are physical rather than digital, rooted in facilities where the lights are turned off and the work is carried out by robots. FANUC in Japan has been running lights-out factories of this sort since 2001; Xiaomi, in 2024, opened a heavily automated dark factory of its own. What these have in common is a product assembled and shipped without a single human having read any of it. The "dark" comes in when that act of reading is removed from the process.
I'm not borrowing the concept for its vibe or as an insult. For all its creepy buzz, "dark" here is a simple physical claim: the original factory floor, but without light. In software, the floor is the diff. Whoever wrote the diff, whoever reviewed it, whoever shipped it, those humans are gone, and what remains is a diff verified only by the machines that built it.
This is a surprisingly easy thing to do, at least at first. It's easy because that missing review step gets in the way of everything. Its absence makes your perception of your team's vertical throughput seem suddenly and radically higher. It feels as if you've broken the sound barrier. For all its apparent ease, it's harder than it seems to survive those dark workflows, with all their buried costs.
## Harness engineering is not enough
The harness of orchestration, sandboxed prototyping, and tool calling as models interact with the world and each other will become increasingly powerful and effective. However, there's an inherent in-model failure in trying to keep up with codebase quality over the long game and through additive changes, and I think there's good reason to believe that models alone will ultimately lose that battle against comprehension debt.
Comprehension debt is the widening gap between how much code exists and how much any human still understands. A dark factory doesn't pay it down; it takes it on as fast as it can, with the tests green the whole way.
This is an important distinction because models do well at some tasks. But for anything that isn't an immediate change to a small part of a codebase, especially in a complex brownfield system, model-only automated coding faces an insurmountable obstacle. Greenfield apps, weekend toys and side projects are alike in that a few months of development cycles is usually enough to get things in working order, or at least close enough.
But an enterprise system that has been under development for a decade or more is a different beast; it has to be maintained, in a professional environment at a professional pace. Three to six months into a project, you're already drowning in unread code. That kind of environment, and especially the constraints enforced by production code, would make even a powerful agent do poorly, all of it in contrast to the vibe-coding enjoyed by developers working on weekend toys.
Dex reports from experience that this is a major failure, so much so that it required painstaking manual debugging to pinpoint. This came from running a fully automated code factory for about four months, during which no human looked at the code that was written. Underlying the experience is a tradeoff between two conflicting metrics. One is maximizing token utilization, the number we currently treat as progress. The other, which it quietly minimizes, is the amount of the system any human participant still understands at any moment.
Where the dark factory truly shines is in its ability to burn through pristine code while the tests stay green. The ultimate reckoning, when it comes, will not be a dramatic "it all goes sideways" moment. It will be quiet and late.
Dark and lit are the same pipeline with the lights in different places. The lit version doesn't just re-add review at the end - it moves human judgment upstream to design and architecture, too. The bottleneck was never generation
The fundamental constraint in a software factory isn't how much code we can churn out: it's how quickly we can verify it.
Back pressure is the rule that you can only hand a loop as much autonomy as you can cheaply and reliably verify, and not one inch more. Verification, not generation, is the real constraint on a factory.
Because unbounded generation capacity is in perpetual tension with the finite, non-scaling resource of human attention, the core problem is the gap between cheap generation and bounded review. Look at the funnel: as long as the neck representing verification doesn't widen, it's going to back up. As Dex points out, volume alone isn't the problem: what we're really suffering from is a surplus of bad PRs. When you've got high volume without trustworthy gates, manufactured defects are unavoidable. This is just back pressure again: autonomy can't expand beyond what can be cheaply and reliably verified.
The second-order problem is why improving the model shouldn't automatically close the gap between what it can generate and what can be verified. Training on well-architected systems is an arguably more difficult proposition than passing simple tests: remember, the cost functions measuring architectural excellence aren't measured in seconds or even minutes, but in months and years. Tidy gradients are functionally impossible to compute, so a system expecting crisp, instant evaluation of complex design decisions isn't going to be trained on good examples.
Generation is a wide mouth; verification is the narrow neck. Speeding up the mouth just deepens the pile at the neck.
## Turning the lights back on
A lit factory is the same pipeline with the lights left on where judgment lives. The agents still do most of the building, but a human reads what comes out before it ships, and the lights stay on wherever a wrong call is expensive.
The lit version doesn't tack review onto the end but moves the point of human judgment upstream, to the product, the design, and the architecture before an agent starts a loop.
One great thing about that upfront hour is that it leads to fewer implementation hours. It turns a long, frustrating code review into a quick read of a two-hundred-line plan. You get to review a decision before it's built, so later you aren't chasing through two thousand lines of generated code to find out what the decision even was. Some decisions are expensive and long-lived enough that you'd want a person in on them early, before the cost compounds. Of course, there are still times you look at diffs, even when you've spent time up front.
You might be thinking that all sounds unglamorous. You're right. The safety net is made up of perfectly ordinary architectural practices we've always known about and mostly ignored: good types and method signatures so that mistakes are caught by the compiler instead of in production; test seams where we can pin behavior and make change observable; laying out the code so the next reader, human or model, knows where to find the thing they care about; keeping call stacks short and legible; keeping component boundaries well defined so a change doesn't have a huge blast radius; and dependency injection so we can swap out one piece for another. None of it is new. We've always said we care about good architecture. But now that we're using automated coding agents, that architecture is finally doing a second job as a cheap and hard-to-fake safety net against the mistakes the agent will make.
That safety net has to live outside the model, because the model won't supply it. The coding agents that feel most capable, Claude Code and Codex among them, are reinforcement-trained against their own harness and tools: fluent with all the tools and idioms of the trade, but not with things like long-term maintainability. The deliberate architecture we've always talked about is the tool that catches that debt, and the investment we make in it is us buying back our autonomy.
Put that together with safe infrastructure, and there are some tight, low-risk loops you can run unattended. Horthy described one in a recent post: a nightly GitHub Actions cron that fixes exactly one anti-pattern, a lint violation or a needlessly optional prop, commits, and opens one small pull request, all on its own, so the team wakes up to a slightly better codebase and a diff short enough to read. But for loops with high enough stakes, you don't want to risk waking up to a broken auth system, billing engine, or public API contract. Keep the lights on there, and trust that a person with judgment and a real working knowledge of the system will catch the mistake.
## What earns a loop the dark
This rule applies whether you call it back pressure, verification, or the light switch.
A loop can earn itself fully automated status only if the check is cheap, runs at high frequency, and relies on something that can't be easily faked out. Green-or-red oracles, type gates, property tests, and a review agent coupled with a real rubric all fit. You also need the oracle to answer immediately and not drift over time. When done can be proven not just by you but by a machine, you've reached automation.
Short loops are easier to verify than long ones. Dex's rule of thumb: an agent holds up for three to ten steps, then starts losing the thread past twenty. The reason is context accumulation, the more the agent drags along, the more likely it is to wander off. When a loop is short, verifying it is cheap. Sprawling loops hide mistakes in the corners, which is another way of saying they never earned lights-out status.
Keeping the lights on is the opposite case. A loop needs to be reviewed if a wrong answer is expensive and only a person can catch it. Subtle production bugs that can't be caught by tests, large blast radii, and a decision that's going to shape the work of a year or more all qualify. In those cases, your attention is the actual product, the costly, essential one.
The danger is forgetting to flip each switch and just setting all of them to the same mode. All dark, and you're stuck tearing everything down four months later. All lit, and no one can get reviews done in time and you're stuck in a gigantic bottleneck. The hard, skilled job is deciding where to put each switch.
## Loops, graphs or state machines?
You should read "State machines in 2 minutes" by @DavidKPiano
When you hand an agent a task, you're probably going to build a graph around it, whether you call that graph a finite state machine or a set of conditionally-linked service calls. It's a framing where the software isn't just following some abstract rules but a structured workflow: every node is an explicit step, and every edge between nodes is an explicit condition.
That sounds like a lot of structure, but most of it is already there in any software, since any code can be expressed as a control-flow graph. So the only real novelty is that an agent insisting on autonomy is really just walking around a particular graph, and its freedom is constrained to the inside of a node. And here's the part people forget, which Dex wrote down a year ago: software was always going to have that structure. There's a reason we used to draw programs as flow charts.
The genuinely new move was trying to throw the diagram away, leaning on a loop where the model picks the path tool call by tool call, until it declares itself done. That felt like liberation, right up until it met a ten-year-old codebase, and the discipline everyone is now rediscovering, owning your control flow, is really just walking the graph back around the loop. So the question of whether we should shift from loops back to graphs is almost an admission that we needed the flowchart all along.
Here's what it looks like in practice. Take a bug to fix. As a pure loop, you sit down and think: figure out what's wrong, change some code, run the tests, see what happens, and if that round doesn't kill the run, loop back and start again. The whole journey is decided as you go, which problem you chase, the exact code you change, which tests you run and in what order, whether you run tests at all, and whether you try again or declare victory.
As a graph, the first thing you do is map out what should happen. Reproduce the bug or go ask for more information, find the cause, try a fix, run the tests, and let a failing run route back to the fix while a passing one goes on to review, where only an approval reaches done. The agent is still clever inside each box; it just can't wander off the paths you sanctioned. Santi laid this out with a diagram that makes the difference obvious.
The real appeal of that graph, of course, is that it's back pressure drawn as a diagram. You give up some of the agent's freedom and get mandatory checks and legible failure points in return, so when a run dies you can point at the node that killed it. It's the same instinct behind Dex's blunt line that most so-called agents aren't very agentic at all, "mostly deterministic code, with LLM steps sprinkled in at just the right points." And this isn't just an artifact of how people happen to be building things right now: you can see the pattern in LangGraph and LlamaIndex Workflows, in Jerry Liu's hybrid workflow-graph-over-agents with an outer loop that grows parts of the graph as it runs, and in David Khourshid's reminder that this is really just state machines and the actor model turning up in new clothes.
One clarification, because the term is badly overloaded: when I keep calling this a graph, I don't mean a knowledge graph. I mean a predefined directed graph of how the work should flow, conditional edges and all, giving the loop a shape you can actually trust.
## Where the human actually goes
Notice that the person never left the factory. They moved.
I think engineers need to increasingly own the outer loop. The agents can investigate a bug, write up the diagnosis, implement a fix, run the tests, and write up a report. That's the execution of the inner loop, and they can do it as efficiently as anyone. But that was never the job. The bits you own are what I'd call the outer loop: decide whether it's the right way to address the problem, verify that the diagnosis and implementation are sound, approve the change, and carry the consequences of being wrong. The boundary between the two loops is evidence, the diffs, the tests, the logs, and a brief explanation that connects them. Types, seams, and rubrics make it possible to oversee all this without doing a lot of work for every change.
It's useful to put it this way: you're not down on the line writing changes any more; you're up at the end of the production line designing it and guarding the gate. There's a lot you can do to make the model better and the harness more capable, but I've observed that identifying problems that are expensive in the long term is not typically something you can automate away. The core thing that's still the job is to exercise human judgment better than any flow of paper and computing power.
Robots are fine operating in the dark, but humans need to see what they're doing. If everything on the factory floor is dark, and you can't see anything, and you can't even find the light switch, that's where the danger is.
Pangram scored this article as 100% human written.
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [145K](https://x.com/addyosmani/status/2079442194449232227/analytics)
- [Bob Bemer's](https://en.wikipedia.org/wiki/R._W._Bemer)
- [@dexhorthy](https://x.com/@dexhorthy)
- ["Harness Engineering is not Enough: Why Software Factories Fail."](https://youtu.be/htM02KMNZnk?t=27219)
- [loop engineering](https://addyosmani.com/blog/loop-engineering/)
- [the factory](https://addyosmani.com/blog/factory-model/)
- [FANUC in Japan has been running lights-out factories of this sort since 2001](https://en.wikipedia.org/wiki/Lights_out_(manufacturing))
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [Dex's rule of thumb](https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-10-small-focused-agents.md)
- [your attention is the actual product](https://addyosmani.com/blog/human-is-the-expensive-part/)
- [State machines in 2 minutes](https://x.com/DavidKPiano/status/2079209887158989231)
- [@DavidKPiano](https://x.com/@DavidKPiano)
- [Dex wrote down](https://github.com/humanlayer/12-factor-agents)
- [outer loop](https://addyosmani.com/blog/own-the-outer-loop/)
- [scored](https://www.pangram.com/history/d151077c-b4ca-4277-a2fe-75e6cb282f06)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:43 PM · Jul 21, 2026](https://x.com/addyosmani/status/2079442194449232227)
- [145.2K Views](https://x.com/addyosmani/status/2079442194449232227/analytics)
- [View quotes](https://x.com/addyosmani/status/2079442194449232227/quotes)
---
*导出时间: 2026/7/21 17:38:10*
---
## 中文翻译
# 软件工厂，明与暗
**作者**: Addy Osmani
**日期**: 2026-07-21T05:43:47.000Z
**来源**: [https://x.com/addyosmani/status/2079442194449232227](https://x.com/addyosmani/status/2079442194449232227)
---
软件工厂就是规模化运作的受控循环。你可以在循环中加入人来运行（明工厂）：用判断力和专注度来换取速度和故障。或者你可以忽略人类（暗工厂），让智能体自行定义范围、构建并交付代码，而无需任何人真正阅读细节。但如果人们停止阅读，他们也将停止理解你的软件。你现在最艰巨的工作是知道应该建立哪些检查机制，以及委托多少自主权。
软件工厂这一概念可以追溯到 Bob Bemer 在 1968 年发表的论文《程序生产经济学》。半个世纪以来，许多人梦想着一个世界，其中软件是一个可重复且可仪器化的生产过程（类似于在工厂里冲压汽车零件），而不是个体的孤立手工艺。从历史上看，这个梦想总体上（虽然并非绝对）已经落空，部分原因是想要冲压出“想法”实在太难了。
但在过去两年里，情况发生了剧变，现在有必要重新审视这一旧梦想。由于一些微妙之处容易被忽略，因此值得精确地弄清楚究竟什么是真正新颖和不同的，以及什么可能只是伪装成新机遇的重复陷阱。
HumanLayer 的联合创始人 @dexhorthy 最近在 AI Engineer World's Fair 上发表了一场精彩的演讲，题为“Harness Engineering is not Enough: Why Software Factories Fail”（驾驭工程还不够：为什么软件工厂会失败）。这个话题值得一看。
## 循环是原子。工厂是规模化运作的循环。
结构就是一切，一切都始于小单元。整个技术栈实际上就是叠加在一起的三个概念：循环、驾驭和工厂。
循环是一个智能体重复执行单一任务：收集上下文、采取行动、检查结果，然后再次执行，直到满足某个条件。它是智能体工作的最小单元，而其上的一切都只是循环的叠加。
循环工程的意义在于，你不再一步步地提示智能体，而是设计一个替你提示它的小型系统。
驾驭是环绕在循环四周的墙壁：它运行的沙箱、它能触达的工具、在运行之间持久存在的记忆，以及决定“完成”意味着什么的各种关卡。循环是行为；驾驭是该行为运行于其中的环境。
如果把一个原始模型交给它而不加驾驭，它可能会永远快乐地空转下去。驾驭是周围的一切，正是这些让它变得有用且运行安全。
软件工厂是许多受控循环同时运行，由工作队列供给，并通过审查关卡排入生产环境，而人类则从上层拥有整个系统。它不是一个更大的智能体；它是一个由循环组成的组织结构图。
最终的范式转变是从编写代码转向构建和运行编写代码的工厂。工作单元向上提升了一个层次，变成了循环、驾驭以及它们之间的流转，而不是单个代码差异。
循环 → 驾驭 → 工厂。工厂不是更聪明的智能体；它是许多受控循环汇聚到一个审查关卡，由人类拥有外部循环。工厂示意图。
Dex 花时间最多的那张核心幻灯片非常精彩，因为它是一张清晰的接线图，将原本显而易见的循环可视化。以下是我对它的理解：
工厂是一个闭环：意图和生产信号输入到队列中，驾驭负责构建，自动检查和审查关卡进行过滤，部署负责发布，监控将生产环境转化为信号。意图源于工程领导层的愿景，以及工程师的直接输入，流入待办事项队列。由事故和用户请求驱动的信号也会驱动同一个队列。
驾驭只是从队列中选取一项并为其构建变更的东西。在驾驭之外，我们可以看到使变更足够安全以至于能进入生产环境所需的所有自动检查。得益于 CI、测试、静态分析和各类扫描，这些自动检查同时、轻松地运行，无需工程师的任何有意识参与。这里唯一的决策点是审查关卡。批准后，变更被部署并在生产环境中监控，监控数据反馈回最初启动循环的信号中。
总的来说，这张图中的每一个方框几乎都是零成本的：生成、测试、扫描。它们都以可忽略不计的成本规模化运行。只有一个昂贵的方框顽固地抗拒规模化，那就是审查关卡。那个闪亮的琥珀色方框就是“判断”，这也是关于我们能否让开发更快、更频繁的争论的关键所在。
## 为什么我们称之为“暗”
暗工厂在物理上是关灯运行的，因为车间里只有机器，而机器不需要光来看见东西。暗软件工厂也是同样的举措：发布的代码没有任何人类阅读过，仅由其他机器验证。
这个概念借用于制造业。它的起源是物理的而非数字的，根植于那些关灯并由机器人进行工作的设施。日本的 FANUC 自 2001 年以来一直在运行这种关灯工厂；小米在 2024 年也开设了自己的高度自动化暗工厂。它们的共同点在于，产品的组装和发货没有任何人类阅读过其中的任何内容。当“阅读”这一行为从过程中移除时，“暗”就出现了。
我借用这个概念并不是为了它的氛围或作为一种侮辱。尽管它有一种令人毛骨悚然的流行感，但这里的“暗”只是一个简单的物理陈述：原来的工厂车间，但没有光。在软件中，车间就是代码差异。无论谁编写了差异，谁审查了它，谁发布了它，那些人都消失了，剩下的只是由构建它的机器验证的差异。
这是一件出奇容易做到的事情，至少起初是这样。它之所以容易，是因为缺失的审查步骤会阻碍一切。它的缺席让你对团队垂直吞吐量的感知似乎突然且大幅度地提高。感觉就像你突破了音障。尽管表面上看起来容易，但在那些暗工作流及其所有隐性成本中生存下来，比看起来要困难得多。
## 驾驭工程还不够
随着模型与世界及彼此互动，编排、沙箱原型制作和工具调用的驾驭将变得越来越强大和有效。然而，在长期博弈和增量变更中试图保持代码库质量，存在着模型固有的失败，我认为有充分的理由相信，仅靠模型最终将输掉这场对抗理解债务的战斗。
理解债务是现有代码量与任何人类仍然理解的代码量之间不断扩大的差距。暗工厂并不会偿还它；相反，只要测试一直通过，它就会尽可能快地承担这种债务。
这是一个重要的区别，因为模型在某些任务上表现出色。但对于任何不是对代码库一小部分进行即时更改的任务，尤其是在复杂的棕地系统中，仅靠模型的自动编码面临着无法克服的障碍。绿地应用、周末玩具和副业项目都有一个共同点：通常几个月的开发周期就足以让事情步入正轨，或者至少接近正轨。
但是，一个开发了十年或以上的企业系统则是另一回事；它必须在专业环境中以专业的节奏进行维护。在项目进行三到六个月后，你已经淹没在未阅读的代码中。这种环境，特别是生产代码强制执行的约束，即使是一个强大的智能体也会表现糟糕，这与开发周末玩具的开发人员所享受的氛围编码形成了鲜明对比。
Dex 根据经验报告说，这是一个重大的失败，以至于需要艰苦的手动调试来定位问题。这来自于运行一个全自动代码工厂大约四个月，期间没有人查看编写的代码。这种经验背后的原因是两个相互冲突的指标之间的权衡。一个是最大化 Token 利用率，这是我们目前视为进步的数字。另一个则是它悄悄最小化的指标，即任何人类参与者在任何时刻仍然理解的系统数量。
暗工厂真正发光的地方在于它能够在测试保持绿色的情况下消耗掉干净的代码。当最终的清算到来时，它不会是一个戏剧性的“一切失控”的时刻。它将是安静且迟来的。
暗和亮是相同的管道，只是灯的位置不同。亮版本不仅仅是在最后重新添加审查——它还将人类判断提前到设计和架构阶段。瓶颈从来都不是生成
软件工厂的根本约束不在于我们能产出多少代码：而在于我们能多快地验证它。
背压是一条规则：你只能赋予一个循环与其能够被廉价且可靠验证的程度相当的自主权，一分一毫也不能多。验证，而不是生成，才是工厂真正的约束。
因为无限的生成能力与有限且无法扩展的人类注意力资源之间存在着永恒的张力，核心问题在于廉价生成和有限审查之间的差距。看看这个漏斗：只要代表验证的颈部不变宽，它就会发生回流。正如 Dex 指出的那样，量本身并不是问题：我们真正遭受的是糟糕的 PR 过剩。当你在没有可信关卡的情况下拥有高产量时，制造缺陷是不可避免的。这又是背压：自主权不能扩展到廉价且可靠验证的范围之外。
二阶问题是为什么改进模型不应该自动缩小它可以生成的内容与可以验证的内容之间的差距。在架构良好的系统上进行训练可以说比通过简单测试要困难得多：请记住，衡量架构卓越性的成本函数不是以秒甚至分钟来衡量的，而是以月和年来衡量的。想要计算出整齐的梯度在功能上是不可能的，因此一个期望对复杂设计决策进行清晰、即时评估的系统，将无法在好的示例上进行训练。
生成是一个宽口；验证是窄颈。加快口的输出只会加深颈部的堆积。
## 重新打开灯
亮工厂是相同的管道，只是在判断存在的地方开着灯。智能体仍然做大部分构建工作，但在产品发布前人类会阅读输出结果，并且在错误判断代价高昂的地方，灯一直亮着。
亮版本不是将审查附加在最后，而是将人类判断的点提前，即在智能体启动循环之前，提前到产品、设计和架构阶段。
前期投入一小时的一大好处是，它能减少后续的实现时间。它将漫长而令人沮丧的代码审查变成了对两百行计划的快速阅读。你可以在构建之前审查决策，这样以后就不必在两千行生成的代码中追查，以找出决策到底是什么。有些决策足够昂贵且长远，你希望尽早有人参与其中，在成本复合之前。当然，即使你在前期花了时间，有时你仍然需要查看差异。
你可能会想，这一切听起来都很不吸引人。你是对的。安全网是由那些我们一直知道但大多忽略的完全普通的架构实践组成的：良好的类型和方法签名，以便错误由编译器而不是生产环境捕获；测试接缝，我们可以在此固定行为并使变更可观察；布局代码，以便下一个读者，无论是人类还是模型，都知道在哪里找到他们关心的东西；保持调用栈简短易读；保持组件边界定义明确，以便变更不会产生巨大的爆炸半径；以及依赖注入，以便我们可以将一个部分换成另一个部分。这些都不是新的。我们一直都说我们关心好的架构。但现在既然我们正在使用自动编码智能体，该架构终于发挥了第二重作用，即成为对抗智能体将犯错误的廉价且难以伪造的安全网。
这个安全网必须存在于模型之外，因为模型不会提供它。那些感觉最有能力的编码智能体，如 Claude Code 和 Codex，是针对它们自己的驾驭和工具进行强化训练的：精通所有的工具和行业习语，但不精通长期可维护性之类的事情。我们一直在谈论的有意架构是捕获这种债务的工具，而我们在其中的投资就是我们买回我们的自主权。
将其与安全基础设施结合起来，你可以运行一些紧凑、低风险的循环而无需人工干预。Horthy 在最近的一篇文章中描述了这样一个例子：一个每晚运行的 GitHub Actions cron，它只修复一个反模式、一个 lint 违规或一个不必要的可选属性，然后提交并打开一个小的拉取请求，所有这些都是自动完成的，这样团队醒来时面对的是一个稍微好一点的代码库和一个足够短的可阅读的差异。但是，对于风险足够高的循环，你不想冒着醒来发现损坏的身份验证系统、计费引擎或公共 API 合约的风险。在那里把灯打开，并相信一个具有判断力和对系统有真正实际了解的人会捕捉到错误。
## 什么让循环有资格变暗
无论你称之为背压、验证还是开关，这条规则都适用。
只有当检查是廉价的、高频运行的，并且依赖于某种难以被欺骗的东西时，循环才有资格获得完全自动化的状态。红/绿预言机、类型关卡、属性测试，以及与真实标准相耦合的审查智能体都符合条件。你还需要预言机立即回答并且不随时间漂移。当“完成”不仅由你而且可以由机器证明时，你就达到了自动化。
短循环比长循环更容易验证。Dex 的经验法则是：智能体能保持三到十步，超过二十步就会开始失去线索。原因是上下文积累，智能体拖带的东西越多，就越可能偏离。当循环很短时，验证它是廉价的。庞大的循环将错误隐藏在角落里，这也就是它们从未获得关灯资格的另一种说法。
开灯则相反。如果一个错误答案代价高昂且只有人能捕捉到，那么循环就需要被审查。测试无法捕捉的微妙生产错误、巨大的爆炸半径，以及将决定一年甚至更长时间工作的决策，都符合这种情况。在这些情况下，你的注意力才是真正的产品，那种昂贵的、必不可少的产品。
危险在于忘记翻转每个开关，只是将它们全部设置为相同的模式。全暗，四个月后你就得被卡住拆除一切。全亮，没人能及时完成审查，你就会陷入巨大的瓶颈。困难且需要技巧的工作是决定将每个开关放在哪里。
## 循环、图还是状态机？
你应该阅读 @DavidKPiano 的“State machines in 2 minutes”（2 分钟看懂状态机）
当你交给智能体一个任务时，你可能会围绕它构建一个图，无论你将该图称为有限状态机还是一组条件链接的服务调用。这是一个框架……