Juggling five to ten AI coding agents at once is less a test of model choice than a test of a developer's capacity to delegate and verify, according to a practitioner essay republished by O'Reilly Radar.
The piece, written by Addy Osmani for his Elevate blog and carried on O'Reilly's Radar with his permission, opens from inside a working setup rather than a research lab: "The way that I typically work is I have anywhere between five and ten agents working at the same time in parallel. There are going to be some tasks that I'm very happy to delegate fully […]."
Delegation, not generation, is the constraint
As described in the source summary, the essay's central premise is that once an engineer is running several agents concurrently, the scarce resource stops being code output and starts being human verification. The question shifts from "how do I get the model to write this?" to "which tasks can I hand over, and how do I confirm what comes back?"
That framing puts the developer's attention — not the agent's capability — at the centre of the workflow. Delegation is presented as a judgement to be made task by task, with some work handed off wholesale and other work kept under close review.
The summary does not itemise the specific techniques Osmani recommends, and this article does not attribute any particular method to him beyond the delegation-and-verification premise above. The full essay is the place to check for concrete workflow steps.
From individual habit to team policy
Whatever specific practices the full essay sets out, the underlying logic has an obvious read-across for teams rather than solo practitioners. An individual developer can run on instinct; a team adopting AI-assisted workflows generally cannot. Someone has to decide which classes of tasks are eligible for delegation, who signs off on each class, and how that sign-off is recorded — otherwise "we use agents" quietly becomes "no one checked this."
It is worth stating the caveat plainly: this is practitioner commentary describing one developer's working setup, not controlled research or a benchmark result. Its value is as a description of lived practice, and it should be weighed accordingly.
Why it matters
The piece is relevant to any development team adopting AI-assisted workflows, including in Hong Kong, because it reframes the adoption question. The debate over which coding model to standardise on may matter less than whether a team has decided what it will and will not delegate, and how it verifies what comes back. Under that framing, the discipline being built is one of attention management as much as tooling.
Source: O'Reilly Radar, "Practical Loop Engineering," originally published on Addy Osmani's Elevate blog.
據 O'Reilly Radar 轉載的一篇實戰文章指出，同時操作五至十個 AI 編程 agent，與其說是對模型選擇的考驗，不如說是對開發者委派與驗證能力的考驗。
該文由 Addy Osmani 為其 Elevate blog 撰寫，經其許可後刊登於 O'Reilly 的 Radar，開篇即從實際工作環境而非研究實驗室切入：「我通常的工作方式，是同時並行運行五至十個 agent。有些任務我很樂意完全委派出去……」
瓶頸在於委派，而非生成
根據原文摘要所述，文章的核心前提是：當工程師同時並行運行多個 agent 時，稀缺資源便不再是程式碼產出，而是人手驗證。問題的焦點亦由「如何讓模型寫出這段程式碼？」轉變為「哪些任務可以交出去？又如何確認交回來的結果？」
這種框架將開發者的注意力——而非 agent 的能力——置於工作流程的中心。委派被視為一項須逐項任務作出的判斷：部分工作全權交託，其餘工作則須密切監督。
該摘要並未逐項列出 Osmani 建議的具體技巧，本文亦不會將上述委派與驗證前提以外的任何特定方法歸於其名下。完整文章才是查閱具體工作流程步驟之處。
從個人習慣到團隊政策
不論完整文章列出了哪些具體做法，其背後邏輯對團隊而非單打獨鬥的從業者有著明顯的啟示意義。個別開發者可以憑直覺行事；團隊採用 AI 輔助工作流程一般則不能。總要有人決定哪一類任務符合委派資格、每類任務由誰簽署批准、以及該批准如何記錄——否則「我們有使用 agent」便會悄然演變成「根本無人檢查過」。
有必要明確指出該保留事項：這是從業者評論，描述的是一名開發者的工作設定，並非受控研究或基準測試結果。其價值在於對實際工作習慣的描述，應據此衡量。
為何重要
這篇文章與任何採用 AI 輔助工作流程的開發團隊皆有關連，包括香港的團隊，原因在於它重新框定了採用的問題。圍繞應以哪種 coding model 為標準的爭論，重要性可能不及團隊是否已決定甚麼可以委派、甚麼不可委派，以及如何驗證交回的結果。在這種框架下，正在建立的紀律既是工具運用，同樣也是注意力管理。
來源：O'Reilly Radar，〈Practical Loop Engineering〉，原刊於 Addy Osmani 的 Elevate blog。