最近發生一個有趣的職場小插曲。

老闆在假期間，和 AI 暢聊了一個新產品計劃，然後將輸出的 PDF 寄給工程師。指定這個計劃需要「在 AI 指揮下」來完成。由 AI 來完成決策，看看最後會發生什麼。

工程師就把 PDF 拆解成 docs，然後建立 Harness，派出 subagent 開始進行轟轟烈烈的 coding。

跑了 72 小時後，在 GitHub 上有了不少的進度。

從工程師的角度，100% 的 AI coding。

今天老闆和工程師有一個快速的 sync up。

• 老闆說：我想要讓我的 agent 直接指揮這個專案，我已經和我的 ChatGPT 談了很久了，他最知道我要什麼。
• 工程師說：沒問題，現在所有的計劃都是根據那份 PDF 來做的。
• 老闆說：接下來我要看到有第二個 AI 和第三個 AI 加入進來，可以互相檢查。

但老闆的貼身助理和我開始煩惱一個問題：「如何讓老闆覺得自己正在指揮一場 AI 的 orchestration？」

• 我們問：要不要我們在 slack 上做兩個 bot，一個是 FABLE 一個是 ASTRO。然後可以互相 tag
• 工程師說：但每次寫完一包 commit 都會讓另一個模型來 review 啊，要看 review 記錄的話應該要看 GitHub 上的 issue 記錄。
• 助理：老闆不可能去看 GitHub 的，需要把溝通介面完全拉到 slack 上，讓他可以用自然語言與 agent 互動。

在工程師的世界觀裡，GitHub issue 上充滿了精彩的互動。

但我和助理總覺得，不拉到一個類 LINE 群的介面上，似乎那個「老闆與 AI 共舞」的主觀感覺永遠不會發生。

在各種工程理性與揣摩上意的大亂鬥後，最後的共識是：

• 老闆要的 AI-driven，不是指 100% AI coding。而是老闆不用找人類部下開會，就可以和自己的 agent 了解最新進度，並且叫「自己的 agent」去監督工程師有沒有按計劃執行。
• 遇事不決時，老闆不想要找人類開會，老闆希望看到 FABLE & ASTRO & SPARK 進行精彩絕倫的討論，然後派一個 agent 去告訴工程師結論，並監督後續工作執行。

至於工程端，工程師早就掌握 AI coding 的技能了，老闆並不關心他們是 100% 還是 99%。老闆在意的是中間不要再經過「工程師寫了一包 code 和老闆說這是照你的意思做的你看一下這是不是你要的」，這種連他自己都不知道在決定什麼的決策。

工程師很無奈地說：我大概理解你的意思了，但真的老闆叫他的 agent 進 GitHub 就可以了。

助理說：但教老闆用 slack 比用 Codex 容易啊。

自從 agent 問世後，總覺得每天都在這樣的迷霧中渡過～