一周前，我寫了一篇關於生成式與代理式 AI 如何可能加劇我所稱的「認知債務」的文章：即系統不斷演變的結構，與團隊對該系統如何運作、為何如此運作以及如何隨時間改變的共享理解之間，日益擴大的差距。
這篇文章在不同社群引發了深入的討論。與其逐一回覆，我希望在此綜合我聽到的觀點，並連結到我閱讀到的其他反思。隨著對話的演進，我可能會持續更新本文。
包括 Simon Willison 和 Martin Fowler 文章在 Hacker News 討論區上的其他人等幾位實務工作者，都描述了親身經歷認知債務的感受。他們談到在自己的專案中迷失方向，發現要自信地添加新功能變得更加困難。他們可以移動得更快，但卻失去了將決策與意圖、意圖與程式碼連結起來的深層意義建構。
這不僅僅是關於程式碼品質。這是關於個別開發者和產品團隊是否能夠維持對系統正在做什麼以及為什麼這樣做的連貫心智模型。
在這些討論中，有一個主題始終如一：速度可能超越理解。
技術債務存在於程式碼中。認知債務存在於人心中。
當共享理解遭到侵蝕時，痛苦會體現在：
軟體可能「正在運作」，但系統的理論變得更難以存取和追蹤。成本不僅是結構性的。它是體驗性的。
Siddhant Khare 寫了關於 AI 疲勞的文章。Steve Yegge 反思了 AI 加速開發所帶來的倦怠。Annie Vella 則優美地描述了當系統變得更難以推理時，不確定性所帶來的心理和認知體驗。這些觀點都強化了這不僅僅是一個工程紀律問題，而是影響開發者感受和運作方式的問題。
Martin Fowler 指出，與技術債務一樣，認知債務最終必須被償還。我同意這一點。
但重建失去的知識需要恢復系統的分布式理論。這包括擷取意圖、決策背後的理由、關鍵限制以及架構如何支援變更。
該理論不僅僅儲存在程式碼中。它分散在：
* 程式碼本身
* 程式碼中的註解
* 版本控制系統的提交訊息
* 設計文件
* 架構圖
* 會議記錄
* 即時通訊記錄
* 開發者之間的口頭交流
* 開發者的心智模型
償還意味著維護所有這些，而不僅僅是重構程式碼或更新架構文件。
在快速推進的壓力下，無論是在努力學習的初創公司，還是在推動 AI 採用的大型組織中，這種償還都可能顯得昂貴且容易被延遲。
包括 Michael Würsch 在內的幾位評論者認為，認知債務反映了良好工程紀律的失敗。清晰的規格、嚴謹的審查、廣泛的測試和明確的架構文件應該可以防止知識的流失。
原則上，我同意。但在實務上，誘因正在轉變。AI 降低了產生結構的成本。結構比共享理解能夠穩定下來的速度更容易演變。即使是紀律嚴明的團隊也必須有意識地控制或塑造他們的實踐，以使理解與變革保持一致。
規格和文件不足以應付，如果它們不是團隊積極參與的活態產物。
令人鼓舞的是，許多讀者分享了他們如何減輕認知債務。
有些人還描述了使用 AI 來降低這些實踐的成本，甚至支援認知追蹤、依賴管理和解釋。
謹慎使用時，AI 可能有助於使認知工作更加可見，而不是使其模糊。
高績效團隊一直以來都有意圖地管理技術債務。隨著 AI 被初創公司和大型公司採用，問題變成了團隊將如何管理認知債務。
他們將如何塑造社會技術實踐和工具來外化意圖並維持共享理解？他們將如何利用生成式和代理式 AI 不僅來加速程式碼生產，而且來維持他們的集體理論？
隨著 AI 減少技術摩擦，共享理解可能成為績效的瓶頸。
我將繼續關注事態的發展。如果您看到在實際團隊中有效的緩解實踐，我很樂意向您學習。