You can launch 100 coding agents. Who keeps them moving?

📝 摘要 #

作者在 30 天内用 Mac 运行 Claude、Codex、Grok、Cursor 及其子代理，累计 514 小时（约每天 17 小时）编码智能体活动，并据此提出六条规则来管理整条 SDLC。文章的核心判断是：增加智能体只是增加执行容量，真正稀缺的是结果产生之后的连接工作——把发现送入正在推进的实现、让决策跨会话延续、为每个结果指定去向、只把属于人的决策带回。为此应把目标当作贯穿 spike→spec→实现→审查→验证→产品决策的契约；只持久化决策与证据（revision、已接受/被否决方案、开放 finding、验证结果、下一步），而非整段对话；为每个结果指定目的地（继续、转交、验证、上报、搁置）；把 finding 定向路由给拥有代码上下文的会话；在明确边界内下放常规决策并用工具强制执行权限；最后以绑定当前 revision 的产品证据而非「改完了/绿灯了」来驱动下一轮迭代。

核心概念： 多智能体时代的瓶颈不是启动更多会话，而是让已有会话的产出带着证据持续流动到正确的下一个环节。

关键技术栈 / 关键要点：

1. 目标即契约 — 保持一份关于预期行为、约束与验收标准的唯一事实源，用 spec-driven development + TDD 让每个阶段都可判定。
2. 持久化决策与证据 — 交接给下一会话的是「当前现实的索引」：当前 revision、决策、被否决方案、开放发现、验证结果与下一步；代码、diff、测试输出、issue、截图承载细节。
3. 每个结果都要有目的地 — 继续、路由、验证、上报或明确搁置；避免制造自我生成任务的「智能体工厂」，也避免一个失败触发五个冗余修复。
4. 把发现路由到能改变结果的地方 — finding 要连同证据和明确请求的动作送给拥有代码上下文的会话；成功标准是对代码做出有理由的修改或拒绝，而不是「消息送达」。
5. 在目标内下放权限，用工具强制执行 — 权限绑定动作与环境而非模型信心；沙箱、hooks、策略检查做确定性约束，skills 只解释流程、不负责执行。
6. 先要产品证据，再决定下一轮 — commit 和绿灯只是证据碎片；真正需要的是与当前 revision 绑定的可观测产品结果（端到端运行、可复现性能提升、UI 走查、同输入前后对比）。

关键结论 / 实践建议： 这套方法用现有智能体即可执行：把目标与验收标准写在下一会话能找到的地方，留一份短检查点而非转录，给每个结果一个去向（包括 park/stop），把权限交给工具执行。可复用的 skill 或常驻指令能标准化流程，但无法跨会话持有目标、观察正在运行的会话并只带回属于人的决策——这正是 Vistara 试图补上的位置。

---

Six rules for running the software development lifecycle across a fleet of coding agents, November 2026.

Over the last 30 days, coding agents on my Mac accumulated 514 hours of runtime across Claude, Codex, Grok, Cursor, and their subagents. Roughly seventeen hours of agent activity per day.

Running more agents gives me more execution capacity. Harness engineering makes agents more capable through tools, context, permissions and feedback. The bigger unlock is connecting what they produce: getting findings into active implementations, carrying decisions across sessions, routing the next action, and bringing actual product results back for review. The bottleneck isn’t launching another session. It’s what happens to the result. Six rules I use to keep that work moving.

1. Make the goal the contract for the whole development cycle.
2. Persist decisions and evidence, not entire conversations.
3. Every result needs a destination.
4. Route the finding into the work that can use it.
5. Delegate routine decisions within an explicit boundary.
6. Bring back the product result and the next decision.

1. Make the goal the contract for the whole SDLC #

An idea can begin as a spike, turn into a spec or a PRD, then move through implementation, review, verification and a product decision. The goal has to make sense at every stage. Keep one source of truth for the intended behavior, the constraints and the acceptance criteria, and record decisions as the design evolves.

That's spec-driven development: the spec tells the implementation what it must achieve. Checks test the observable behavior. Work test-first (TDD): a failing test establishes the defect before an agent fixes it. On an interface, it may be an end-to-end interaction and a before/after capture. The evidence should fit the product, not the format of the prompt.

Codex /goal already gives a thread a persistent outcome and an evidence-based completion contract. Use the native capabilities of the tool you are in. A project-level goal keeps the same product outcome available when work moves across sessions, reviews and runtimes.

Try this: Ask the session that owns the change for a few observable acceptance criteria, and give the reviewer the same list. You should be able to judge the result without reading the author's summary.

2. Persist the decisions and evidence the next session needs #

The best handover is a map to current reality: the current revision, accepted decisions, rejected approaches, open findings, verification results and the next action. The code, the diff, the test output, the issue and the screenshots hold the detail. The checkpoint points to them.

Project instructions and skills are useful for durable conventions and repeatable procedures. They should not become a second, stale copy of the product state. That belongs in versioned artifacts and in the systems that actually ran the work.

When context compacts or another session takes over, the recipient should read that state and inspect the source. A new agent should not depend on remembering every sentence from an old conversation.

Try this: Write the revision, the decisions, links to evidence, and the next action. Open a fresh session with only that note; it should know what to do next without interviewing you.

3. Every result needs a destination #

When an agent returns, that result needs a destination. Sometimes that means continuing with the same owner, routing a finding to another session, running verification, or bringing me a product decision. Sometimes it means parking the work until I decide it is worth pursuing again.

I don't want an agent factory that keeps generating tasks for itself. I want development to advance according to the goals and priorities I have set.

The destination matters. A parked investigation should stay parked. A failed check needs an owner and a bounded repair. A review finding should reach the implementation it affects. A session that runs out of capacity can hand over its current state if the goal is still active. A session that runs out of capacity can hand over its current state if the goal is still active. This happens every week.

10月7日

Codex 已耗尽。 Vistara 将工作交给 Grok。 代理会变。工作继续推进。

Hooks and CI can generate the signals. Someone or something still has to connect those signals to the right goal and destination, once, and recognize when nothing more should happen. One failing check should not launch five redundant repairs. A reviewer and an implementer should not bounce the same finding forever, and a fresh agent should not start while one with the context still has capacity.

Try this: Park one session on purpose, and send one real finding to the session that owns the code. The parked session should stay quiet; the finding should reach one owner, with its evidence.

4. Route findings to the place where they can change the result #

During a rebuild of Split's options trading copilot, Claude was implementing a substantial change with many parallel subagents. I asked Grok to inspect part of the refined architecture against the code and best practices. The review found problems it was missing, including inconsistent pricing paths for an options structure.

I selected Grok's findings and sent them directly to the Claude session implementing the change. Claude already had the codebase context, checked the findings against the implementation, and revised its approach. I could follow the handoff and what happened afterward.

The same send works in the other direction. When an implementation session finished a review pack, I selected it and sent it to the reviewer.

Sending a review directly into the coding-agent session implementing the change.

A finding needs to reach the owner who can act on it, with evidence and an explicit requested action. The sender's model and the receiver's model are secondary. An existing session may have the right context. A fresh session may have the available capacity.

Try this: Take one evidence backed finding and give it to the session that owns the code. Success is a reasoned change or rejection against the code, not a message that merely arrived.

5. Delegate authority with the goal, and enforce it in tools #

Some decisions can be made once and reused. If the agreed scope allows local tests, read-only investigations and another review pass, those can proceed. Changes to product scope, sensitive access, spending and consequential releases cannot.

Attach permissions to the action and the environment, not to a model's confidence. Sandboxes and tool permissions enforce what can actually run. Hooks and policy checks apply deterministic constraints. Skills explain procedures. They do not enforce them.

Try this: Allow tests and edits on a feature branch, and block deploy or production secrets in the tool settings. The allowed action should run; the blocked one should be stopped by the tool, not by a prompt.

6. Ask for product evidence before directing the next iteration #

A commit and a green check are pieces of evidence. The return that matters is an observable result in the product, tied to the current revision, together with the decision that should happen next. That might be an end-to-end run, a reproducible performance improvement, a UI walkthrough, or before/after behavior against the same inputs.

For the trading-copilot issue, the proof is that the same options structure and inputs produce consistent quotes across the actual pricing paths. The review and the code changes are how you get there. The acceptance test is the behavior. If you are the one taking the screenshots, the agent is not done: ask it for the before and after.

That result becomes the next step in the SDLC: review, a staged release, a look at production telemetry, a fix-forward or the next experiment. Carry the decision and its evidence into the goal so the next iteration starts from what you learned.

Try this: Save the failing result before the change, then run the same check on the latest revision. If the code changed after you checked, run it again.

Keep the work moving #

You can run this method with the agents you already have. Write the goal and the acceptance criteria where the next session will find them. Leave a short checkpoint instead of a transcript. Give every result a destination, including park or stop. Send findings into the work they affect. Enforce authority in tools. Ask for revision-linked product evidence.

A reusable skill or standing instruction can standardize that procedure. What it cannot do is watch the sessions already running, hold the goal across them, or bring me only the decisions that are mine.

That is what Keki does in Vistara. On-screen AI supervisor whose goal is to keep the work moving. It watches the sessions already running on my Mac, holds the goal, reviews each turn, communicates with other agents, and brings me only the decisions that are mine.

https://vistara.dev