在經典的《Programming Perl》（被一代技術人員親切地稱為「駱駝書」）中，Larry Wall 曾以懶惰、不耐煩和傲慢這三種程式設計師的美德聞名：
如果我們要談論好的軟體設計，我們就必須談論懶惰、不耐煩和傲慢，這是好的軟體設計的基礎。我們都曾陷入使用複製貼上（cut-and-paste）的陷阱，而應該定義一個更高級別的抽象，即使只是一個迴圈或子程序。當然，有些人走向了另一個極端，定義了不斷增長的更高級別抽象，而應該使用複製貼上。總的來說，大多數人需要考慮使用更多的抽象而不是更少。
在這些美德中，我一直認為懶惰是最深刻的：它包含在帶有諷刺意味的自我貶低中，是對不僅需要抽象，而且是抽象美學的評論。懶惰驅使我們盡可能簡化系統（但不能過度簡化！），開發出強大的抽象，從而讓我們能夠更輕鬆地做更多的事情。
當然，這裡的潛台詞是，要做到懶惰需要付出很多努力：當程式設計師從事看似懶惰的「吊床驅動開發」（hammock-driven development）時，我們實際上是在反覆思考問題。我們承擔開發這些抽象的艱難智力工作，部分原因是因為我們在優化未來自己的時間，即使是以犧牲當前時間為代價。當我們正確地進行這種計算時，這是輝煌的，因為抽象不僅服務於我們自己，也服務於所有後來的開發者。也就是說，我們的懶惰使得軟體更容易編寫，系統更容易組合——讓更多人能夠編寫更多軟體。
理想情況下，您會希望那些從抽象中受益的人能夠將懶惰的美德傳承下去——利用他們新獲得的力量來勞動於他們所創造的抽象。但是，過去二十年來軟體創作的擴展所帶來的後果之一是，它包含了越來越多不太可能稱自己為程式設計師的人——對他們來說，懶惰的美德將失去其原有的意義。
更糟的是，現代抽象所帶來的非凡生產力催生了一種虛假的勤奮。貶低地說，這就是「brogrammer」的興起，諷刺的懶惰美德和吊床驅動開發被關於「擊敗程式碼」的「hustle porn」所取代。
對這乾燥的火絨，閃電擊中了大型語言模型（LLM）。無論一個人對軟體創作的態度如何，LLM 都能以（大得多的）力量應用它，所以 LLM 已成為「brogrammer」群體的合成代謝類固醇，這並不令人意外。
他們對新獲得的力量感到欣喜若狂，似乎無法停止談論它。以「brogrammer」代表人物 Garry Tan 為例，他對自己使用 LLM 的態度尤其令人難以忍受，吹噓自己每天能寫三萬七千行程式碼（並且「還在加速」）：
（作為對比，DTrace 的總程式碼量——取決於你如何計算——大約是六萬行程式碼。）
如果懶惰是程式設計師的美德，那麼這樣思考軟體顯然是一種惡習。就像以重量來評估文學一樣，其謬誤即使對新手程式設計師來說也很明顯。
這裡的問題本身不是這些問題（這些都是可以解決的！），甚至不是相信創造它們的方法論代表了軟體工程的未來（儘管這肯定很煩人！）。
問題在於 LLM 本質上缺乏懶惰的美德。對 LLM 來說，工作沒有成本。LLM 不覺得有必要為自己（或任何人的）未來時間進行優化，並且會樂於將越來越多的東西傾倒在一個垃圾層層疊疊的系統上。如果放任不管，LLM 只會讓系統變得更大，而不是更好——或許會迎合扭曲的虛榮指標，但卻以犧牲所有重要事物為代價。因此，LLM 凸顯了我們人類的懶惰是多麼重要：我們有限的時間迫使我們開發簡潔的抽象，部分原因是因為我們不想浪費我們（人類！）的時間在笨拙的抽象後果上。最好的工程總是誕生於限制，而我們時間的限制限制了我們願意接受的系統認知負載。這就是驅使我們在系統本質複雜的情況下，使其變得更簡單。正如我在演講「簡潔的複雜性」（The Complexity of Simplicity）中所闡述的，這是一項重大的任務——我們不能期望那些不受時間或負載限制的 LLM 自願承擔這項任務。
這當然不是說 LLM 在我們未來不會扮演重要角色：它們是軟體工程的非凡工具，但是——正如我們在 Oxide 的 LLM 使用指南中所概述的——它們僅僅是一個工具。我們可以利用它們來處理程式設計師懶惰的非諷刺性（且非美德的！）方面——幫助我們處理技術債務等棘手問題——或者用它們來促進我們的工程嚴謹性，但這必須服務於我們自己的有益懶惰：產生一個更簡單、更強大的系統，不僅服務於我們自己，也服務於我們之後的幾代軟體工程師。