我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。
我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。
前面幾篇討論了 AI Coding 如何改變軟體開發的成本與 Lead Time，以及當企業軟體可以透過 API、MCP 或 AI Agent 調度既有功能時，部分客製化需求可能直接由使用者自行完成。
但如果企業內部的員工，已經能夠透過 Claude Code、Codex、Vercel 等工具，自行開發需要的系統，那麼企業是否還需要外部 FDE？
從過去接觸中小企業的經驗來看，我認為這是一個值得認真看待的變化。許多企業雖然沒有專職軟體工程師，但內部其實有不少非常熟悉營運流程的人。他們知道每天需要處理哪些資料、哪些工作最花時間，以及現有系統有哪些不方便的地方。過去這些人即使有改善流程的想法，也可能因為缺乏程式開發能力，只能繼續使用 Excel、Google Sheets，或等待公司安排工程師協助，AI Coding 扭轉了這個情況。
然而，我在企業現場也經常遇到另一種情況：當一位員工開始具備軟體開發能力，公司可能就會期待他協助其他部門，甚至考慮讓他轉任 IT。這個人的工作內容，也會因此發生相當大的改變。下一個必須思考的問題是，企業培養出會使用 AI Coding 的員工，和建立一個能夠服務整間公司的軟體團隊，中間還有哪些需要跨越的問題。
上一篇討論 FDE 如何透過縮短需求與開發之間的距離，降低整體 Lead Time。如果需求提出者本身就具備開發能力，這個距離還有機會進一步縮短。
例如一位業務人員，每天都需要從不同 Excel 檔案整理產品規格與價格，再根據客戶詢問的內容製作報價單。他自己最清楚哪些資料可以直接使用、哪些規格需要額外確認，以及哪些情況應該交給主管或採購處理。
如果由外部工程師開發系統，通常需要先進行需求訪談，再將流程整理成規格，接著安排開發、測試與驗收。即使工程師技術能力很好，也需要花時間理解這位業務人員原本就很熟悉的工作。但如果業務人員可以直接使用 AI Coding，他就有機會自己建立報價工具，並且立即使用實際資料測試。
即使 AI 第一次產生的程式有 Bug，或是某個流程不符合原本的工作習慣，他通常也能很快發現問題。因為他每天都在執行相同的工作，對於資料應該如何呈現、計算結果是否合理，以及什麼情況需要額外處理，已經累積了相當多的經驗。這類錯誤不一定需要寫成正式的 Bug Report，再等待工程師理解，使用者可以直接向 AI 描述問題、要求調整，接著重新執行並確認結果。
當需求提出者、開發者與使用者是同一個人，需求理解、實作、測試與修正之間的等待時間，就有機會大幅下降。當然，熟悉流程不代表能夠發現所有軟體問題。例如資安漏洞、資料競爭、權限錯誤或極端情況，未必能夠透過日常使用經驗察覺。但對於範圍明確、主要由自己使用的工具，這種開發方式確實具有很大的效率優勢。
我認為這是 AI Coding 帶來非常實際的改變，也沒有理由要求所有企業都必須繼續委託外部工程師，才能完成這類系統。
從過去參與 ERP、CRM 及製造業系統整合的經驗來看，我認為企業有相當多適合透過 AI Coding 改善的工作，尤其是既有 ERP 的外圍系統。
許多企業已經投入不少預算導入 ERP，涵蓋採購、庫存、銷售、生產及財務等流程。不過，ERP 的標準操作介面，未必符合各部門最有效率的工作方式。例如業務人員可能需要處理大量非標準規格的詢價，必須先整理客戶資料、查詢價格，再建立報價。生產管理人員則可能需要依照工單進度、機台狀態與交期，使用另一種方式檢視工作。這些需求不一定需要修改 ERP 本身。
如果 ERP 已經提供適當的 API，或其他可以安全交換資料的方式，就有機會在外部建立更符合使用者需求的系統，完成必要的資料整理與操作，再將結果同步回 ERP。
例如業務人員可以自行建立一套報價介面，讓使用者以更符合實際工作習慣的方式輸入規格、查詢價格，最後再透過 API 將確認後的報價資料寫回 ERP。同樣的方式也可能應用在訂單管理、工單追蹤，或其他需要改善操作效率的情境。
這類外圍系統的好處，是企業可以保留既有 ERP 作為核心資料與交易系統，同時讓各部門根據自己的工作需求，建立更方便的操作工具。而且這些需求通常相當具體，內部使用者也有能力快速判斷系統是否符合工作習慣，因此很適合透過 AI Coding 進行小範圍開發與驗證。
不過，這個做法有幾個必要條件。ERP 必須具備適合的資料交換機制，外圍系統也需要遵守原本的資料驗證、權限及交易規則。如果需要處理複雜的庫存異動、財務交易或資料同步，就可能涉及更多系統架構問題。
因此，我比較傾向將這類應用視為企業建立內部軟體能力的起點。先從使用者熟悉、影響範圍容易控制的流程開始，讓 AI Coding 發揮降低開發與溝通成本的優勢。
還有個人才面的議題，我還沒看過有人討論。有些原本不具備軟體工程背景的員工，因為開始接觸 AI Coding，發現自己也能建立系統，進而對軟體工程師的工作產生興趣。其中一個原因，是他們認為工程師具有比較好的薪資待遇與職涯發展機會。過去因為沒有資訊相關背景，可能不容易轉換職涯，但現在透過 AI Coding，他們開始認為自己也有機會往資訊專業發展。
這樣的期待可以理解，因為 AI Coding 確實降低了開發軟體的門檻，也讓更多人有機會接觸原本需要程式能力才能完成的工作。但有一個容易被忽略的差異：當這位員工開發自己使用的工具時，他本身就是最熟悉需求的人；一旦轉任 IT，或開始負責其他部門的系統，他就需要理解其他人的問題。
例如原本在業務部門工作的員工，可能非常了解報價流程，也能利用 AI Coding 建立一套好用的報價工具。但如果公司因此希望他協助採購部門改善請購流程，他就需要重新理解採購人員的工作、不同層級的審核權限，以及相關資料如何影響後續流程。如果接著又需要協助生產部門開發工單管理系統，就必須再理解製程、機台、工單狀態與跨部門的作業方式。這些工作除了開發程式，也包含需求訪談、流程盤點、跨部門協調及確認不同使用者的期待，而且並非每個喜歡開發軟體的人，都喜歡或擅長這些工作。
我在企業現場就經常遇到類似的情況。有些人對技術很有興趣，也願意研究如何透過工具改善自己的工作，但當他需要和其他部門反覆確認需求、解釋技術限制，或處理不同人對系統的期待時，工作內容就未必符合他原本的興趣。
這也讓企業在人才培育上需要思考，員工希望學習 AI Coding，究竟是為了提升原本工作的效率，還是有意願轉向以軟體開發為主要職責的工作？即使兩者都合理，後續需要培養的能力仍然有所不同。
如果企業只是希望各部門使用 AI Coding 改善自己的工作，原本的組織架構可能不需要太大幅度調整。但當公司開始希望某些員工負責其他部門的開發需求，甚至成立自己的 IT 團隊時，就會遇到另一個層次的問題。
許多中小企業長期以營運、生產或業務為核心，內部工作主要按照既有 SOP 運作。即使有專門負責資訊設備或 ERP 維護的人員，也不一定具有管理軟體開發專案的經驗。
假設公司原本有一位業務人員，因為很擅長使用 AI Coding 開發工具，逐漸被其他部門注意到。主管開始希望他協助建立採購系統、整理生產資料，甚至處理跨部門的系統整合。這時候公司需要開始管理需求的優先順序、開發範圍、進度、測試、驗收及維護責任。
例如業務部門希望先完成報價功能，採購部門希望改善請購流程，生產部門又提出工單追蹤需求。當每個部門都認為自己的問題最重要時，就需要有人決定開發優先順序，以及哪些需求值得投入資源。
如果這位內部開發者不擅長跨部門溝通，公司可能還需要有人承擔專案經理的角色，負責需求確認、工作協調與進度管理。但這對部分中小企業而言也是新的能力。過去企業可能擅長管理標準化的營運流程，卻沒有培養需求分析、軟體專案管理或工程團隊的經驗。
而且軟體開發除了完成當前需求，也需要考慮版本管理、系統部署、資料備份、使用者權限及後續維護。當系統開始被更多人使用，或直接影響企業的重要營運資料，這些工作就需要有相應的管理機制。
因此，AI Coding 雖然讓企業更容易培養出具有軟體開發能力的員工，但如果希望將這些能力擴大到整間公司，仍然需要建立需求管理、跨部門協作及軟體工程管理能力。
這些能力不一定要全部由同一位員工承擔，也不代表企業一定需要立即成立完整的 IT 部門。但企業需要重新思考，應該讓哪些人負責開發、哪些人負責需求與專案協調，以及誰需要對正式上線的系統承擔責任。
這個方向其實也可以從大型科技公司的布局看到。
2026 年 10 月 2 日，Anthropic 宣布投入 1 億美元推動 Claude Frontier Academy，目標是在 2027 年底前培養 10,000 名 Frontier Deployed Engineers。這項計畫的參與者包含 Accenture、Bain、Deloitte、McKinsey、Morgan Stanley 等顧問公司及企業組織的人員。受訓者需要透過實際專案，學習如何將 Claude 導入企業工作流程，並在回到原本組織後完成部署。（參考：Anthropic — Claude Frontier Academy）
Palantir 也有類似的觀點。一位自述在 Palantir 擔任 FDE 已有 14 年的員工，曾在官方開發者社群分享，他相當看好企業內部建立自己的 FDE 團隊，因為這些人可以同時具備工程能力、企業營運知識，以及接觸業務決策者的機會。他也特別強調，Forward Deployed Engineering 是一套持續從真實營運問題中學習、改善產品的工作方式，需要整個組織共同參與。（參考：Palantir Developer Community — Who are Palantir FDEs?）
這兩個案例反映出，大型科技公司也開始重視讓企業內部建立 AI 部署與軟體工程能力。不過，Anthropic 的培訓內容同樣包含需求、資安審查、正式部署與交接，並沒有將 FDE 的能力限制在使用 AI 寫程式。這也呼應前面討論的問題：當企業希望讓內部人員負責更完整的軟體交付，仍然需要培養工程技術以外的能力。
當企業開始具備內部 AI Coding 能力時，外部 FDE 可以扮演什麼角色？
我目前比較傾向讓熟悉流程的內部人員持續負責開發，而外部 FDE 則提供軟體工程方法、系統架構與專業技術方面的協助。
首先是建立基本的軟體工程管理機制。例如企業原本只有一位員工自行開發工具，可能直接在電腦上修改程式，測試完成後就更新正式使用的版本。但當系統開始有其他使用者，或需要長期維護時，就需要考慮程式版本管理、資料庫 Migration、自動化測試，以及正式環境與測試環境的區分。
這些機制可以協助企業降低修改系統時的風險，也讓未來有其他人接手時，不需要完全依賴原本的開發者。AI Coding 可以協助建立這些工具與流程，但企業仍然需要知道應該採用哪些管理方式，以及如何讓開發者持續遵守。外部 FDE 可以透過技術顧問、架構審查與教育訓練，協助企業建立必要的工程規範，再由內部人員自行開發與維護。
另一部分則是較複雜的系統架構與 AI 技術問題。
例如當系統需要支援多個部門、不同角色及較複雜的權限控管，就需要考慮資料庫架構、身分驗證及資料存取權限。當訂單量或使用者數量增加，也可能需要處理系統效能、交易一致性及部署架構。
如果企業希望導入 AI Agent 或 RAG，則可能需要評估模型能力、資料處理方式、檢索架構、評測方法，以及如何控制成本與錯誤風險。而且並非所有問題都適合使用 LLM，例如需求預測、異常偵測或部分分類任務，可能更適合統計模型或其他機器學習方法。這些都需要根據實際資料與業務條件進行選擇。
這些工作即使可以透過 AI Coding 協助實作，仍然需要有人對架構與技術選型做出判斷。對於已經能夠自行開發一般應用程式的企業，外部 FDE 如果具備這些能力，就有機會在內部人員遇到較複雜的技術問題時提供協助。
不過，我認為外部 FDE 還需要特別注意另一個容易被忽略的問題：參與客戶的內部開發專案，可能逐漸變成承擔客戶內部團隊的管理責任。
當企業內部人員使用 AI Coding 開發自己的工具時，通常不需要頻繁向其他人回報進度。他們可以直接和 AI 協作，快速測試與修改，直到功能符合自己的需求。
但如果外部 FDE 開始加入專案，負責技術審查或協助解決開發問題，就可能需要知道內部人員目前完成了什麼、遇到哪些問題，以及後續預計如何修改。
這時候就可能出現工作習慣上的差異。內部開發者可能習慣直接和 AI 完成工作，沒有定期更新專案進度、維護技術文件或回報問題的習慣。而外部 FDE 如果需要對專案交付負責，就必須花時間追蹤這些資訊，甚至協助安排工作、確認進度與處理不同部門的需求。原本只是提供系統架構建議，最後卻可能變成需要管理客戶內部的開發者。
這類工作已經相當接近專案經理或工程主管的職責，但外部 FDE 通常沒有企業內部的人事管理權限，無法直接決定人員的工作優先順序、績效考核或職務調整。如果需要承擔交付責任，卻沒有相應的管理權限，專案就可能產生大量難以控制的溝通與協調成本。而且這些問題經常和客戶的人員能力、工作習慣及組織文化有關，很難單純透過技術改善。
因此，我認為技術顧問與團隊管理最好視為不同的服務。如果客戶需要的是建立版本管理、測試、部署與架構規範，外部 FDE 可以提供具體的技術成果，再由客戶自行管理內部人員如何執行。但如果客戶希望外部 FDE 直接負責分配工作、追蹤進度、協調需求，甚至對整個內部開發團隊的交付結果負責，就需要另外確認管理權限、責任範圍及收費方式。
這類服務並非沒有價值，只是具有更高的客製化程度，也包含較多難以預先控制的因素。對目前以外部技術顧問及 FDE 方式提供服務的我來說，會比較傾向優先承接架構、工程規範及專業技術問題，讓客戶自己負責內部人員與專案管理。
綜合以上，我認為 AI Coding 確實讓企業有機會用更低的成本，培養出能夠自行開發系統的員工。尤其當使用者本身就熟悉流程，能夠直接利用 AI Coding 開發、測試與修正工具，原本需要透過外部工程師才能完成的工作，有機會在企業內部更快完成。
但當企業希望將這些能力擴大到其他部門，或是讓工具成為需要長期維護的正式系統，就需要另外建立軟體工程管理、架構設計、專案協調與責任分工等能力。企業未必需要立即成立完整的 IT 部門，也不一定要讓擅長 AI Coding 的員工轉任專職工程師。讓各部門保留熟悉流程的人員，再透過共通的工程規範與技術架構，協助他們自行開發，也可能是一種值得考慮的方式。
對外部 FDE 而言，我目前比較傾向提供軟體工程管理機制、技術架構與 AI 相關專業能力，協助企業建立可以持續自行開發的環境。至於直接承擔客戶內部團隊的管理責任，則需要另外評估相應的管理權限、工作範圍與商業條件。
回到這個系列最初的問題，當客戶已經有能力自行開發愈來愈多系統，外部 FDE 能夠收費的工作可能也會改變。原本來自一般應用程式開發的需求可能減少，但軟體架構、工程治理、AI 技術選型及跨系統整合，則可能形成新的服務機會。
下一個我認為值得探討的問題是，如果企業內部可以自行完成愈來愈多軟體開發工作，而外部 FDE 又希望避免承擔大量客製化的團隊管理責任，那麼每次專案累積的技術架構、工程規範與解決方案，應該如何轉換成可以重複使用的能力，讓 FDE 形成可以長期經營的服務模式？
有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！
iThome鐵人賽
看影片追技術