# 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](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [386K](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)
- [386.8K Views](https://x.com/addyosmani/status/2074927530482835916/analytics)
- [View quotes](https://x.com/addyosmani/status/2074927530482835916/quotes)
---
*导出时间: 2026/7/9 08:54:14*
---
## 中文翻译
# 掌控外环
**作者**: 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%。
然后是编排税 ~ 现在很容易启动大量智能体，但你的认知带宽并不能以同样的方式并行化。引导你的智能体远离最坏的行为，对智能体产生的工作进行分类以找出需要你关注的工作，指导它首先关注你关心的任务，在让它运行之前验证你最重要的约束和最危险的假设……
所有这些都需要工作，而且无法自动化。
人类的判断力无可替代。
棕地系统在这里尤其危险，因为你必须审计的系统行为并不存在于代码中。它存在于伤疤中。
解决方案？将注意力作为架构决策的优先事项。使用 worktrees、范围和证据来减少初始计划与从中产生的工作之间的耦合。为解决不可行的步骤设定时间限制。并使软件中的更改严格成为选择性加入的权限。
Alpha（领先）、Decay（衰减）和 Taste（品味）：这三个核心模式塑造了跨领域的职业生涯和表现。
Alpha 是竞争中的最高成就者所占据的领先部分，当你打出最高价值的一步棋时。Decay 是每个人通过重复和观察他人学到的既定模式（如果你喜欢，也可以说是高原期）。Taste 是我们在任何证据表明事情正在发生之前，就能感知到 Alpha 中的领先或 Decay 中的变化的最早时刻。这是我们对即将发生的事情的判断，即使我们还没有任何证据。Paul Graham 的观点是，当任何人都可以制造任何东西时，选择制造什么变得更重要，而 Mitchell Hashimoto 的定义是一个可操作的定义：在尚无客观指标存在的情况下做出高质量的定性判断。从现在起，品味驱动一切：Alpha 的转变就是品味的改变。而 Decays 会逐渐消退，因为我们开始尝到了不同的东西。
下一步？将你的品味操作化。如何做？给它起一个名字，反映你试图将其从边缘系统转移到意识层面的东西。在批评和示例中练习它。使其基本原理明确化。
并继续做出能为你的行业带来最持久竞争优势的举动。那是什么？不断提升边缘，从仅仅执行任务转变为教导任务、系统化任务、决定何时应该完成任务，并拥有结果。
每个人都是开发者，但不是每个人都是工程师。工程师是开发者转变为采用更严格工作纪律时的状态：彻底且逻辑严密的推理、对约束和权衡的考量、对风险和暴露的认知，以及实际的问责。
在未来，人们将脱离工程的行政工作，并随着工程变得更具挑战性而拥抱新出现的角色。这些角色从工匠精神中解耦出来，但明确了每个人的职责。将会有原型制作的人。构建的人。扫尾的人。扩展的人。维护的人。
人类也在另一个方向上握着系统的边缘。在另一个方向上增加 Alpha：选择值得做的事情，定义应该在什么约束内完成，决定证据是否足以继续推进，以及关心结果。无论是单个团队还是一百个团队，这是只有人类才能掌握的边缘。
问责将扩展工厂。像注意力和品味一样，问责也是让一切运作的三个二元性之一。没有问责，就没有规则。没有与质询者的博弈。没有权衡。没有风险。没有安全网。如果没有人拥有决策的后果，那么高度的主体性只会带来混乱。
优势的半衰期是一次发布，但签名的半衰期是整个职业生涯。签名是你在工作上的名字，让你觉得可以站在发布的东西背后。技能给你杠杆；问责将杠杆转化为信任。
只有人才能选择。只有人继承后果。可以要求智能体在策略内安全地选择、路由、合并和升级，但它们无法继承后果。
也许每个代码库都应该附带某种问责契约，明确说明接受更改时理解的清单、进入决策的证据、谁对更改负责，以及更改被阻止后的系统状态。就像：
- 你的注意力和品味
- 你的证据、裁决和所有权
- 你的 Alpha、Decay 和品味
## 高主体性
在典型的智能体工作流中，高主体性是知的艺术