企業會不會經歷從 object-oriented programming 到 pipeline-oriented programming 的典範轉移？

企業會不會經歷類似從 object-oriented programming 到 pipeline-oriented programming 的典範轉移？物件導向本來就是從現實公司組織建模而來的軟體架構，將軟體拆分成一個個負責某些事的「物件」，然後協同這些物件去完成不同的業務。在現實當中，公司組織的這種型態是因為公司是由人類組成的組織，而人類是運算、能力範圍、記憶容量有限的 agent。所以最有效的組織法是想辦法把業務拆分成適合個別人類去執行的工作單位，並建立起人類之間的溝通協定，工作默契之類的。

但是這個組織型態在軟體工程來說不一定是最佳解。應該說對於開發者來說還是不錯，因為開發者是人類，而人類對於現實中人類的組織會比較熟，所以物件導向的概念對人類開發者來說是很好懂的。可是軟體運作跟人類很不一樣，因為軟體運作中一台電腦一次大概只會有幾個 thread 在跑。換成人類組織的概念的話，就是整間公司總共只有四到八個人，而物件導向架構就等於是設計出數十、上千個不同的職位與座位，然後要這幾個人去不停切換座位，做不同職位的事情。切換職位對電腦來說並不是太大的問題，因為電腦的 thread 並沒有人類的限制，所以物件導向程式的效能是沒有問題的。問題反而是在開發端：這種組織模式的 overhead 會隨著組織規模一起變大。原本一個物件可能只要處理一兩件事，但當程式長太大的時候，一個物件可能變成要處理很多件事，有的時候甚至你會不知道它到底在做什麼事，但拿掉它之後整個程式就會當掉。然後你得要不停的想，「我到底要怎麼分責任」「我到底要怎麼讓不同的物件一起工作」之類的。

比如說一個產品從研發到上市，以物件導向的概念來說，就是要設幾個不同的部門：研發部、生產部、發行部、行銷部等等，然後去指定每個部門的職責，以及他們之間要如何溝通協作。

Pipeline-oriented programming 是捨棄了「什麼都要用物件來解決」的這個傾向，改成盡可能用「流程」來解決問題。以人類組織來想像的話，就是認知到公司裡的那幾個人（thread）其實能力很強，所以與其設一堆不同的職位，不如直接把工作流程從頭到尾寫清楚丟給這幾個人去執行。

拿剛剛的產品研發上市流程來說，就是我直接做一份流程書，定義說這個產品應該要經過研發、生產、發行、行銷等步驟，然後把這個流程書丟給一個人來執行。簡單來說就是一條龍做到好。有點像是一個超強 PM。人類很難做到，但對電腦來說，反正就算設一堆職位，最終還是一個人去做，那不如把職位都取消掉，只留下「要做什麼事」就好，也沒什麼損失。

而 AI agent 的某些性質跟電腦 thread 是比較接近的，也就是能力範疇非常廣，記憶操作很靈活，更可以用 sub-agent 等快速切換脈絡。所以說，在一個 AI 系統裡面，其實並不需要模擬人類組織，去設置不同的部門、設置不同的「職位」，徒增管理成本。反而是可以借鑑 pipeline-oriented programming，把「流程」當成基本單位，不只降低管理成本，AI agent 甚至跑起來也會更順，因為降低了很多 overhead。

我原本也是為敘事鋸設置了十幾個不同領域的 AI agent，想說可以減輕經營公司的壓力，但後來發現我還是花了大量的時間在調整各個 agent 的知識與行為等等，又把自己變成一個管理者，蠻痛苦的。所以我後來把這些 agent 都封存掉，連 Claude Project 也盡量不用（留到只剩下一個），直接用普通的 Claude Chat 與 Cowork，結果發現現在的 AI model 根本就不需要太多調整，就可以完成大多數任務了。而我這樣改變用法後，也發現需要管理的文件大幅減少。我感覺自己終於沒有在「管理」，而是在完成事情。

如果拿一般人類組織來比喻的話，我覺得 AI agent 比較像是外聘的顧問，可以幫你一條龍把一個任務辦到好，然後你不需要管理他，你只需要清楚的交辦任務、給他存取公司資源的權限，然後分階段進行驗收與回饋就可以了。

當然，外包化本來就是企業界的現在進行式，只是現在有了 AI 之後，外包的範疇可能會越來越長，越來越一條龍化，也就是垂直整合。畢竟甲方一直以來要看的本來就是成果，中間發生什麼事說真的沒什麼人 care。只是未來也許除了外包之外，連組織內部也會開始一條龍化。

說不定未來求職網站的職位描述就不會是「職位」的描述，而是流程或者產線描述了。又或者流程的 owner 直接變成 AI agent，然後人類職位變成每個階段的監督驗收者。