程式碼是一種負債（而不是資產）。科技老闆們不明白這一點。他們認為AI很棒，因為它產生的程式碼是程式設計師的10,000倍，但這只是意味著它產生了10,000倍的負債。 1/

如果您想閱讀或分享此帖子的文章格式版本，請在我的無監控、無廣告、無跟蹤器的博客上提供連結： 2/

AI 是我們在高科技社會的牆壁中填充的石棉： 程式碼是一種負擔。程式碼的 *能力* 是資產。 3/

科技商店的目標是擁有能夠產生比維持該代碼運行所需成本更多收入的代碼。 4/

長期以來，企業一直抱有一種錯誤的信念，認為隨著時間的推移，程式碼的運行成本會降低：在初始的調整期內，程式碼中的錯誤被發現並解決後，程式碼就不再需要進行有意義的維護。 5/

畢竟，程式碼是一台沒有活動部件的機器——它不會磨損；甚至不會退化。 這是保羅·梅森2015年書籍《後資本主義》的論點，這本書的陳舊程度令人驚訝（雖然，或許，沒有梅森自己政治信譽的陳舊程度那麼糟）。 6/

程式碼並不是一個無限可重複的機器，不需要任何勞動。相反，它是一個脆弱的機器，需要越來越多的英勇措施來保持良好的運行狀態，最終會 "磨損"（在需要全面重構的意義上）。 7/

要理解為什麼代碼是一種負擔，你必須了解「寫代碼」和「軟體工程」之間的區別。 「寫代碼」是一項非常有用、有趣且引人入勝的消遣。 8/

這涉及將複雜的任務分解為明確的步驟，描述得如此精確，以至於計算機可以可靠地執行它們，通過找到巧妙的方法來最小化代碼對計算機資源（如 RAM 和處理器週期）的需求來優化性能。 9/

同時，「軟體工程」是一個包含「編寫程式碼」的學科，但重點在於程式碼所屬的*系統*的長期運作。 10/

軟體工程關注的是生成系統接收數據的上游過程。它關注的是系統向外發送處理後信息的下游過程。 11/

它關注的是從相同的上游過程接收數據和/或向系統正在發送的相同下游過程發送數據的相鄰系統。 12/

"寫程式"是關於編寫*運行良好的*程式碼。"軟體工程"則是關於編寫*失敗良好的*程式碼。這是關於編寫可讀的程式碼 - 其功能可以被可能被要求維護它的第三方理解。 13/

這些第三方可能會被要求調整系統下游、上游或相鄰的流程，以防止系統崩潰。 14/

這就是問題所在：任何非平凡的代碼都必須與外部世界互動，而外部世界並不是靜態的，它是*動態的*。外部世界不斷打破軟體作者所做的假設*隨時*，每當這樣做時，軟體都需要被修正。 16/

還記得Y2K嗎？那是一個完美運行的代碼，在完美運行的硬體上，會停止運作的日子——不是因為代碼改變了，而是因為*時間推進了*。 17/

我們距離 Y2038 問題還有 12 年，屆時所有 32 位元的 Unix 系統將全部無法運作，因為它們也將耗盡可計算的秒數。 18/

「世界」的存在是一個無法避免的因素，會使軟體耗損，並需要重建，這通常需要巨大的費用。程式碼運行的時間越長，遇到「世界」的可能性就越大。 20/

取得設備用來報告其物理位置的代碼。最初，這是用於計費等事務——確定您使用的是哪個運營商或提供商的網絡，以及您是否在漫遊。 21/

然後，我們的移動設備使用這段代碼來幫助確定您的位置，以便在導航應用中提供逐步指引。然後，這段代碼再次被重新利用來幫助我們找到丟失的設備。 22/

這成為定位*被盜*設備的一種方式，這個用例與尋找遺失設備有著明顯的不同。在定位遺失設備時，你不必面對惡意行為者已經禁用「尋找我的遺失設備」功能的可能性。 23/

這些額外的使用案例 - 上游、下游和相鄰 - 揭露了原始代碼中的錯誤，這些錯誤在早期的應用中從未顯現過。 24/

例如，所有位置服務必須在（非常常見的）不確定自己位置的情況下，具有某種默認行為。 25/

也許他們有一個通用的修正方法——例如，他們知道自己連接的是哪個手機基站，或者他們知道自己上次獲得準確位置修正時的位置——或者他們可能完全迷路了。 26/

事實上，在許多情況下，位置應用程式會在所有可能的位置周圍畫一個圓，然後將其位置設置在該圓的中心。 27/

如果圓圈的直徑只有幾英尺，或者應用程式能迅速用更精確的位置取代這個近似值，那就沒問題。但如果位置跨越數英里，而位置修正*從未*改善呢？ 28/

如果任何沒有定義位置的 IP 地址的地點被給定為 *美國大陸的中心*，而任何不知道它在哪裡的應用程式報告它位於堪薩斯的一個房子裡，會怎樣呢？ 29/

在我位於伯班克的城鎮，谷歌的定位分享服務曾告訴我們，我們當時11歲的女兒（我們無法聯繫到她的手機）距離我們12英里，位於洛杉磯縣一個未合併的地區的高速公路匝道上。 32/

（她在附近的公園，但超出了範圍，應用程式估算她的位置為最後固定的區域中心。） （這幾個小時過得很艱難。） 33/

底層代碼 - 使用某些曾經無害的預設來模糊未知位置的代碼 - 需要*不斷*更新，因為與之相關的上游、下游和相鄰過程也在*不斷*變化。 34/

那段代碼放在那裡的時間越長，它原本的行為就越顯得過時，而其上層的修補程式則越來越繁瑣、雜亂和難以理解。 35/

程式碼不是資產，而是負債。電腦系統運行的時間越長，它所代表的技術負債就越多。系統越重要，關閉並完全重做的難度就越大。 36/

相反地，新的程式碼層被覆蓋在其上，無論程式碼層相遇的地方，都會出現裂縫，這些系統的行為並不完全一致。 37/

更糟的是：當兩家公司合併時，它們的 IT 系統被強行合併，這樣就會出現*相鄰*的技術負債來源，以及上游和下游的裂縫： 38/

這就是為什麼大型公司如此容易受到勒索病毒攻擊的原因——它們充滿了不兼容的系統，這些系統被迫以各種形式的數位黏土、繩子和包裝線的假象兼容。 39/

它們並不是防水的，且無法做到防水。即使不被駭客攻擊，它們有時也會倒下，無法再站起來。 40/

還記得2022年聖誕週時，西南航空的電腦崩潰，讓數百萬旅客滯留的情況嗎？ 41/

航空公司特別糟糕，因為他們早期就實現了電腦化，無法關閉舊電腦以用新電腦取而代之。這就是為什麼他們的應用程式如此糟糕。 42/

這就是為什麼航空公司解雇了他們的客服人員，並要求乘客使用應用程式來處理*所有事情*，即使這些應用程式根本無法運作。這些應用程式永遠不會運作。 43/

英國航空的應用程式顯示「發生未知錯誤」的原因並不僅僅是因為他們解雇了所有IT人員並將工作外包給海外的低標投標者。 44/

這是沒錯的，但也因為BA的第一台電腦是用電機機械閥運行的，而自那以後的一切都必須與一個由艾倫·圖靈的門徒用他自己的前牙咬出的一整根原木的系統向後兼容。 45/

程式碼是一種負擔，而不是資產（BA的新應用程式已經落後於計劃多年）。 程式碼是一種負擔。讓邁克爾·布隆伯格成為億萬富翁的彭博終端伺服器運行在RISC晶片上。 46/

這意味著它被鎖定在使用越來越少的專業硬體和數據中心供應商，支付專業程序員的費用，並建立脆弱的代碼鏈，以將這些 RISC 系統連接到世界上不那麼奇特的對應系統。代碼不是資產。 47/

AI 可以寫代碼，但 AI 不能做軟體工程。軟體工程完全是關於思考 *上下文* - 這個系統之前會發生什麼？之後會發生什麼？會與它並存的有什麼？世界將如何改變？ 48/

軟體工程需要非常寬廣的「上下文視窗」，而這是AI所不具備的，也無法擁有的。AI的上下文視窗狹窄且淺薄。對AI的上下文視窗進行線性擴展需要*幾何*級別的計算需求： 49/

編寫有效的代碼，而不考慮它將如何失敗，是一個災難的配方。這是一種在大規模上創造技術負債的方式。這就像把石棉填入我們技術社會的牆壁中。 50/

老闆們*不知道*程式碼是一種負債，而不是資產。這就是為什麼他們不會停止談論那些產出比任何人類程式設計師多出10,000倍程式碼的聊天機器人。 51/

他們認為他們找到了能以人類程式設計師的 10,000 倍速度生產 *資產* 的機器。實際上，他們找到的是一台以任何人類程式設計師的 10,000 倍速度生產 *負債* 的機器。 52/

可維護性不僅僅是經驗教會你陷阱在哪裡的問題。 53/

這也需要培養 "Fingerspitzengefühl" - 這種 "指尖感覺" 讓你能合理地猜測出從未見過的陷阱可能出現的地方。 54/

這是一種過程知識。這是不可避免的。即使是你可以用作訓練數據的最大代碼庫中也不存在潛在的知識： *男孩*，科技老闆們真是不明白這一點。 55/

以微軟為例。他們目前的重大賭注是「代理 AI」。他們想在你的電腦上安裝間諜軟體，捕捉每一次按鍵、每一次通訊、你看到的每一個螢幕，並將其發送到微軟的雲端，讓一群聊天機器人可以訪問這些資料。 56/

他們聲稱你可以告訴你的電腦："幫我訂一張去卡迪夫的火車票，並找到去年科里提到的那家酒店，幫我在那裡訂一個房間"，然後它就會這樣做。 這是一個極其不可行的想法。 57/

沒有任何聊天機器人能夠遠端做到這些事情，這是微軟明確指出的。微軟提議將這些任務分解到數十個聊天機器人中，每個聊天機器人希望達到95%的可靠性。 58/

這本身就是一個完全不切實際的聊天機器人標準，但考慮這一點：概率是*相乘*的。一個包含兩個以95%可靠性運行的過程的系統，其淨可靠性為90.25%（0.95 * 0.95）。 59/

將一項任務分配給幾十個95%準確的機器人，這項任務正確完成的機會幾乎為*零*。 60/

與此同時，一位微軟高管在去年十二月因在Linkedin上發布消息，宣布他打算讓AI重寫微軟的*所有*代碼而陷入麻煩。 63/

重構微軟的代碼庫是非常有意義的。微軟——就像英國航空和其他傳統公司一樣——擁有大量非常舊的代碼，這些代碼代表了不可持續的技術負債。 64/

你們中的一些人*是*軟體工程師，發現聊天機器人在為你們編寫代碼方面非常有用。這是一個常見的AI悖論：為什麼有些使用AI的人覺得它非常有幫助，而另一些人卻厭惡它？ 66/

不喜歡AI的人是「不擅長AI」嗎？AI的粉絲是懶惰的，並且不在乎他們工作的質量嗎？ 67/

無疑這兩者都有發生，但即使你教會每個人成為 AI 專家，並將所有不以工作為榮的人從樣本中剔除，這個悖論仍然會存在。 68/

AI 悖論的真正解決方案在於自動化理論，以及「半人馬」和「反向半人馬」的概念： 69/

在自動化理論中，"半人馬"是指一個受到機器協助的人。"反向半人馬"則是指被徵召去*協助機器*的人。 70/

假設你是一名軟體工程師，使用 AI 來編寫例行程式碼，而你有時間和經驗來驗證這些程式碼，運用你的直覺和流程知識來確保它適合其目的。 71/

很容易理解為什麼你會覺得使用 AI（在你選擇的方式、在你選擇的時間、以你選擇的速度）是有用的。 但假設你是一名軟體工程師，已被要求以你之前的速度的 10 倍、100 倍或 10,000 倍的速度產出程式碼。 72/

說唯一的方法是透過 AI，而沒有任何人類的方式可以審查那段代碼並確保它在首次接觸世界時不會崩潰，你會討厭它： 73/

(如果你被變成了AI的責任承擔者，對AI的錯誤負有個人責任，你會更討厭它。) 軟體工程師發現AI生成的代碼在某些情況下非常有幫助：當這段代碼是*孤立的*時。 74/

如果你只是在做一個單一的專案——比如說，將一批檔案轉換成另一種格式，只做一次——你不必擔心下游、上游或相鄰的過程。這些過程並不存在。 75/

你正在編寫代碼來做某件事，這個過程不需要與其他系統互動。很多編程都是這種實用項目。這是乏味的、沒有感謝的，並且非常適合自動化。 76/

許多個人專案都屬於這個範疇，當然，根據定義，個人專案就是一個半人馬專案。沒有人強迫你在個人專案中使用 AI - 何時以及如何使用任何工具始終是你的選擇。 77/

但事實上，軟體工程師有時可以透過 AI 改善他們的工作，並不否定程式碼是一種負債，而不是資產，且 AI 生成的程式碼代表著大規模的負債生產。 78/

在技術性失業的故事中，有一個觀點是新技術在使舊工作過時的同時也會創造新工作：每一位因汽車而失業的鐵匠，背後都有一個等待的機械師職位。 79/

自從 AI 泡沫開始膨脹以來，我們聽到了很多版本的說法：AI 將為「提示工程師」創造工作，甚至會創造一些我們無法想像的工作，因為這些工作在 AI 改變世界到無法辨識之前是不存在的。 80/

我不會指望在一個無法想像的奇幻行業中找到工作，因為我們的意識尚未因 AI 的影響而改變到能夠概念化這些新的工作模式。 81/

但如果你*正在*尋找一份AI肯定會創造的工作，數以百萬計的工作，我有一個建議：數位石棉移除。 82/

AI 代碼 - 以任何人類編碼者的 10,000 倍速度編寫，旨在運行良好，但不會優雅地失敗 - 是我們填充牆壁的數位石棉。我們的後代將花幾代時間將這些石棉挖出牆壁。 83/

我們將有很多工作要修復我們因為最危險的 AI 精神病而破壞的東西——那種錯誤的信念，認為「寫代碼」和「軟體工程」是同一回事。 84/

以我們目前的進展，未來幾代的石棉清除工將會有充分的就業機會。 85/