“就问莎拉”的结尾
The end of "Just ask Sarah"

原始链接: https://simme.dev/posts/the-end-of-just-ask-sarah/

## 智能体时代意图债务的兴起 工程组织传统上依赖“莎拉”——掌握系统构建方式*原因*的关键背景知识的人。人类可以向她提问,但人工智能智能体不行。这使得文档从一种客套转变为一种必需品:记录驱动执行的组织意图的持久记录。 如果没有诸如ADR(架构决策记录)和规范之类的文档,智能体只能基于现有模式运行,从而传播“意图债务”——未记录的决策。与能够随着时间积累背景知识的人类不同,智能体每次会话都会从头开始,无法从未书面的历史中受益。 仅仅拥有数据(工单、Slack 历史记录)是不够的;这是一种考古学,而不是记忆。文档提供了关键的*阻力*,迫使智能体考虑模式存在的*原因*,而不仅仅是盲目地扩展它。规范阐明意图(例如幂等性要求),而手册则指导超出症状修复的操作响应。 最终,缺乏文档暴露了一个组织的首要任务:交付代码而不是解释决策。在人工智能时代,写作不是开销——而是组织意图转化为有效行动的主要方式,并且可以规模化。

黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 “直接问莎拉”的结束 (simme.dev) 6点 由 milkglass 31分钟前 | 隐藏 | 过去 | 收藏 | 2评论 帮助 chromehearts 2分钟前 | 下一个 [–] 西蒙应该问莎拉如何写一篇文章,而不要依赖LLM回复 zacharyvoase 0分钟前 | 上一个 [–] ai;dr回复 考虑申请YC 2026年夏季批次!申请截止至5月4日 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系 搜索:
相关文章

原文

Sarah is the person who knows why a service was split, why an abstraction exists, why a strange constraint shaped the current design, and why the obvious fix was rejected three quarters ago.

Every engineering organization has a Sarah.

Humans can ask her.

Agents won’t.

That changes what documentation is. If boring code is an organizational tell, the absence of documentation is an even sharper one. Documentation is no longer a courtesy to future humans. It is the durable surface through which organizational intent reaches execution.

An agent opens a task. There’s a codebase, a prompt, a ticket. No ADR explaining why the service is structured the way it is. No spec describing the intent. The agent does what it’s built to do: finds the dominant pattern and extends it.

That’s not a bug. That’s intent debt propagating. A decision was made, it just wasn’t written down. So the agent inherits the output without the reasoning, and fills in the blanks.

Humans carry state

Organizational memory has always been a social structure as much as a technical one. It lived with the engineer who’d been on the team for seven years. In the phrase “just ask Sarah”. In the context handed off in one-on-ones and accumulated across stand-ups. Writing was the backup - always supposed to be there, but rarely maintained to the point where it could actually stand in for the human who held the original context.

This was survivable as the cost was deferred, not permanent. The penalty of the bus factor was only ever incurred through staffing changes. The engineer who made the decision last quarter is still on the team, allowing you to reconstruct the intent by asking.

The cost of undocumented decisions was real but recoverable: slower onboarding, an awkward investigation session before touching a brittle component, a 30-minute messaging thread that could have been a two-paragraph ADR.

Organizations learned to run on oral tradition because the alternative required discipline that was hard to reward. With agents, the full cost of a missing paper trail is paid every time the session terminates.

Agents don’t have Sarah

Agents have whatever is in the context window, and when that closes, it’s gone. The next session starts from zero.

Retrieval and agent memory do not change this. They only help if the organization has produced something worth retrieving. A vector database full of stale tickets, half-written specs, and decisions that only happened in Slack is not institutional memory.

It is archaeology with better search.

This makes intent debt structurally different for agents than it was for people. A human engineer can accumulate unwritten context over time by carrying it forward, updating it, and passing it on. Agents can’t form the kind of institutional memory that makes oral tradition viable. The knowledge that used to live between sessions now has to live somewhere that survives the session ending.

The codebase carries the result of decisions: the code that shipped, the abstractions that stuck, the patterns that propagated. It doesn’t carry the reasoning. Why this module boundary and not that one? What was evaluated and ruled out before the current approach was chosen? What constraint produced a design that looks strange now because the constraint no longer exists?

Without that reasoning, an agent encountering the code has only the output to work from. It doesn’t know whether the pattern is intentional or a historical accident. So it treats it as intentional and extends it - which is the correct behavior given what it has access to, and the wrong behavior given what actually matters.

An agent sees that every customer integration has its own service, so it creates another one. What it cannot see is that the pattern came from a scaling constraint two years ago, before the shared integration layer existed.

The constraint disappeared. The architecture kept reproducing.

Intent needs a format

For agents, the value of ADRs, specs, and playbooks is not completeness. It is friction. They interrupt the default move from “this pattern exists” to “this pattern should be extended”.

The ADR is where intent debt gets paid down. Its job is to record not just what was decided, but what was considered and why the alternatives lost. The constraint that drove the choice and the tradeoffs that were accepted. When an agent reads it, the decision isn’t an arbitrary historical fact - it’s the conclusion of an argument the agent can now evaluate and extend.

The spec operates on a longer time horizon. An agent optimizing a billing pipeline removes what looks like redundant retry logic. The spec would have told it the retries were a required idempotency guarantee - not an oversight. The code didn’t say why they were there. Only that they were. A spec written before code is a target. A spec written after code is a description.

The playbook is the operational artifact. Its time horizon is the incident. An agent responding to a memory spike restarts the affected pod. The playbook would have told it to check the upstream rate limiter configuration first - the restart clears the symptom, the playbook clears the cause. For a human SRE at 3am, the playbook is a spine. For an agent, it’s the only structured reasoning available.

All three operate at different layers - the decision, the direction, and the operation. None of that lives in the code itself.

The unwritten decision is still a decision

The absence of documentation is not neutral. It answers a question about what the organization treats as output. The incentive structure treated the time spent writing as overhead, not output.

The absence of an ADR is a sharper tell than anything you’ll find in the codebase. Code can be clever for reasons that are hard to see from the outside: inherited constraints, reasonable tradeoffs, or historical accidents.

The organization that resists ADRs isn’t resisting a writing style - it’s revealing a priority order. Shipping before explaining. Code before context. The decision, but not the decision record. The friction was never in the prose.

A concentration of cost

The cost of not writing concentrates in exactly the place where it’s hardest to recover from: the agent that picked up the task, found no ADR, found no spec, and proceeded with what it had.

That means writing is now the primary surface through which organizational intent becomes part of the context.

The boring organization writes everything down. If the decision was worth making, it was worth recording. If it wasn’t, that’s a choice the organization made, and agents will execute on it the same way they execute on everything else: faithfully, without judgment, at scale.

联系我们 contact @ memedata.com