# Own the Outer Loop
**作者**: Addy Osmani
**日期**: 2026-07-08T18:44:08.000Z
**来源**: [https://x.com/addyosmani/status/2074927530482835916](https://x.com/addyosmani/status/2074927530482835916)
---
In the past year, the conversation around agentic engineering has moved to harnesses and loops, fleets and software factories. My 2c is engineers need to own the outer loop - the accountability for these systems. This only gets more true as powerful models like Fable and GPT-5.6 become available.
Agents have leverage, and leverage creates obligations. Someone must be able to explain exactly what changed, why it was safe, and what will happen if they're wrong. Otherwise, their actions can't be justified. Which makes it unlikely their organization will ask for them in the first place.
And so I want to talk about three terms. The first, Quality, refers to all the checks we install before we let the system loose. Those checks produce evidence, and from that evidence we derive a Verdict.
The second, Verdict, refers to the final decision we make before work enters our dependent system: I'm the line-producer of this content. I run the team whose work is shipped under my name. The model may write the line, but the Verdict is mine. The work of my team will not enter our dependent systems without my decision. A Verdict is the production decision: should we ship, block, redirect, narrow the response, add a guardrail, or reject outright?
The third, Answerability, refers to the guarantee that if someone asks, I can explain why.
To say this another way: our agent (which I define as a model plus a harness of files, tools, memory, skills, sandboxes, permissions, observability, and recovery) is what runs our loop (which I define as investigation, implementation, verification, and repeat). And it's what creates our software factory.
The model is just the engine. The harness - tools, memory, permissions, sandboxes, tests - is the car you build around it so it can do real work safely.
Wrap that harness in a repeatable cycle: investigate, implement, verify, repeat. The loop is how one good run becomes a process you can trust to run again. Wrap that harness in a repeatable cycle - investigate, implement, verify, repeat - where an independent check, not the model's own say-so, decides when the work is done.
Now run many loops at once. A factory is loops at scale - the agents ship the work inside, while humans own the decisions at the boundary.
And at the heart of that factory is a careful boundary between what's inside the system and what's outside it. Inside the system: we collect inputs (from the product team's intent, or knowledge of previously shipped work, or of recent incidents, or of specific feedback from users). The agent loop investigates the task, implements a plan, and verifies the result. Then, evidence crosses that boundary. A human, who owns the dependent system, sees the evidence and decides whether to proceed.
And that, friends, is the shift we're trying to make. Before, our agents were doing the inner loop of the execution loop. Now they run the inner execution loop. Engineers own the outer loop.
Inside the system, there's really just one kind of thing our agents are doing: capability. The capability to investigate tasks, implement plans, test their results, and report back. That's the capability of a model. And as we've said, that future is already here.
Outside the system, there's a single kind of thing: agency. The agency to decide, verify, approve, and own.
We're still talking about code, you see. It just needs to live in a place and be performed by people who know what they're doing.
The potential for AI code is no longer marginal. In a Sonar 2026 survey, we asked teams about the share of their commits that were AI-assisted. It was small but non-trivial. And several of the respondents said they expect the share of AI-assisted commits to grow substantially. Sonar's 2026 State of Code report found that 42% of committed code was AI-generated or significantly AI-assisted, with expectations for that share to keep growing rather than plateauing.
Creation, in other words, is getting cheaper. Scarcer resources are review, validation, understanding, and maintenance.
We moved the speed of generation faster than we moved the speed of control. And so we have a trust-verification gap. A lot of people we talk to still express some degree of distrust in AI code. Yet fewer of them seem to consistently build that distrust into their verification processes.
And that's a dangerous place to be in. We're going to need cheaper, clearer ways to verify the trustworthiness of AI code.
If you look at the GitLab June 2026 report, you'll see that governance questions have shifted. GitLab's June 2026 AI accountability research shows that review and validation are the current bottlenecks when using AI and, more worryingly, that governance usually happens after code creation, after we've accepted the risk and lost control over ownership. Today, it's not just about control. It's about what constraints we set on the system. It's about how we'll check the work with evidence, and how we'll hold teams accountable. It's about who will own what part of the AI lifecycle.
So the final distinction in this series is between process and quality. Quality is the concept of back pressure. We mean it literally. We don't want to grant our agents as much autonomy as they can possibly exercise. We want to grant them just enough autonomy that we have enough back pressure to stop them, regulate them, check their work, and ensure our humanity.
Ordinary engineering holds up a lot of signals that indicate that the work being done is doing the right thing. Type checks, tests, hooks, sandbox limits, audit logs, monitors. Our engineering systems are full of these kinds of signals, and they're designed to provide enough back pressure to keep the system honest.
And so as long as our agents are emitting these same signals, we can trust our ordinary engineering to provide appropriate back pressure.
Trusting our systems doesn't mean we don't want a human in the loop. It just means that the human doesn't need to be in the inner loop. We want them in the constraints loop (what inputs, architectures, instructions, or invariants should we set?), the sampling loop (how much output should we sample and review?), the audit loop (what evidence should we keep and how do we make sure our audit log is effective?), and the ownership loop (what part of the production boundary should we own).
But the human doesn't need to be in the inner loop.
The agent can ship more than you can review.
And the scarce resource is your own core human judgment, informed by quality signals like logs or tests.
The AI June 2026 report shows that, in the experimental setting, agentic delegation along hour-scale time horizons is essentially here. The work by OpenAI this year on agents and the future of work was a great source for these ideas. So we need to start thinking about how to establish this ownership boundary, as our systems start shipping more than we can review.
And that's where the answerability comes in.
Because with long-horizon agents, the decisions made over hour-scale time horizons are just that - decisions. And not all the decisions are going to be recorded. You can't trace them all back to input tokens. If all you're doing is trusting that the output you get is the correct choice for the problem at hand, the hundreds or even thousands of human hours of work you're going to need to reconstruct the chain of decisions that lead to it become impossible. And so, again, answerability becomes something that must be at the core of our system design.
## Three hidden costs
And there are three hidden costs:
Cognitive surrender ~ blindly accepting what AI gives you. When you delegate work to an agent, the work itself may appear to be the work of the agent. But it's actually your work. It's your reputation. It's your responsibility. And it's your software that suffered the defects in the output. And it's your software that needs to be changed to reflect that output. So the agent's output becomes your answer. And with it comes all the accountability. The Wharton study that put this together is reassuring when the AI is right. But when it's wrong, the news isn't great. When the AI was wrong, nearly three-quarters of people accepted it anyway, and felt more confident than they would have without the AI.
Cognitive debt ~ erosion of your understanding and memory of how to solve problems. When you delegate work to an agent, you're offloading all the thought work to the agent. And while thinking it all out yourself takes time and energy, thinking it out on a massive codebase takes resources that aren't available when you're trying to run up the learning curve. So the output you get is often unattainable by you. And the longer the time horizon of the agentic planning, the bigger the gap between the code the agent produces and your understanding of it becomes. The gap compounds. The debt accumulates. And the cost of climbing the learning curve grows almost exponentially. There's a randomized controlled trial from Anthropic looking at whether engineers who lean on AI to write code understand it as well as engineers who write it themselves. The conclusion was gloomy: on a comprehension quiz, the engineers who worked through AI scored seventeen percentage points lower than those who didn't, 50 percent versus 67 percent.
And then there's the orchestration tax ~ its easy to spin up lots of agents now, but your cognitive bandwidth doesn't parallelize in the same way. Steering your agent away from the worst behaviors, sorting the work the agent produces to identify the ones that need your attention, directing it to focus on the work you care about first, verifying your most important constraints and your most dangerous assumptions before you let it run…
All of that takes work, and it can't be automated.
There's no substitute for human judgment.
Brownfield systems are especially dangerous here, because the system behavior you have to audit doesn't live in the code. It lives in the scars.
Fixes? Make attention the priority in your architectural decisions. Use worktrees, scopes, and evidence to reduce the coupling between your initial plan and the work that emerges from it. Time-box the effort to resolve unactionable steps. And make change in your software strictly an opt-in permission.
Alpha, decay, and taste: these are the three core patterns that shape careers and performances across domains.
Alpha is the lead part taken up by the highest achiever in the competition, when you're playing your highest-value game move. Decays are established patterns that everyone learns through repetition and watching others (plateaus, if you like). Taste is the earliest we can sense the lead in an alpha or the change in a decay. It's our judgment of what's coming before we have any evidence that anything is happening. Paul Graham's point is that when anyone can make anything, choosing what to make matters more, and Mitchell Hashimoto's definition is the operational one: making high-quality qualitative judgments where no objective metric exists yet. From now on, taste drives everything: alpha shifts are taste changes. And decays fade out because we start to taste something different.
Next step? Operationalize your taste. How? Give it a name that reflects what you're trying to move from limbic to conscious. Practice it in critique and examples. Make its rationale explicit.
And keep making the move that delivers the most durable competitive advantage in your industry. What's that? Keep moving the edge up from just doing the task to teaching it, systematizing it, deciding when it should be done, and owning the result.
Everyone is a developer, but not everyone is an engineer. Engineering is what a developer turns into when they embrace a work discipline that is more strict: thorough and logically sound reasoning, consideration of constraints and tradeoffs, recognition of risk and exposure, and practical accountability.
In the future, people will leave the administrative work of engineering and embrace new roles that emerge as engineering becomes more demanding. Roles that are un-bundled from the spirit of craft but make clear what each person does. There will be those who prototype. Those who build. Those who sweep. Those who grow. Those who maintain.
The humans hold the edge of the system in the other direction, too. Increasing the alpha in the other direction: choosing what is worth doing, defining the constraints within which it should be done, deciding if the evidence is sufficient to proceed, and caring for the result. Whether it's a single team or a hundred teams, this is the edge that only humans can hold.
Accountability will scale the factory. Like attention and taste, accountability is also one of the three dualities that makes everything work. Without accountability, there are no rules. No wrangling with questioners. No trade-offs. No risks. No safety nets. If nobody owns the consequence of a decision, then high agency can only bring chaos.
The half-life of an edge is one release, but the half-life of a signature is a career. A signature is your name on the work, such that you feel you can stand behind what was shipped. Skills get you leverage; accountability turns leverage into trust.
Only people can choose. Only people inherit consequence. Agents can be asked to choose, route, merge, and escalate safely inside a policy, but they cannot inherit the consequences.
Every codebase should perhaps come with some kind of accountability contract that explicitly states the checklist that was understood when the change was accepted, the evidence that went into the decision, who was accountable for the change, and the system status after the change was blocked. Just like:
- Your attention and taste
- Your evidence, verdict, and ownership
- Your alpha, decay, and taste
## High agency
In a typical agentic workflow, high agency is the art of knowing when to delegate, when to inspect, when to stop, and when to own the result of a process. The ladder of agency runs from low to high: flag a potential problem, investigate it, execute against it, diagnose it, propose solutions, recommend fixes, and resolve the issue. A high rung on the agency ladder is discernment: found it, it's not worth fixing, moving on.
## The twelve pillars that hold up the software factory
Brownfield is the frontier for factories that hope to scale. All those clever little innovations may not feel like much yet, but the production environment is a lot. When building an entirely new system, it's much easier to plan and implement sufficient back pressure mechanisms because you have full control. When you're adding intelligent agents to a legacy system, however, it's another matter entirely.
Legacy systems include the entirety of production behavior, future expectations from customers, migration histories, release and budget cycle durations, unspoken assumptions, edge cases, data weirdness, runbook procedurals, and all the scars that accumulated without the will to care for the system.
To be a steward of brownfield requires a form of durable engineering. Work has to be done to turn implicit knowledge into explicit constraints, keep it coherent across teams and through generations, formalize that knowledge into test procedures and functional specifications, and tie that knowledge to objective evidence. All while ratcheting failure into more learning. Because if the system doesn't get the care it has always received, everything will come crashing down.
## New Work is Real Work
The work will get more interesting as you scale. Because when everything else is built, people will want to build new things. They'll want to employ the alpha and taste they have developed through their craft to design new loops that can be grafted onto the software factory. Or they'll want to build greenfield systems that employ all the knowledge of the software factory to one elegant, well meaning, principled effort. They'll want to design and implement new forms of evidence that will rise to the level of verification for the new systems. They'll want to take care of brownfield systems that are now so complex they need dedicated attention. They'll want to design and manage new back-pressure mechanisms. They'll want to design new agents. And they'll want to build agency.
And, as they do, they'll come to see that all this is real work. That's a good thing.
Automation creates bottlenecks. Bottlenecks in production that are worth owning. Because automation gives us control over industrial scale. But there's also new bottlenecks that arise from industrial scale. The bottleneck moves from "can we build this?" to "should this exist, can we answer for it?"
What I'm suggesting is a practical operating model for scaling agentic engineering. There's inner and outer loops. The inner loop is where the work is done. Loops are designed to be as independent as possible. Put all quality assurances and verification inside the loop. Once you've designed and validated the loop itself, the only thing you have left to do is to grant autonomy by putting in place a back-pressure mechanism that acts to control the rate at which the loop is run and its scope of operation. And put humans in their rightful place, on the right decisions. Don't treat understanding as a hand-off or a release gate, but rather as a point of decision where humans are primed to provide their insight. And then for every artifact that exists and is fed back into production and into new teams and engineers, leave behind better artifacts.
Build the factory; keep the lights on; make work legible, verifiable, owned.
An agent can write it. But before it reaches users, someone must explain why it should exist, why it's safe enough to be part of production, and what they will do when it is wrong.
That is agentic engineering at the outer loop - that is the work now.
Pangram has scored this article as 100% human written: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
## 相关链接
- [Addy Osmani reposted](https://x.com/addyosmani)
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [913K](https://x.com/addyosmani/status/2074927530482835916/analytics)
- [loops](https://x.com/addyosmani/article/2064127981161959567?lang=en)
- [Sonar's 2026 State of Code report](https://www.sonarsource.com/state-of-code-developer-survey-report.pdf)
- [GitLab's June 2026 AI accountability research](https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx)
- [OpenAI this year on agents and the future of work](https://openai.com/index/how-agents-are-transforming-work/)
- [Wharton study](https://executiveeducation.wharton.upenn.edu/thought-leadership/wharton-at-work/2026/05/thinking-fast-slow-and-artificially/)
- [randomized controlled trial from Anthropic](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [Paul Graham's point](https://paulgraham.com/taste.html)
- [https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871](https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:44 AM · Jul 9, 2026](https://x.com/addyosmani/status/2074927530482835916)
- [913.4K Views](https://x.com/addyosmani/status/2074927530482835916/analytics)
- [View quotes](https://x.com/addyosmani/status/2074927530482835916/quotes)
---
*导出时间: 2026/7/16 14:48:17*
---
## 中文翻译
# 掌控外循环
**作者**: Addy Osmani
**日期**: 2026-07-08T18:44:08.000Z
**来源**: [https://x.com/addyosmani/status/2074927530482835916](https://x.com/addyosmani/status/2074927530482835916)
---
在过去的一年里，关于智能体工程的讨论已经转向了挽具与循环、机队与软件工厂。我的两点看法是，工程师需要掌控外循环——即对这些系统的问责。随着像 Fable 和 GPT-5.6 这样强大的模型问世，这一点只会变得更加真实。
智能体具有杠杆作用，而杠杆作用带来了义务。必须有人能够确切地解释发生了什么变化、为什么它是安全的，以及如果弄错了会有什么后果。否则，他们的行为就无法被证明是正当的。这也使得他们的组织在起初就不太可能要求他们去做这些事。
因此，我想谈谈三个术语。第一个是“质量”，指的是我们在放开系统之前安装的所有检查。这些检查会产生证据，而我们要从这些证据中得出“裁决”。
第二个是“裁决”，指的是在作品进入我们的依赖系统之前我们做出的最终决定：我是这款内容的制作人。我领导着那些以我的名义发布作品的团队。模型可能写出了那一行代码，但裁决由我做出。没有我的决定，我团队的作品就不会进入我们的依赖系统。裁决是一个生产决策：我们应该发布、阻止、重定向、缩小响应范围、添加护栏，还是直接拒绝？
第三个是“可问责性”，指的是一种保证，即如果有人询问，我可以解释原因。
换句话说：我们的智能体（我将其定义为一个模型加上由文件、工具、记忆、技能、沙盒、权限、可观测性和恢复机制组成的挽具）运行着我们的循环（我将其定义为调查、实施、验证和重复）。正是它创造了我们的软件工厂。
模型只是引擎。挽具——工具、记忆、权限、沙盒、测试——是你围绕它建造的汽车，这样它才能安全地完成实际工作。
将那个挽具包裹在一个可重复的循环中：调查、实施、验证、重复。循环就是让一次良好的运行变成一个你可以信任并再次运行的过程。将那个挽具包裹在一个可重复的循环中——调查、实施、验证、重复——其中由独立的检查，而不是模型的自说自话，来决定工作何时完成。
现在同时运行多个循环。工厂就是规模化的循环——智能体在内部交付工作，而人类则拥有边界上的决策权。
那个工厂的核心在于系统内部和外部之间一个经过精心设计的边界。在系统内部：我们收集输入（来自产品团队的意图，或对已发布工作的了解，或对近期事件的了解，或用户的特定反馈）。智能体循环调查任务，实施计划，并验证结果。然后，证据穿过那个边界。拥有依赖系统的人类看到证据，并决定是否继续。
这就是，朋友们，我们正在努力做出的转变。以前，我们的智能体是在执行循环的内循环中工作。现在它们运行内部的执行循环。工程师掌控外循环。
在系统内部，我们的智能体实际上只在做一类事情：能力。调查任务、实施计划、测试结果并报告回来的能力。这就是模型的能力。正如我们所说，这种未来已经到来。
在系统外部，只有一类事情：能动性。决定、验证、批准和拥有的能动性。
你看，我们谈论的仍然是代码。只是它需要存在于一个合适的地方，并由知道自己在做什么的人来执行。
AI 代码的潜力已不再是微不足道。在 Sonar 2026 年的一项调查中，我们询问了团队其提交中有多少比例是 AI 辅助的。这个比例虽小但不可忽视。几位受访者表示，他们预计 AI 辅助提交的比例将大幅增长。Sonar 的 2026 年代码状态报告发现，42% 的提交代码是由 AI 生成或显著由 AI 辅助的，并且预计这一比例将持续增长而非趋于平稳。
换句话说，创作的成本正在降低。稀缺的资源是审查、验证、理解和维护。
我们将生成的速度提升得快于我们提升控制的速度。因此，我们有了一个信任-验证的缺口。我们交谈的许多人仍然表达了对 AI 代码某种程度的不信任。然而，似乎很少有人将这种不信任持续地融入到他们的验证流程中。
这是一个危险的处境。我们需要更廉价、更清晰的方法来验证 AI 代码的可信度。
如果你查看 GitLab 2026 年 6 月的报告，你会发现治理问题已经发生了转变。GitLab 2026 年 6 月的 AI 问责研究表明，审查和验证是当前使用 AI 时的瓶颈，更令人担忧的是，治理通常发生在代码创建之后，在我们接受了风险并失去了对所有权控制之后。今天，这不仅仅关乎控制。这关乎我们要对系统设置什么约束。这关乎我们将如何通过证据来检查工作，以及我们将如何让团队承担责任。这关乎谁将拥有 AI 生命周期的哪个部分。
因此，本系列的最后一个区别在于流程和质量。质量是反压的概念。我们是字面意思。我们不想赋予我们的智能体尽可能多的自主权。我们只想赋予它们刚好足够的自主权，以便我们有足够的反压来阻止它们、规范它们、检查它们的工作，并确保我们的人性。
普通工程通过大量信号来表明所做的工作是正确的。类型检查、测试、钩子、沙盒限制、审计日志、监控器。我们的工程系统充满了这类信号，它们的设计旨在提供足够的反压以保持系统的诚实。
因此，只要我们的智能体发出这些相同的信号，我们就可以信任我们的普通工程来提供适当的反压。
信任我们的系统并不意味着我们不需要人在回路中。这只是意味着人不需要在内循环中。我们希望他们在约束循环中（我们应该设置什么输入、架构、指令或不变量？）、采样循环中（我们应该采样和审查多少输出？）、审计循环中（我们应该保留什么证据，以及如何确保我们的审计日志有效？）以及所有权循环中（我们应该拥有生产边界的哪个部分？）。
但是人不需要在内循环中。
智能体交付的工作可能超过你所能审查的范围。
而稀缺的资源是你自己核心的人类判断力，这种判断力由日志或测试等质量信号提供信息。
AI 2026 年 6 月的报告显示，在实验环境中，跨越小时级时间跨度自主的智能体委托基本上已经实现。OpenAI 今年关于智能体和工作未来的工作为这些想法提供了很好的来源。因此，随着我们的系统开始交付超过我们所能审查的工作量，我们需要开始思考如何建立这个所有权边界。
这就是“可问责性”发挥作用的地方。
因为对于长周期智能体，跨越小时级时间跨度做出的决定就是——决定。并非所有的决定都会被记录下来。你无法将它们全部追溯回输入的 token。如果你所做的只是信任你获得的输出是当前问题的正确选择，那么你将需要数百甚至数千个人类小时来重建导致该输出的决策链，这变得不可能。因此，同样地，可问责性必须成为我们系统设计的核心。
## 三种隐性成本
这里有三种隐性成本：
认知放弃 ~ 盲目接受 AI 给你的东西。当你将工作委托给智能体时，工作本身可能看起来是智能体的工作。但这实际上是你自己的工作。这是你的声誉。这是你的责任。并且是你的软件遭受了输出中的缺陷。也是你的软件需要进行修改以反映该输出。因此，智能体的输出变成了你的答案。随之而来的还有所有的问责。沃顿商学院的这项研究在 AI 正确时令人安心。但当 AI 错误时，情况就不太乐观了。当 AI 错误时，仍有近四分之三的人接受了它，并且比没有 AI 时更有信心。
认知债务 ~ 你对如何解决问题的理解和记忆的侵蚀。当你将工作委托给智能体时，你将所有的思考工作都卸载给了智能体。虽然自己把一切都想通需要时间和精力，但在庞大的代码库上想通所需的资源，在你试图攀登学习曲线时是无法获得的。因此，你获得的输出往往是你自己无法实现的。而且智能体规划的时间跨度越长，智能体产生的代码与你对它的理解之间的差距就越大。差距会复合。债务会积累。攀登学习曲线的成本几乎呈指数级增长。Anthropic 有一项随机对照试验，旨在研究依赖 AI 编写代码的工程师是否像自己编写代码的工程师一样理解代码。结论令人沮丧：在理解测验中，通过 AI 工作的工程师比没有使用 AI 的工程师低 17 个百分点，即 50% 对 67%。
然后还有编排税 ~ 现在启动许多智能体很容易，但你的认知带宽并不能以同样的方式并行化。引导你的智能体远离最糟糕的行为，整理智能体产生的工作以识别那些需要你注意的工作，指导它首先关注你关心的任务，在你让它运行之前验证你最重要的约束和最危险的假设……
所有这些都需要工作，而且无法自动化。
人类的判断力是无法替代的。
遗留系统在这里尤其危险，因为你需要审计的系统行为并不存在于代码中。它存在于伤疤中。
解决方案？将注意力作为你架构决策的优先事项。使用工作树、范围和证据来减少你的初始计划与从中产生的工作之间的耦合。为解决不可操作的步骤设定时间限制。并使软件中的变更严格地成为一种选择性加入的权限。
Alpha、衰减和品味：这三个核心模式塑造了各个领域的职业生涯和表现。
Alpha 是竞争中最优秀者在进行最高价值博弈时所占据的领先部分。衰减是每个人通过重复和观察他人学到的既定模式（如果你愿意的话，也可以说是高原期）。品味是我们在没有任何证据表明任何事情发生之前，最早就能感知到 Alpha 中的领先或衰减中的变化的能力。这是我们对即将发生的事情的判断。Paul Graham 的观点是，当任何人都可以制造任何东西时，选择制造什么变得更重要，而 Mitchell Hashimoto 的定义是操作性的：在尚无客观指标存在的情况下做出高质量的定性判断。从现在起，品味驱动一切：Alpha 的转变就是品味的改变。而衰减之所以消退，是因为我们开始品味到了不同的东西。
下一步？将你的品味操作化。怎么做？给它起一个反映你试图将其从边缘系统转化为有意识层面的名字。在批评和例子中练习它。使其理由明确化。
并继续做出能在你的行业中带来最持久竞争优势的举措。那是什么？不断将边缘从仅仅执行任务提升到教授任务、系统化任务、决定何时应该执行任务以及拥有结果。
每个人都是开发者，但不是每个人都是工程师。工程学是当开发者拥抱一种更严格的工作纪律时变成的样子：彻底且合乎逻辑的推理、对约束和权衡的考虑、对风险和敞口的认识以及实际的问责。
在未来，人们将离开工程的管理工作，拥抱随着工程变得更具挑战性而出现的新角色。这些角色从工匠精神中解绑出来，但明确规定了每个人的职责。将会有那些负责原型设计的人。那些负责构建的人。那些负责清理的人。那些负责增长的人。那些负责维护的人。
人类在另一个方向上也掌握着系统的边缘。在另一个方向上增加 Alpha：选择什么是值得做的，定义应该在什么约束内完成，决定证据是否足以继续，以及关心结果。无论是单一团队还是一百个团队，这都是只有人类才能掌握的边缘。
问责制将扩大工厂的规模。像注意力和品味一样，问责制也是让一切运作的三个二元性之一。没有问责制，就没有规则。没有与质疑者的争论。没有权衡。没有风险。没有安全网。如果没有人拥有决策的后果，那么高度的能动性只能带来混乱。
优势的半衰期是一次发布，但签名的半衰期是一个职业生涯。签名是你在工作上的名字，让你觉得可以支持发布的东西。技能给你杠杆；问责制将杠杆转化为信任。
只有人可以选择。只有人继承后果。可以要求智能体在策略内安全地选择、路由、合并和升级，但它们无法继承后果。
也许每个代码库都应该附带某种问责合同，明确规定接受变更时理解的清单、决策所依据的证据、谁对变更负责以及变更被阻止后的系统状态。就像：
- 你的注意力和品味
- 你的证据、裁决和所有权
- 你的 Alpha、衰减和品味
## 高能动性
在典型的智能体工作流中，高能动性是知道……