過去幾個月，Rahul Garg 在此發表了一系列文章，探討如何降低 AI 輔助程式設計的摩擦。為了讓這些想法更容易付諸實踐，他現在已經建置了一個開源框架來實踐這些模式。

AI 程式碼助理會直接跳到程式碼，默默做出設計決策，在對話中忘記限制條件，並產生沒有人根據真實工程標準進行審查的輸出。Lattice 透過三層可組合技能——原子、分子、精煉器——來解決這個問題，這些技能嵌入了經過實戰考驗的工程紀律（Clean Architecture、DDD、設計優先方法、安全編碼等），以及一個動態情境層（.lattice/ 資料夾），用於累積專案的標準、決策和審查見解。該系統會隨著使用而變得更聰明——經過幾個功能週期後，原子不再套用通用規則，而是套用你的規則，並根據你的歷史記錄進行調整。

它可以作為 Claude Code 外掛程式安裝，或下載供任何 AI 工具使用。

 ❄                ❄                ❄                ❄                ❄

這裡也值得一提的是，我的同事 Wei Zhang 和 Jessie Jie Xia 撰寫的關於結構化提示驅動開發 (SPDD)的文章，已經引起大量流量和不少問題。因此，他們在文章中新增了Q&A 區段，回答了十幾個問題。

 ❄                ❄                ❄                ❄                ❄

Jessica Kerr（Jessitron）發表了一篇關於建立工具來處理對話記錄的有趣文章。她觀察到其中涉及的雙重回饋迴路。

這裡至少有兩個回饋迴路正在運作。一個是開發迴路，Claude 執行我的要求，然後我檢查這是否真的是我想要的。[…] 另一個是元層級的回饋迴路，當我感受到阻力時進行的「這是否有效？」檢查。挫折、乏味、惱怒——這些感受對我來說是一個訊號，告訴我也許這項工作可以變得更容易。

這裡的雙重迴路不僅在改變我們正在建置的東西，也在改變我們用來建置該東西的工具。

作為使用軟體建置軟體的開發人員，我們有潛力塑造自己的工作環境。隨著 AI 讓軟體變更變得超快，改變我們的程式以使除錯更容易，會立即帶來回報。而且，這很有趣！

確實如此，這也讓我想到，代理正在讓我們（重新）發現軟體開發中那些偉大且失落的樂趣之一——將我的開發環境塑造成完全符合問題和個人品味的樣子。不久前，我曾以內部可重編程性的名稱撰寫過這方面的內容。這是 Smalltalk 和 Lisp 社群的核心特色，但隨著我們獲得複雜且精緻的 IDE，這個特色大多已消失（儘管 Unix 命令列提供了一絲其吸引力的提示）。

 ❄                ❄                ❄                ❄                ❄

Ashley MacIsaac 是一位來自 Cape Breton 的音樂家，他演奏受民謠影響的音樂（我的收藏中有幾張他的專輯）。Google 產生了一個 AI 概覽，聲稱他曾被判犯下包括性侵在內的罪行，並被列入全國性犯罪者登記冊。這些內容完全是假的，將他與另一位同名男子混淆了。MacIsaac 正在控告 Google 誹謗：

「這不是搜尋引擎只是掃描內容並提供別人的故事 […] 這是由他們發佈的。對我來說，這就是誹謗。沒有防護機制來防止 Google AI 發佈該內容。」

MacIsaac 的重點是，Google 必須對其控制的工具所發佈的內容負責。MacIsaac 在這件事上受到了真正的傷害，不僅是聲譽受損，他的演唱會也被取消，這些指控也影響了他的表演。

「我感受到了一種由媒體公司發佈的東西所帶來的實質恐懼，」他在接受加拿大新聞社採訪時表示。「因為被貼上這樣的標籤，我害怕上台表演。而且我不知道這種情況會跟隨我多久。」

科技公司太常試圖逃避其行為的後果。確實存在大規模監控發佈內容的困難，但這是他們應該面對的責任。

 ❄                ❄                ❄                ❄                ❄

Stephen O’Grady（RedMonk）認真探討了大型科技公司在 AI 建置上的支出規模。涉及的金額不僅在絕對值上令人驚嘆（超過 1000 億美元），與相關公司的營收相比也相當可觀。像 Amazon、Alphabet 和 Microsoft 這樣的公司的支出超過其營收的 50%（而非利潤）。Meta 和 Oracle 達到或超過了營收的 75%。

這種程度的投資在十年前是不可想像的。今天，圖表顯示這已成為基本門檻。

有一個值得注意的例外：Apple。他們顯然在「Think Different」，從圖表來看，他們的支出似乎接近營收的 10%。

 ❄                ❄                ❄                ❄                ❄

我交談過的大多數人，在使用代理式程式設計時，都是使用雲端模型：Claude、Codex 等。大家都同意這些是最強大的模型，是引發11 月轉折點的模型。但我們是否需要使用最強大的模型，特別是當我們必須將資料傳送給它們，並為此支付高昂費用時？Willem van den Ende考慮了一種替代方案，即本地模型已經「夠好」。

假設
- 我們都在找出解決方案。
- 工具（程式碼代理 +「技能」+ 擴充功能）的品質可能至少與模型一樣重要
- 執行開放模型和開放式程式碼代理 + 自訂擴充功能需要時間，但會在理解和穩定的基礎上獲得回報，工程努力會在此累積
- 開放的本地模型（對我而言）已經跨越了「夠好」的門檻，可與程式碼代理一起用於日常工作。

這篇文章詳細描述了他進行本地模型工作的設定。其中包括使用 Nono 進行沙箱隔離，這即使在使用雲端模型時也值得考慮——如此強大的工具需要零信任架構。

 ❄                ❄                ❄                ❄                ❄

如果你還沒注意到，最後兩段片段彼此呼應。Apple 沒有參與雲端 AI 模型的遊戲，他們節省了大量資金，而如果本地模型最終成為未來趨勢，他們看起來將會相當明智。Van den Ende 的文章讓我聯想到 Nate B Jones 的一個播客，該播客認為Apple 正在重演 50 年前的策略。所有那些年前，使用電腦的人都要購買大型主機的時間，而 Apple II 將功能較弱的運算能力放到了家庭和小型辦公室中。由此產生了試算表、桌上出版，以及現代家用電腦——這些都是使用大型主機無法實現的。

他認為 John Ternus 擔任 CEO 的崛起，不僅僅是換成一位知名的內部接班人——而是賭注 AI 的未來是家用、辦公室和口袋中的精密硬體。如果開放原始碼模型已經「夠好」，那麼為什麼要把包含敏感資料的 token 傳送給 AI 巨頭？

 ❄                ❄                ❄                ❄                ❄

談到 50 年前，1974 年 Fred Brooks 以這幾段文字開啟了我們這個專業領域中最具影響力的書籍之一：

史前時代沒有哪個場景比巨獸在焦油坑中掙扎更生動。在心靈的眼睛裡，你會看到恐龍、猛獁象和劍齒虎在焦油的束縛下掙扎。掙扎得越激烈，焦油就越纏繞，沒有哪隻野獸如此強壯或如此靈巧，但最終都會沉沒。

大型系統程式設計在過去十年一直是這樣的焦油坑，許多偉大而強大的野獸在其中劇烈掙扎。大多數都產生了可運行的系統——很少達到目標、時程和預算。無論大小、龐大或纖細，一個又一個團隊都陷入了焦油。沒有任何單一因素造成困難——任何特定的爪子都可以被拉開。但同時發生且相互作用的因素累積，導致動作越來越緩慢。每個人都對問題的黏性感到驚訝，很難辨別其本質。但如果我們要解決它，我們必須試著理解它。

Kent Beck 在他最近的文章標題中喚起了這種意象，即精靈焦油坑。在解釋為什麼熟練的軟體開發是關於同時建置功能和未來之後，他觀察到這些 AI 工具在產生具有良好未來所需的內部品質的軟體方面做得不好。

我觀察到的情況是——精靈自然生活在「摸索」的左下方。「合理的可否認性」任務導向讓精靈即使在程式碼根本無法運作的情況下也能宣稱成功。複雜性堆疊在複雜性之上，直到連精靈也無法再假裝有進展。

在代理式程式設計的時代，內部品質是否重要、或重要到什麼程度，仍然是一個開放的問題。一種觀點是，正如 Laura Tacho 所說的，「開發者體驗和代理體驗的文氏圖是一個圓圈」。組織良好的元素，搭配良好的命名，有助於精靈理解程式碼，因此如果我們要繼續超越小型的一次性系統，這些元素就很重要。另一種觀點是，這種內部品質並不重要，LLM 的超級大腦將能理解最大的義大利麵碗。也許現在不行，但經過幾次轉折點之後就會。

這是根本問題。精靈能否避開焦油坑，還是會在焦油的黏性束縛下徒勞掙扎？