🔶 我不再审查 Agent 写的代码了：我现在这样做

**提醒：这篇内容面向高级用户。**它假设你已经每天都在使用 Claude Code 等编程 Agent 开发，并且熟悉 CI、合并队列和功能开关。如果你还处于 AI 使用之旅的早期阶段，建议先收藏，之后再看。Operate 系列文章会是更好的入门起点。

两周前，我改变了构建软件的方式。从那以后，我合并了 562 个 PR；而且说实话，其中有四个晚上我还在山里徒步。

视频中，我会完整讲解自己如今的工作方式。下面这篇文字是配套说明：包括配置、提示词、数据，以及你本周可以尝试的做法。

如果你还在审查 Agent 写出的每一行代码，这篇文章就是写给你的。

1. **设定意图。**与 Agent 一起规划，直到你们对要构建什么、为何构建达成一致。

2. **设定护栏。**建立 Agent 无法绕过的测试、CI 和审查机器人。

3. **设定目标。**一个会话、一个协调 Agent、由子 Agent 执行具体工作。

4. **让它以小块方式合并。**自动合并、功能开关、验证、重复。

模型在过去几周发生了巨大变化，尤其是 Opus 5.5。几周前，我不会建议任何人这样工作。我一直觉得自己必须检查产出：质量够好吗？这该合并吗？

现在我认为，只要正确设置两件事，Agent 就能独立完成一整套计划：正确的意图，以及确保意图真正得到落实的正确护栏。把这两点做好，你就可以真正让它跑起来。

这些工作大部分都投入到了 Sightline——Spare 的内部运营平台。那里是我最先试验一切的地方。

AI 代码具有非确定性，也存在风险。但人写的代码同样具有非确定性，也有完全相同的风险。我们构建 SRE 系统，是为了避免人犯错。现在，我们需要同样的系统，只是要强化得多，来避免 Agent 犯错。

这和我们用于处理事故的无责文化是一样的：当 Agent 犯错时，不要责怪 Agent。要问的是，缺少了哪一道护栏，然后把它建立起来。

这并不意味着质量不再重要。Agent 也会制造混乱。正因如此，护栏才是关键工作。以下是每个 Sightline PR 在能够合并前都要经历的流程：

因此，当某个 PR 进入队列时，我知道它不可能跳过任何一个红旗信号。

护栏也会保护自身。我们让 Bugbot 持续要求补充更多测试。CI 中的这些反馈闭环，让我们能够在不冒及可用性风险的前提下如此快速地推进。而当有问题漏网时，我们不只是修复代码，还会修复护栏。

每个会话都以同样的方式开始。我打开 Claude，与它一起制定计划：如何拆分、有哪些挑战、有哪些风险。我也经常要求它提供 UX 预览，以便在任何功能开始构建之前，先看到它实际使用起来会是什么感觉。

这就是我现在投入大部分时间的地方。我审查计划，而不是代码。

一旦我与计划达成一致，我就打开一个会话并设定目标。下面是我逐字使用的提示词：

完成这份计划。通过自动合并交付代码。你是协调者。不要亲自执行工作。所有事情都使用子 Agent，并尽可能并行化。

“协调者”这一部分帮助很大。顶层 Agent 只保存计划和状态，因此其上下文保持干净。子 Agent 承担繁重工作，并会随着计划逐步展开而来去调度。

我让它自行合并，说实话，这相当安全。这些模型很谨慎，也不想搞坏东西。让它们把所有功能都置于功能开关之后，它们就会这么做。由于能够合并，它们会以小块方式交付：先交付一部分，在预发布或生产环境中运行端到端测试，确认有效后，再交付下一部分。多阶段部署，小步增量。

一个可能有争议的观点：最终来看，一个你在本地反复迭代的大 PR，可能比二十个各自通过所有检查的小 PR 风险更高。

我回来后会要求查看进度报告。Agent 会生成一份 HTML 报告：已经完成什么、接下来做什么、它需要我提供什么。这才是我审查的内容。

我认为大多数人忽略的一点是：让目标在夜间持续运行，如果需要，甚至连续运行数天。我们的自定义角色目标运行了一天多。我会定期查看、阅读报告、在需要时推动一下，然后让它继续运行，直到真正达成目标。

我通常会同时运行两到四个目标，分别针对互不相关的功能，以免彼此干扰。这就是让我们能够极快推进工作的原因。

我们大多数人仍然把这些工具当作一个速度极快的工程师来使用：实现这个工单，添加那个端点。这当然有效，但思路太小了。通过目标工作流，你可以设定更高层次的意图，提出开放式问题，或者直接交给它一个完整的业务问题，让它自己判断需要做什么。

• 与其说“添加一个角色编辑器”，不如把目标设为“让 Sightline 的权限体系在所有地方都像 Spare 一样工作”。

• 与其说“把 OKR 移到一个 package 中”，不如设为“把 Sightline 变成可供其他团队扩展的平台”。

你还可以把它推得更远：

• “我们的 CI 太慢了。让它变快。”就这样。让它自己找出时间花在哪里，并加以修复。

• “我们某个企业客户的 PPVH 偏低。深入分析五天的数据，找出可以怎样优化。”这是真实的业务问题，而不是编码任务。

• “我们的前端 UX 在管理面板中不一致。找出这些不一致之处，并帮助我们消除它们。”

这些不是工单，而是结果。现在的模型已经足够擅长接受一个结果、将其拆解，并为之持续工作一天或更久。

一旦你这样工作，token 就会成为瓶颈。单个套餐提供的额度已经不够我们使用，而超额费用又极其昂贵。

我目前的做法是运行多个 Claude 账号，大约五个，每个约 200 美元，并通过名为 Claude Swap 的工具在它们之间切换。它会监控每个账号的五小时和七天用量；当某个账号达到 90% 时自动切换，因此所有任务都可以持续在后台运行。

这并不完美。切换账号时，你会失去 Claude artifacts 和移动端远程控制等功能，而且我不断需要在浏览器和手机上重新登录。这会浪费时间。因此，这周我一直在研究能够解决同样问题、又不需要切换账号的工具：Paseo、Orca、Superset，以及其他一些工具。

我们的工作正在远离交付一个个单独的功能，而转向构建能让产品不断演进的系统。我们设定意图，并构建能够朝着这一意图自我修复的系统。

我们已经在这样做了：自动修复 bug 的自动化、用于 SRE 工作的自动化、执行漏洞研究的 Agent，以及自动修复这些安全风险的早期探索。下一步将是能够发现低质量问题、数据库和渲染性能问题、UI 不一致问题的系统，以及负责修复这些问题的 Agent；还有能够发现测试覆盖缺口并编写测试的 Agent。

重点不再是由我们逐一找出每件事，而是建立护栏，让系统不断自我修复，变得更好。

1. **停止在一个真实功能上检查代码。**先从低风险事项开始。随着信心增强，再用在更大的事项上。

2. **给它一个问题，而不是一个工单。**看看它能走多远。

3. **审视你正在触及的范围。**还缺少什么护栏，才能让 Agent 无法出错？什么闭环可以自行修复问题？

我很想听听哪些方法对你有效。如果你尝试了，欢迎回复或留言，告诉我发生了什么。我还会写更多关于如何使用 Agent 构建产品的内容。

Alexey

Heads up: this one is for power users. It assumes you already build with coding agents like Claude Code every day and are comfortable with CI, merge queues, and feature flags. If you're earlier in your AI journey, bookmark it for later. The posts in Operate are a better place to start.

Two weeks ago, I changed how I build software. Since then I've merged 562 PRs, and honestly, I spent four of those nights hiking in the mountains.

In the video I walk through exactly how I work now. Below is the written companion: the setup, the prompt, the numbers, and the things to try this week.

If you're still reviewing every line your agent writes, this one's for you.

1. Set the intent. Plan with the agent until you agree on what's being built and why.

2. Set the guardrails. Tests, CI, and review bots that an agent can't get around.

3. Set a goal. One session, one coordinator agent, sub-agents doing the work.

4. Let it merge in small pieces. Auto-merge, feature flags, verify, repeat.

The models changed dramatically in the last few weeks, Opus 5.5 especially. A couple of weeks ago, I wouldn't have told anyone to work this way. I always felt I had to check the work. Is the quality good enough? Should this get merged?

Now I feel an agent can work through a whole plan on its own, as long as two things are set up right: the right intent , and the right guardrails to make sure that intent is actually met. Get those right and you can let it really run.

Most of this work went into Sightline, our internal operations platform at Spare. It's where I try everything first.

AI code is non-deterministic and has risk. But human code is non-deterministic too, and it has the exact same risk. We built SRE systems so humans don't make mistakes. Now we need those same systems, way more beefed up, so agents don't make mistakes.

Same blameless culture we use for incidents: when an agent makes a mistake, don't blame the agent. Ask what guardrail was missing, and build that.

This doesn't mean quality stops mattering. Agents make messes too. That's exactly why the guardrails are the job. Here's what every Sightline PR goes through before it can merge:

So when something's queued, I know it couldn't skip a single red flag.

The guardrails also guard themselves. We ask Bugbot to keep asking for more tests. Those feedback loops in CI are what let us go this fast without risking uptime. And when something slips through, we don't just fix the code. We fix the guardrail.

Every session starts the same way. I open Claude and work out a plan together: how it's broken up, what the challenges are, what the risks are. I often ask for a UX preview too, so I can see what it'll feel like before anything gets built.

This is where I spend most of my time now. I review the plan, not the code.

Once I'm aligned on the plan, I open a session and set a goal. This is the prompt I use, word for word:

Accomplish the plan. Ship code using auto-merge. You're the coordinator. Don't do work directly. Use sub-agents for everything, and parallelize when possible.

The coordinator part helps a lot. The top-level agent only holds the plan and the status, so its context stays clean. Sub-agents do the heavy work and come and go as the plan gets built out.

I let it merge on its own, and honestly, it's fairly safe. These models are careful and don't want to break things. Ask them to feature-flag everything and they will. Because they can merge, they ship in small pieces: ship something, run end-to-end tests in staging or production, check that it works, ship the next thing. Multi-stage deploys, small increments.

A bit of a hot take: one big PR you're iterating on locally is probably riskier in the end than twenty small ones that each passed every check.

I come back and ask for a progress report. The agent builds an HTML report: what's done, what's next, and what it needs from me. That's what I review.

Here's the part I think most people miss: let goals run overnight, for days if they need to. Our custom roles goal ran for over a day. I checked in periodically, read the report, nudged it when needed, and let it keep going until it actually hit the goal.

I usually have two, three, or four goals running at once, on unrelated features so they don't step on each other. That's what lets us rip through things really fast.

Most of us still use these tools like a really fast engineer: implement this ticket, add this endpoint. That works, but it's thinking too small. With the goal workflow you can set much higher-level intent, ask open-ended questions, or hand it a whole business problem and let it figure out what needs to happen.

• Instead of "add a role editor," the goal was "make Sightline's permissions work like Spare's everywhere."

• Instead of "move OKRs into a package," it was "turn Sightline into a platform other teams can extend."

You can push it much further:

• "Our CI is too slow. Make it faster." That's it. Let it find where the time goes and fix it.

• "We're seeing low PPVH for one of our enterprise customers. Dig into five days of data and figure out how we can optimize it." That's a real business problem, not a coding task.

• "Our front-end UX is inconsistent across the admin panel. Find the inconsistencies and help us remove them."

Those aren't tickets. They're outcomes. The models are now good enough to take an outcome, break it down, and work toward it for a day or more.

Once you work like this, tokens become the bottleneck. Individual plans don't give us enough credits anymore, and the overages are super expensive.

What I've been doing is running multiple Claude accounts, about five at around $200 each, and switching between them with a tool called Claude Swap. It watches five-hour and seven-day usage on every account and switches automatically when one hits 90%, so everything keeps running in the background.

It's not perfect. When you switch accounts you lose things like Claude artifacts and remote control from the mobile app, and I'm constantly logging in again in the browser and on my phone. It wastes time. So this week I've been looking at tools that solve the same problem without the switching: Paseo, Orca, Superset, and a few others.

Our job is moving away from shipping individual things. It's moving to building the systems that evolve our product. We set the intent, and we build systems that self-heal toward it.

We're already doing it: automations that fix our bugs, automations for SRE work, agents that do vulnerability research, and early work on remediating those security risks automatically. Next are systems that find poor quality, performance issues in the database and rendering, and inconsistencies in our UIs, and agents that fix them. Agents that find gaps in test coverage and write the tests.

It's not us figuring out each individual thing. It's standing up guardrails that keep healing the system into a better place.

1. Stop checking the code on one real feature. Start with something low-risk. As you build confidence, try it on something bigger.

2. Give it a problem, not a ticket. See how far it gets.

3. Look at the surface area you're touching. What guardrail is missing so an agent can't get it wrong? What loop could fix things on its own?

I'd love to hear what's working for you. If you try this, hit reply or drop a comment with what happened. I'll be writing a lot more about how we're building with agents.

Alexey