採用代理工程實踐的最大挑戰是適應「寫程式碼現在變得便宜」這一事實所帶來的後果。

過去，程式碼一直是昂貴的。撰寫數百行乾淨且經過測試的程式碼，對大多數軟體開發者來說，通常需要一整天甚至更久。我們許多工程習慣，無論是宏觀還是微觀層面，都是圍繞這個核心限制建立的。

在宏觀層面，我們花費大量時間設計、估算和規劃專案，以確保昂貴的編碼時間能被盡可能有效利用。產品功能的點子會根據它們能帶來多少價值來評估——一個功能必須多次賺回其開發成本，才值得投入！

在微觀層面，我們每天做出數百個基於可用時間和預期取捨的決策。是否應該重構那個函式，使其更優雅，即使會多花一小時？是否要撰寫文件？是否值得為這個邊緣案例添加測試？我能否合理化為此建立一個除錯介面？

編碼代理大幅降低了將程式碼輸入電腦的成本，這擾亂了我們許多既有的個人和組織直覺，讓我們難以判斷哪些取捨仍然合理。

平行運行多個代理的能力更讓評估變得困難，因為一位人類工程師現在可以同時在多個地方實作、重構、測試和撰寫文件。

交付新程式碼的成本幾乎降至免費，但交付優質程式碼仍然顯著昂貴。

編碼代理工具能協助完成大部分工作，但開發者仍需承擔重大責任，確保產出的程式碼在當前專案所需的良好標準範圍內是優質的。

挑戰在於培養新的個人與組織習慣，以回應代理工程所帶來的可能性與機會。

這些最佳實踐仍在業界摸索中，我自己也還在學習。

目前我認為最好的做法是自我質疑：每當直覺告訴你「別做了，不值得花時間」時，仍然可以發出提示，讓代理在非同步的環境中執行，最壞的情況也只是十幾分鐘後發現不值得花費代幣而已。

本文摘自《代理工程模式》指南。