The skills for managing agents are pretty much the skills for managing a team, and you don't need to be a manager to learn them.
If you're spending all day with a coding agent, you are managing. You're repeatedly selecting tasks, writing instructions, delegating, following up, evaluating results, and deciding what ships. The engineers who get the most out of agents aren't necessarily the ones who are best at prompt engineering. They're the ones who learned how to manage, intentionally or otherwise.
This might be an unwelcome idea. Many of the engineers I admire took an individual contributor (IC) career path because they want to stay close to the work. They've seen friends become managers and disappear into their calendars. But I'm not telling you to become a manager like that. I'm using "management" in a specific sense: producing good outcomes by enabling others' work. And I'm certainly not saying agents are a substitute for managers or colleagues.
Every gripe you have about bad managers is a bug report for interacting with agents. Think about handoffs. If you’ve experienced a bad one you may have got an ask that felt vague, lacked context or just had expectations shift a lot. The good news for ICs is that since you’ve been on the receiving end of handoffs for years, you might know what a good one looks like.
I've written before that your coding agents need a manager. I've also written about the quiet risk of delegation, cognitive surrender. This piece compares good engineering managers' practices with what we've learned from using and creating Claude Code. The sections are roughly ordered by impact, so that the most high-leverage habit comes first.
Give it a way to check its work
Best practice: Provide the agent with a mechanism to validate its work, like a test suite, build, or screenshot, and have it show you the results as proof.
Anti-pattern: Taking "looks done" as confirmation. This forces you to do all the validation, becoming the agent's test suite.
Ask an experienced manager how they can be confident their team is producing good work without reading everything, and they'll talk about guardrails. CI, code review, dashboards, on-call, etc. Inexperienced managers who don't build guardrails end up validating everything themselves, and within a quarter they're the bottleneck. The same is true for agents. As the Claude Code best-practices guide explains, agents stop when the work looks done. If there's no validation, "looks done" is the only validation the agent has. Providing a mechanism to validate the work allows the agent to do the work, run the validator, see the failure, and correct it on its own. For a UI change, this can mean actually opening the page in a browser and iterating until it works and looks good.
The validation mechanism can be almost anything, as long as it's something that yields a definitive pass/fail result. Think tests, build exit codes, linters, diff scripts, and screenshots. The guide notes that the command that runs these validations is the single most useful line you can have in your CLAUDE.md, the instructions file the agent starts each session with. Once you have the validation mechanism, here are some ways you can bring it into your workflow:
Ask. "Run the auth tests after, and continue until they pass."
Set a goal. With /goal, a separate model runs a condition check after every turn, which is most useful when doing long background work.
Enforce. A Stop hook can prevent the turn from completing until the typecheck passes.
Have it reviewed. /code-review sends the diff to a new subagent (which didn't see your conversation) for review, like how authors don't approve their own PRs.
You can even control the scope of the review. If you ask it to find problems, it will always find something. But if you ask it to find correctness issues and ignore style, it will do that. This is how good managers learn to ask for feedback, as well. Most of the functionality in the Claude Code toolkit is all about tightening this loop. Skills, hooks, subagents, and MCP all exist to bridge the gap between doing the work and validating the work, so your focus is only on the things the agent couldn't validate. This is what experienced engineering managers do.
Set clear context
Best practice: Provide a clear summary of what the agent can't know by inspecting the repo, including: the task's objective and why it's important, constraints, out-of-scope items, and success criteria.
Anti-pattern: Passing a one-line task, while the real expectations live in your head, or padding the brief with things the agent would discover by reading the code.
Effective managers provide clear descriptions of the desired outcome, constraints, and objectives. They articulate what the work should accomplish, but give the person doing the work the freedom to figure out how to do it. In the military, they call it commander's intent. At Netflix, they call it "context, not control."
The challenge of working with agents is that it's hard to know what context the agent is missing. The first thing a coding agent does on every task is read your code. Current models are fantastic at picking up on your folder structure, conventions, and test set-up much faster than you could describe them.
Before you write anything down, think about what the agent can figure out on its own. If the agent can read it in your code, and it would actually go read it, you don't need to say anything. Spend your words on the parts that are not in the repo - e.g. a meeting decision, someone's internal process for deploying, why this task is important, and what it means to be done this time.
Let's take the example of a vague task, "make the dashboard faster", and turn it into a prompt. The numbers here are just for example.
bash
Get p95 load time for the /team dashboard under 2s for orgs with 10k+ members.
Why: enterprise admins open it daily, and slow loads are their top support ticket.
Constraints: no schema changes; keep the API response shape.
Out of scope: UI changes; caching the whole page.
Check: run scripts/perf/team.sh and show before and after numbers.
You don't need to do this for every task. If you're doing discovery work, it's totally fine to write a generic prompt. You'll just refine a little more as you go. If you're not ready to write a prompt, have the agent interview you until it could write the spec, save that spec to a file, and then start a new session with the agent to build from that. You can use that spec to review against later.
You might also need to give your agent access to other tools, like your issue tracker, error dashboard, or team chat. Treat your agent the same way you'd treat a new hire on your team. If it's a CLI tool it already knows about, like gh, you often won't need to tell it anything.
Make every correction compound
Best practice: When you correct the same thing more than once, document it in the team's CLAUDE.md or turn it into a shared skill. Over time, check if newer models reduce the need for these corrections.
Anti-pattern: Manually correcting the same thing every session or relying on tacit knowledge that only exists on your own machine.
Teams that maximize the value of CLAUDE.md update it semi often and write down lessons learned from mistakes worth preventing. Some teams even mention @claude in code reviews, turning feedback into a permanent policy. Keep CLAUDE.md concise. Here are the types of things that belong in it:
How to verify something (exact commands)
Misleading areas of the code
Decisions that don't exist in the repo
Anything you've corrected twice
These are all examples of the compounding nature of written information. It outlasts people changing teams and models getting replaced.
Let it decide, and enforce only what can't bend
Best practice: Let the agent decide by default and only use hard enforcement (e.g. hooks, deny rules) for the few things that must always or never happen.
Anti-pattern: You write rules in ALL CAPS, define hooks for optional preferences, or keep habits from older models long after newer models outgrew them.
Andy Grove's High Output Management describes this as task-relevant maturity: the level of supervision should depend on a person's history of performance in that specific task, not their overall capability.
An old piece of advice for new managers says the same thing: give people a little more latitude than you're comfortable with while backing them up and holding them accountable.
Claude Code takes this and makes it explicit: prompts, CLAUDE.md, and skills are requests that the model can consider and choose to act on; hooks, deny rules, and managed settings are requirements that are always enforced. In most cases, you want the agent to make the call. There are often cases where the model, looking at real code, is better placed to judge if a guideline applies than a rule you set ahead of time. Use enforcement to set hard requirements such as "never edit the generated client" or "always run the license-header script." In particular, new terminal and VS Code sessions start in auto mode, with a classifier that will filter out unsafe behaviors like deploying to production or force pushing over someone's work.
The guide's advice has two sides. If you're putting more emphasis on a CLAUDE.md line and the agent still isn't picking it up, it should be a hook. If a hook is expressing a preference instead of a requirement, it should be removed in favor of letting the agent call the shots. It's like your team deciding to retire a process that is no longer useful. This also means adjusting when you have a new model. The guide keeps a list of habits you can stop: ALL CAPS directions, "think harder" (effort is a setting now), and "don't be lazy." With current models, these tend to lead to over-enforced rules and overwork. With agents, over-process is the new micromanagement.
Plan before it builds
Best practice: Set an agreed-upon plan before the agent starts coding, read for underlying assumptions, and partition tasks into non-overlapping parallel work.
Anti-pattern: Allowing multiple agents to tackle overlapping tasks simultaneously, then spending the afternoon resolving merge conflicts and duplicated decisions.
A good workflow here is to first enter plan mode and iterate on your plan until you have the right one, then delegate the coding. With a good plan, the model can often build it all in a single pass. For larger tasks, use a second session to look through the plan as a staff engineer would; it's a design review, which is the cheapest place to catch a wrong turn. When reviewing the plan, look for underlying assumptions (in a 1:1 this would be asking, "What are you unsure about?").
Decomposition is increasingly being delegated to agents. /batch in Claude Code takes a big mechanical change and creates 5 to 30 tasks, displays the plan, executes them in separate worktrees (separate checkouts of the repo), and creates a PR for each one. You no longer need to divide up the work, just check the slices for overlap and make sure shared interfaces land first. Without this, you might get a false level of parallelism. Five agents taking on overlapping tasks won't lead to five times the output, it leads to one merge conflict with five authors.
Steer early, reset fast
Best practice: Watch the first minute and steer the agent. As soon as you see it go off course, correct. If you've already made two failed attempts to correct the agent, start anew with a fresh session and better prompt.
Anti-pattern: Adding a third or fourth attempt to correct the agent, instead of correcting the request.
An experienced manager knows that if a capable person has a miss multiple times, the problem might be upstream with the instructions, context or scope. The agent version is explicit: as soon as the agent goes off course, hit Esc. If you've already made two failed attempts to correct the agent, clear the session and write a better prompt, incorporating the lessons you learned. A third attempt to correct the agent is mostly just more information that the model has to keep re-reading and re-processing (including failed attempts).
Cheap rollback is also changing the game. /rewind rolls the code and conversation to an earlier point, making it low-risk to try a more ambitious approach first. Good managers do the same with employees: if undoing a mistake is cheap, let them try an ambitious approach. Then run the retro afterwards, and generalize the fix into CLAUDE.md if applicable.
Delegate the task, never the judgment
Best practice: The agent does the work, you decide the important things: product calls, security boundaries, what ships. Treat every diff like you're going to get paged for it.
Anti-pattern: Approving large diffs because the tests are green and the names look reasonable. This is not code review, this is code ratification.
No manager can say "my report shipped that, not me." The same is true for every agent you run. I've fallen into this trap myself. I told an agent to research gaps with competitors and write local PRs to close those gaps. I read the research, skimmed the code and almost went ahead and pushed changes that added complexity for users for little gain. I had delegated the work, and almost delegated the decision as well. It's an easy trap to fall into: it's a 600-line diff, the names look reasonable, the tests are green, approve.
It makes sense to split tasks this way: let agents do the style, linting, follow-ups to reviews, typical bugs and unit testing, but let humans handle security boundaries, compliance and product decisions.
Coordination works the same way. An agent can keep track of handoffs, but deciding between competing requests and getting people to actually commit is still a human job.
You don't need to be in the inner loop of every change. What you do need to own are the outer loops: what the constraints are, how much of the output you actually read, what evidence you keep, and what a human has to sign off on. And keep changes small, since the unit of review is the unit of comprehension.
Design the run that doesn't need you
Best practice: Before deploying an autonomous task, define done, the self-verification, the boundaries, the guardrails, and the human approval.
Anti-pattern: Starting a long-running process before bed, without a definition of done or a stopping point, and waking up the next morning to find out that your model has been working overnight on a faulty premise.
Skip-level managers don't manage the work of individual engineers; they manage the work of goals, guardrails, checkpoints, and leads. AI agents are following a similar trajectory. They are already delegating parts of a task to sub-agents, and they can run autonomously on schedules, after CI failures or after new pull requests are opened. The frontier is self-governing systems that can autonomously start, self-verify, and only call for human intervention when decisions are needed.
The role shifts from controlling the session to designing your loops. The five questions to ask yourself when designing an unattended run are the same questions a good manager asks before giving a senior engineer a project and going on vacation:
Does it know what done looks like? (Goal condition, spec file, or a failing test it has to turn green.)
Does it have a self-verification mechanism? (Test suite, Stop hook, or review step.)
What are its boundaries? (Permission controls, sandbox, worktree, or the one branch it's allowed to push to.)
What are its guardrails? (Turn limit or spend limit.)
Where does it produce output, and who approves it? (A PR or summary, and a human approval of any non-reversible actions.)
The guide has two more habits that managers will recognize as good practices: pilot, i.e., get a batch job to run on three files, iterate the prompt, then run the rest; and watch the first few runs of anything new before you trust it unattended. Think of it as a probation period.
Scale verification, not attention
Best practice: Scale up the use of agents only as fast as checks, goals and fresh reviewers can take over the watching, and measure quality in addition to throughput.
Anti-pattern: Opening more sessions than you can review well, and measuring success by how much code the AI wrote.
Managers learn their span of control pretty quickly. Past a certain number of direct reports, everyone gets less of the manager and the quality goes down. The same is true for agents. It's what I call the orchestration tax: Past the first few agents, each additional agent requires more of your attention than the last. Most days I run four or five background agents and a few local sessions, and some days that's too many.
Managing lots of sessions isn't about being super-focused, it's about delegating most of the monitoring to self-evaluation, goals and new-context reviewers and reserving attention for decisions. It also helps to have notifications instead of polling and a centralized view of the background jobs. You can't scale the number of agents by monitoring more, only by needing to monitor less. Then measure the system rather than the activity. Useful metrics include cycle time for PRs, ramp up time for new employees and the frequency of reverts or rework. Measuring the percentage of AI-written code isn't a useful goal, because what you're aiming for is quality and reliability. Grove's rule of measuring with a countermeasure applies here: If you measure the number of PRs merged, then also measure reverts and rework.
Decide what not to build
Best practice: Ask who needs it, how you'll know it worked and what would make you stop, and limit WIP.
Anti-pattern: Just throwing every plausible idea into a PR; after all it's cheap to build. You'll now have a junk drawer the team needs to review, secure and maintain.
The most important word a manager says is often "no." With agents, it's harder to say no. It's nearly free to start work and you can throw any plausible idea into a PR by lunch. But you'll now have a bunch of PRs that the team needs to review, secure, support and maintain. Review and validation are the scarce resources now.
In fact, the old management questions matter now more than they used to. Who asked for it? How do we measure success? How do we know when to stop? If it's cheap to build the hard question is not "can we?" but "should we?"
Where the analogy breaks
Best practice: Follow management best practices, but account for the differences in the agent model, like cheap rework, how quick they are to agree, and strengths that shift with every model release.
Anti-pattern: Thinking that an agent is just like a junior developer, or that you're prepared to manage five people because you can run five agents.
The analogy is a useful but imperfect one, and the best practitioners of this work are aware of where it is imperfect:
Managing people is harder, and the skills don't transfer back. You're not prepared to manage five people because you've run five agents. There is no equivalent for motivation, conflict, career development, or months-long trust building.
Rework is almost free. You can ask an agent things you would never ask of a person. If a technical debate happens at the whiteboard, the agent can build two or three options and you can compare them.
Agents don't have experience, just a notebook. Auto memory only records notes on one machine. They don't transfer to your teammates' sessions. They aren't the experience and judgment you develop over the course of your career, and you need to write those lessons down for the whole team.
Agents are eager and confident. If you ask a good engineer to do something wrong, they push back. Agents are more likely to do what you ask, and you're likely to overtrust them. In Wharton research on cognitive surrender, participants accepted faulty AI answers most of the time, and grew more confident. You can counter the overconfidence by asking the agent to argue against its own answer.
You only have one agent archetype, and it changes every few months. Human teams have diverse skills and strengths. All your agents have the same strengths and weaknesses, which shift with each model release.
You still have to train your junior devs. When agents take over the starter work junior devs need to learn the fundamentals of the craft, you have to create those reps intentionally as a manager.
The human team still matters. Sometimes you can spend a day managing agents without realizing that you've crowded out the time it takes to build a cohesive team. Don't do this.
You don't need the title
Best practice: Focus your effort on making good software happen: setting the context, defining done, and reviewing well.
Anti-pattern: Evaluating yourself by lines of code while running under-briefed, unchecked agents.
Good staff engineers have always been like this. They write the design doc. They set the context. They do a thorough review. They make the people around them better. Agents let all engineers do this on day one. They give you a crash course on management. You get feedback in minutes, not quarters. You can undo your own mistakes. The job is becoming less about writing the code and more about being the reason good code gets written.
Nobody's born a great manager (or a great engineer). You build skills the same way you always have, through practice. But with agents, practice is cheap.
Try these ideas:
Every task needs a check it can run. Ask for the proof.
Tell the agent what it can't see and leave out what it can.
Talk through the plan before writing the code.
Corrected something twice? Log it in CLAUDE.md. Repeated workflows? Turn them into skills.
Two failed corrections? Restart and rephrase the prompt.
Review the diff as if you'll get paged for it.
You don't have to want to be a manager. But the engineers who do well with agents will have learned to manage along the way.
管理智能体（agents）的技能几乎就是管理团队的技能，而且你不需要成为一名管理者也能学习它们。
如果你整天都在和编程智能体打交道，你就是在做管理。你在不断地选择任务、编写指令、委派工作、跟进进度、评估结果，并决定最终发布什么。从智能体中获益最多的工程师，未必是那些最擅长提示词工程（prompt engineering）的人。他们是那些学会了如何管理的人，无论是有意还是无意。
这可能是一个不受欢迎的想法。我敬佩的许多工程师选择了个人贡献者（Individual Contributor, IC）的职业道路，因为他们希望贴近实际工作。他们看着朋友成为管理者，然后消失在日历的会议中。但我不是让你成为那样的管理者。我在这里使用“管理”一词是在特定意义上的：通过赋能他人的工作来产生良好的结果。而且我绝不是在说智能体可以替代管理者或同事。
你对糟糕管理者的每一个抱怨，都是与智能体交互时的一个 bug 报告。想想任务交接（handoffs）。如果你经历过糟糕的交接，你可能会收到一个感觉模糊、缺乏上下文或者期望总是在变的任务。对 IC 来说好消息是，既然你多年来一直处于任务交接的接收端，你可能知道一次好的交接是什么样的。
我之前写过你的编程智能体需要一个管理者。我也写过关于委派工作的隐性风险：认知投降（cognitive surrender）。这篇文章将优秀的工程管理实践与我们使用和创建 Claude Code 中学到的经验进行了比较。各部分大致按影响力排序，因此最具杠杆效应的习惯排在最前面。
给它一种检查自身工作的方法
最佳实践：为智能体提供一种验证其工作的机制，如测试套件、构建或截图，并让它向你展示结果作为证明。
反模式：将“看起来完成了”作为确认。这迫使你进行所有的验证，使你成为智能体的测试套件。
问问经验丰富的管理者，他们如何在不阅读所有内容的情况下确信团队产出了高质量的工作，他们会谈到护栏（guardrails）。CI、代码审查、仪表盘、值班等等。不建立护栏的经验不足的管理者最终会亲自验证一切，不到一个季度他们就会成为瓶颈。对智能体来说也是如此。正如 Claude Code 最佳实践指南所解释的，当工作看起来完成时，智能体就会停止。如果没有验证，“看起来完成了”就是智能体唯一的验证方式。提供一种验证工作的机制，可以让智能体执行工作、运行验证器、查看失败并自行纠正。对于 UI 更改，这可能意味着实际在浏览器中打开页面并进行迭代，直到它正常运行且外观良好。
验证机制几乎可以是任何东西，只要它能产生明确的通过/失败结果。想想测试、构建退出代码、linters、diff 脚本和截图。该指南指出，运行这些验证的命令是你在 CLAUDE.md（智能体每次会话开始时加载的指令文件）中能拥有的最有用的一行。一旦你有了验证机制，可以通过以下几种方式将其引入你的工作流：
直接要求。“运行 auth 测试，并继续直到它们通过。”
设定目标。使用 /goal，一个单独的模型会在每一轮对话后运行条件检查，这在执行长时间后台任务时最有用。
强制执行。Stop hook 可以阻止当前轮次完成，直到类型检查通过。
让它接受审查。/code-review 将 diff 发送给一个新的子智能体（subagent，它没有看到你的对话）进行审查，就像作者不会批准自己的 PR 一样。
你甚至可以控制审查的范围。如果你让它找问题，它总能找到些什么。但如果你让它找正确性问题并忽略风格，它就会照做。这也是优秀管理者学习如何寻求反馈的方式。Claude Code 工具包中的大部分功能都是为了收紧这个循环。技能（Skills）、钩子（hooks）、子智能体（subagents）和 MCP 的存在都是为了弥合执行工作与验证工作之间的差距，这样你的注意力就只集中在智能体无法验证的事情上。这正是经验丰富的工程管理者所做的。
设定清晰的上下文
最佳实践：提供一份清晰的摘要，说明智能体无法通过检查代码库（repo）得知的内容，包括：任务目标及其重要性、约束条件、范围外事项和成功标准。
反模式：传递一行代码的任务，而真正的期望只存在于你的脑海中；或者在简报中塞满智能体通过阅读代码就能发现的内容。
高效的管理者会对期望的结果、约束条件和目标进行清晰的描述。他们会明确说明工作应该达成什么目的，但给予执行工作的人自由去探索如何完成它。在军队中，这被称为指挥官意图（commander's intent）。在 Netflix，这被称为“提供上下文，而非控制（context, not control）”。
与智能体合作的挑战在于，很难知道智能体缺少什么上下文。编程智能体在每个任务中做的第一件事就是阅读你的代码。当前的模型在捕捉你的文件夹结构、约定和测试设置方面非常出色，比你描述它们要快得多。
在写下任何内容之前，先想想智能体能自己弄清楚什么。如果智能体可以在你的代码中读到它，而且它实际上也会去读，你就不需要说任何话。把你的文字花在代码库中不存在的内容上——例如，会议决定、某人的内部部署流程、为什么这项任务很重要，以及这次“完成”意味着什么。
让我们以一个模糊的任务“让仪表盘变快”为例，并将其转化为一个提示词。这里的数字仅供示例。
Get p95 load time for the /team dashboard under 2s for orgs with 10k+ members.
Why: enterprise admins open it daily, and slow loads are their top support ticket.
Constraints: no schema changes; keep the API response shape.
Out of scope: UI changes; caching the whole page.
Check: run scripts/perf/team.sh and show before and after numbers.
你不需要对每个任务都这样做。如果你正在做探索性工作，写一个通用的提示词完全没问题。你只需在进行过程中稍微细化一下。如果你还没准备好写提示词，可以让智能体采访你，直到它能写出规格说明，将该规格保存到文件中，然后与智能体开启一个新会话并基于此进行构建。你可以稍后使用该规格进行对照审查。
你可能还需要给你的智能体提供其他工具的访问权限，比如你的问题追踪器（issue tracker）、错误仪表盘或团队聊天。像对待团队新成员一样对待你的智能体。如果是一个它已经知道的 CLI 工具，比如 gh，你通常不需要告诉它任何东西。
让每次纠正都产生复利效应
最佳实践：当你多次纠正同一件事时，将其记录在团队的 CLAUDE.md 中，或将其转化为共享的技能（skill）。随着时间的推移，检查更新的模型是否减少了这些纠正的需要。
反模式：每次会话都手动纠正同一件事，或依赖于只存在于你个人机器上的隐性知识。
最大化 CLAUDE.md 价值的团队会半频繁地更新它，并记录从值得预防的错误中吸取的教训。一些团队甚至在代码审查中提及 @claude，将反馈转化为永久性策略。保持 CLAUDE.md 简洁。以下是适合放入其中的内容类型：
如何验证某事（确切的命令）
代码中具有误导性的区域
代码库中不存在的决策
任何你纠正过两次的内容
这些都是书面信息复利特性的例子。它的寿命长于人员的团队更迭和模型的替换。
让它做决定，只强制执行不可妥协的事项
最佳实践：默认让智能体做决定，只对那些必须始终发生或绝不发生的事情使用硬性强制（例如，hooks、deny rules）。
反模式：用全大写字母写规则，为可选的偏好定义 hooks，或者在新模型早已超越旧模型很久之后仍保留旧模型的习惯。
Andy Grove 的《High Output Management》将此描述为任务相关成熟度（task-relevant maturity）：监督水平应取决于一个人在特定任务中的历史表现，而不是他们的整体能力。
给新管理者的一个老建议也表达了同样的意思：给予人们比你认为舒适的再多一点的自由度，同时支持他们并让他们承担责任。
Claude Code 采纳了这一点并将其明确化：提示词、CLAUDE.md 和技能是模型可以考虑并选择执行的请求；hooks、deny rules 和托管设置是始终强制执行的要求。在大多数情况下，你希望智能体来做决定。通常，看着真实代码的模型比你提前设定的规则更有资格判断某条指南是否适用。使用强制执行来设定硬性要求，例如“绝不编辑生成的客户端”或“始终运行 license-header 脚本”。特别是，新的终端和 VS Code 会话会以自动模式启动，并带有一个分类器，可以过滤掉不安全的行为，如部署到生产环境或强制覆盖他人的工作。
该指南的建议有两个方面。如果你对 CLAUDE.md 中的某一行赋予了更多强调，而智能体仍然没有注意到，那它应该是一个 hook。如果一个 hook 表达的是一种偏好而不是要求，就应该将其移除，让智能体来做主。这就像你的团队决定废弃一个不再有用的流程。这也意味着当你使用新模型时需要调整。该指南保留了一份你可以停止的习惯清单：全大写的指令、“think harder”（effort 现在是一个设置项）和“don't be lazy”。对于当前的模型，这些往往会导致过度强制的规则和过度工作。对于智能体来说，过度流程化就是新型的微观管理（micromanagement）。
在构建前做好计划
最佳实践：在智能体开始编码之前设定一个商定的计划，审读潜在的假设，并将任务划分为不重叠的并行工作。
反模式：允许多个智能体同时处理重叠的任务，然后花整个下午解决合并冲突和重复的决策。
这里的一个好工作流是首先进入计划模式并迭代你的计划，直到找到正确的方案，然后再委派编码工作。有了一个好计划，模型通常可以一次性完成所有构建。对于较大的任务，使用第二个会话像资深工程师（staff engineer）那样审查计划；这是一次设计审查，也是以最低成本纠正错误方向的地方。在审查计划时，寻找潜在的假设（在 1:1 会议中这相当于问：“你有什么不确定的地方？”）。
任务分解正越来越多地被委派给智能体。Claude Code 中的 /batch 接受一个大型机械性更改，创建 5 到 30 个任务，展示计划，在单独的 worktrees（代码库的单独检出）中执行它们，并为每个任务创建一个 PR。你不再需要划分工作，只需检查各个切片是否有重叠，并确保共享接口优先落地。没有这一点，你可能会得到一种虚假的并行度。五个智能体处理重叠的任务不会带来五倍的产出，而是会导致一个有五个作者的合并冲突。
尽早引导，快速重置
最佳实践：观察第一分钟并引导智能体。一旦看到它偏离方向，立即纠正。如果你已经进行了两次失败的纠正尝试，请使用全新的会话和更好的提示词重新开始。
反模式：进行第三次或第四次尝试来纠正智能体，而不是纠正请求本身。
经验丰富的管理者知道，如果一个有能力的人多次失误，问题可能出在上游的指令、上下文或范围上。智能体版本的说法很明确：一旦智能体偏离方向，按 Esc。如果你已经进行了两次失败的纠正尝试，清除会话并写一个更好的提示词，结合你学到的教训。第三次尝试纠正智能体，大多只是增加了模型必须不断重读和重新处理的信息（包括失败的尝试）。
低成本的回滚也在改变游戏规则。/rewind 将代码和对话回滚到较早的时间点，这使得首先尝试更具野心的方案变得低风险。优秀的管理者对员工也是如此：如果纠正错误的成本很低，就让他们尝试有野心的方案。然后进行事后复盘，并在适用时将修复方法泛化到 CLAUDE.md 中。
委派任务，绝不委派判断
最佳实践：智能体执行工作，你决定重要的事情：产品决策、安全边界、发布什么。把每一个 diff 当作你会为此收到告警呼叫（paged）来对待。
反模式：因为测试通过且命名看起来合理就批准巨大的 diff。这不是代码审查，这是代码批准盖章。
没有哪个管理者可以说“这是我的下属发布的，不是我”。对你运行的每个智能体也是如此。我自己就掉进过这个陷阱。我让一个智能体研究与竞争对手的差距，并编写本地 PR 来填补这些差距。我阅读了研究，粗略浏览了代码，差点就推送了那些给用户增加复杂性却收益甚微的更改。我委派了工作，也差点委派了决策。这是一个很容易掉入的陷阱：这是一个 600 行的 diff，命名看起来合理，测试通过，批准。
这样拆分任务是有道理的：让智能体处理风格、linting、审查的后续跟进、典型 bug 和单元测试，但让人类处理安全边界、合规性和产品决策。
协调工作也是如此。智能体可以跟踪任务交接，但在相互竞争的请求之间做决定并让人们真正做出承诺，仍然是人类的工作。
你不需要处于每次更改的内部循环中。你确实需要掌控的是外部循环：约束条件是什么、你实际阅读了多少输出、保留了什么证据，以及什么需要人类签字确认。并且保持更改较小，因为审查的单位就是理解的单位。
设计不需要你的运行流程
最佳实践：在部署自主任务之前，定义完成标准、自我验证、边界、护栏和人工批准。
反模式：睡前启动一个长时间运行的流程，没有定义完成标准或停止点，第二天早上醒来发现你的模型整晚都在一个错误的前提下工作。
跨级管理者（Skip-level managers）不管理个别工程师的工作；他们管理的是目标、护栏、检查点和负责人。AI 智能体正在遵循类似的轨迹。他们已经将任务的一部分委派给子智能体，并且它们可以按计划自主运行，或者在 CI 失败后或新的 PR 开启后运行。前沿的发展方向是能够自主启动、自我验证，并且仅在需要决策时才呼叫人工干预的自治系统。
角色从控制会话转变为设计你的循环。在设计无人值守运行时要问自己的五个问题，与优秀管理者在给资深工程师分配项目并去度假前问的问题相同：
它知道“完成”是什么样子的吗？（目标条件、规格文件，或者一个它必须让其变绿的失败测试。）
它有自我验证机制吗？（测试套件、Stop hook 或审查步骤。）
它的边界是什么？（权限控制、沙盒、worktree，或者它被允许推送的那一个分支。）
它的护栏是什么？（轮次限制或花费限制。）
它在哪里产出结果，由谁批准？（PR 或摘要，以及人类对任何不可逆操作的批准。）
该指南还有两个管理者会认为是良好实践的习惯：试点，即让批处理任务在三个文件上运行，迭代提示词，然后再运行其余的；以及在信任其无人值守之前，观察任何新事物的最初几次运行。把它看作是一个试用期。
扩展验证，而非注意力
最佳实践：只有在检查、目标和新的审查者能够接管监控的情况下，才加快扩大智能体的使用，并且在衡量吞吐量的同时衡量质量。
反模式：开启比你能够良好审查的更多的会话，并以 AI 编写了多少代码来衡量成功。
管理者很快就会了解自己的管理幅度。超过一定数量的直接下属后，每个人得到的管理者关注就会减少，质量也会下降。对智能体来说也是如此。这就是我所说的编排税（orchestration tax）：过了最初的几个智能体之后，每增加一个智能体，需要的注意力都比上一个更多。大多数日子里，我运行四五个后台智能体和几个本地会话，有些日子这都嫌多。
管理大量会话不在于保持高度专注，而在于将大部分监控工作委派给自我评估、目标和全新上下文的审查者，并将注意力保留给决策。使用通知代替轮询，以及拥有后台作业的集中视图，也会有所帮助。你无法通过增加监控来扩展智能体的数量，只能通过减少需要监控的内容来扩展。然后衡量系统而不是活动。有用的指标包括 PR 的周期时间、新员工的适应时间以及回滚或返工的频率。衡量 AI 编写代码的百分比并不是一个有用的目标，因为你的目标是质量和可靠性。Grove 的衡量与反衡量规则在这里同样适用：如果你衡量合并的 PR 数量，那么也要衡量回滚和返工。
决定不构建什么
最佳实践：问谁需要它，你如何知道它起作用了，什么会让你停止，并限制在制品（WIP）。
反模式：把每个看似合理的想法都扔进一个 PR 中；毕竟构建成本很低。你现在将拥有一个团队需要审查、保护和维护的“垃圾抽屉”。
管理者说的最重要的词通常是“不”。对于智能体，说“不”变得更难了。开始工作几乎是免费的，你可以在午饭前把任何合理的想法变成一个 PR。但你现在会有一堆 PR 需要团队去审查、保护、支持和维护。审查和验证现在成了稀缺资源。
事实上，旧的管理问题现在比以往任何时候都更重要。谁要求这么做的？我们如何衡量成功？我们怎么知道何时该停止？如果构建成本很低，那么困难的问题就不是“我们能做吗？”，而是“我们应该做吗？”
类比失效之处
最佳实践：遵循管理最佳实践，但要考虑到智能体模型中的差异，如低成本的返工、它们轻易同意的倾向，以及随着每次模型发布而变化的优势。
反模式：认为智能体就像初级开发者，或者认为因为你能运行五个智能体，就准备好管理五个人了。
这个类比有用但不完美，这项工作最优秀的实践者清楚它在哪里不完美：
管理人更难，而且技能无法逆向转移。你不会因为运行过五个智能体就准备好管理五个人。在激励、冲突、职业发展或长达数月的信任建立方面，两者没有等同之处。
返工几乎是免费的。你可以向智能体提出你绝不会向人提出的要求。如果在白板前发生技术辩论，智能体可以构建两三个方案供你比较。
智能体没有经验，只有一个笔记本。自动记忆（Auto memory）只在一台机器上记录笔记。它们不会转移到你队友的会话中。它们不是你在职业生涯中积累的经验和判断，你需要将这些教训写下来供整个团队使用。
智能体热情且自信。如果你让一名优秀的工程师做错事，他们会反驳。智能体则更可能照做，而你很可能会过度信任它们。在 Wharton 关于认知投降的研究中，参与者大多数时候接受了有缺陷的 AI 答案，并且变得更加自信。你可以通过让智能体反驳自己的答案来对抗这种过度自信。
你只有一种智能体原型，而且它每隔几个月就会改变。人类团队拥有多样化的技能和优势。你所有的智能体都有相同的优势和劣势，并随着每次模型发布而发生转变。
你仍然需要培训你的初级开发者。当智能体接管了初级开发者学习手艺所需的基础工作时，作为管理者，你必须有意地为他们创造那些练习机会。
人类团队仍然很重要。有时你可能花了一整天管理智能体，却没有意识到你已经挤占了建立一支有凝聚力团队所需的时间。不要这样做。
你不需要头衔
最佳实践：将精力集中在促成优秀软件的诞生上：设定上下文、定义完成标准并进行良好审查。
反模式：在运行缺乏简报和不受检查的智能体时，以代码行数来评估自己。
优秀的资深工程师一直都是这样的。他们编写设计文档。他们设定上下文。他们进行彻底的审查。他们让周围的人变得更好。智能体让所有工程师在第一天就能做到这一点。它们为你提供了一门管理速成课。你在几分钟内就能得到反馈，而不是几个月。你可以撤销自己的错误。这份工作正变得越来越少地关乎编写代码，而更多地关乎成为优秀代码被编写出来的原因。
没有人天生就是伟大的管理者（或伟大的工程师）。你建立技能的方式一如既往，就是通过实践。但有了智能体，实践的成本很低。
尝试这些想法：
每个任务都需要一个可以运行的检查。要求提供证明。
告诉智能体它看不到的内容，省略它能看到的。
在编写代码之前先过一遍计划。
纠正过两次的东西？记录在 CLAUDE.md 中。重复的工作流？把它们变成技能。
两次纠正失败？重启并重新表述提示词。
审查 diff 时，就像你会为此收到告警一样。
你不必非得想成为一名管理者。但那些在使用智能体方面表现出色的工程师，一定在这个过程中学会了管理。
