【CSDN 編者按】這篇文章探討了軟件工程的復雜性，以及如何應對。作者認為，雖然大型語言模型（LLM）如 ChatGPT 可以減少編寫軟件時的“偶然復雜性”，但“本質復雜性”仍然是一大挑戰。LLM 的出現將改變軟件工程，但我們仍需警惕其潛在問題。
原文鏈接：https://www.kolide.com/blog/can-chatgpt-save-programmers
作者 | Jason Meller譯者| 明明如月
責編 | 夏萌
出品 | CSDN（ID：CSDNnews）
在我二十多歲時，笑容常掛在我的臉上。最初我并未察覺，但和我熟悉的人都會注意到這一點，大多數情況下，這被視為一種正面的特質。
然而，有次一位軟件工程師用困惑和擔憂的眼神問我：“你為什么總是這么快樂？”
這個問題讓我有些意外。據我所知，我擁有一切應當讓人感到快樂的條件：我剛加入了一家我非常喜歡的公司，擔任的職位與我的專長高度匹配，同事們都是才華橫溢且工作熱情高漲的人。更重要的是，我們正在享受公司贊助的部門晚宴，這是一周緊張工作和會議后的輕松時光。在這樣的環境下，誰會不快樂呢？
答案出人意料：軟件工程師。
當我環顧整個房間，忽略那些熱情洋溢的高級管理人員、愉悅的項目經理和樂觀的用戶體驗設計師后，我看到了另一幅畫面，一幅令人擔憂的畫面。
我們團隊里最資深的工程師獨自坐在吧臺前，下巴放在手掌上，由于頭部壓力，肘部已泛紅。他另一只手的食指在吧臺上隨意地劃來劃去，顯然心情并不好。
在房間的另一個角落，四名工程師圍成一個小圈子。其中一人正用手勢激動地解釋著某個問題，而其他人顯然是在不耐煩地等待他結束，以便他們能發表自己的觀點。他們的面部表情都很嚴肅。
后來我了解到，他們當時正在討論一個表面上看似微不足道，但實際上非常有爭議的問題：數據庫中第一條記錄的 ID 應該是 0 還是 1？
這讓我明白了，那名先前覺得我總是快樂的軟件工程師為何會有這樣的疑惑。作為一名編程專家，我為何總是笑容滿面呢？
如今，我 38 歲，肩負著一對嬰兒雙胞胎和一個三歲孩子的父親角色。同時，我還是一家擁有 30 名員工的初創公司的創始人和 CEO。這家公司為數百家企業提供關鍵的身份驗證服務。面對這么多身份和責任，額頭上的皺紋加深、體型微胖、頭發漸白，以及眼下的黑眼圈都似乎成了理所當然的事。
然而，這些身體和精神的消耗主要源于一個因素：我依然在編程。
請不要誤解，我對編程依然充滿熱情，只是現在人們不再因為我的樂觀而稱贊我。
我并非孤例。Cobalt 最近發布的研究報告調查了超過 600 名網絡安全和軟件開發專業人士，揭示了一些令人震驚的現象：
- 58% 的受訪者正面臨職業倦怠。
- 53% 的受訪者考慮辭職。
- 63% 的受訪者認為工作對他們的心理健康有負面影響。
- 64% 的受訪者認為工作對他們的身體健康有負面影響。
回頭看看我以前的工程師同事，幾乎所有人都已經不再進行日常的代碼編寫工作。事實上，許多人已經完全退出了科技行業。
一名程序員因職業倦怠而崩潰，這是他在被要求澄清一個問題時的真實回應。
“哦，這有什么大不了的？”你可能會這樣想，“坐在 700 美元的椅子上，穿著睡衣，在 3000 美元的 macBook Pro 前工作 8 小時，一周幾天，有什么難受的呢？”
現在，讓我來告訴你。
為什么軟件工程如此困難？
根據我的經驗，如果你選擇軟件工程僅僅是為了賺錢，你在這個領域里可能走不遠。事實上，對于大多數開發者來說，有數百個其他職業路徑可以提供同樣或者更高的薪資、聲譽和職業滿足感。
我們可以從另一個角度來深入了解編程如何影響個體情感。面對各種挑戰，為什么人們還是堅持下去？這些堅持的原因通常是高度個人化和深刻的，但當你與足夠多的人進行交流后，你會發現一些反復出現的主題。
編程不僅是一種技術活動，更是一種高度創造性的過程，它常常觸及到思想和情感的深層。有時候，人們會以一種程序員完全沒法預見或者想象到的方式，來利用這些創新成果。也許，沒有什么比創造出別人能夠欣賞和使用的產品更能體現人類創造力的純粹性。
在這方面，1975年軟件工程經典著作《人月神話》的作者弗雷德里克·布魯克斯是最有發言權的人。這些論文不僅歷久彌新，而且具有近乎神秘的相關性。以下是我最喜歡的一段文字，摘自名為 “工藝的樂趣” 的章節。
“在如此靈活的媒介中工作，確實帶來了一種獨特的愉悅。程序員，有點像詩人，工作的素材幾乎完全是思想。他們在虛空中構建自己的‘城堡’，這些‘城堡’是由純粹的思想和想象力塑造的。很少有哪種創造性媒介能像編程語言那樣，容許你如此自由地打磨和重塑，如此方便地實現宏偉的構想。”
布魯克斯還描述了編程的另一面，這一點體現在名為 “工藝的困擾” 的章節中。
“為了編程的有效性，人必須追求近乎完美的準確性。在這一點上，計算機就像是傳說中的魔法。如果代碼中的一個字符、一個語法結構沒有嚴格地按照規定來編寫，那么整個程序就可能無法運行。人類并不特別擅長追求完美，而且很少有其他活動會對人們如此嚴格地要求完美。我認為，適應這種對完美的高標準，是學習編程過程中最具挑戰性的一部分。”
這篇文章寫于 1975 年。
延續布魯克斯的思想，我發現編程中的樂趣與困擾往往是交織在一起的。我最自豪的編程成就往往來自那些幾乎讓我精疲力盡的項目。解決了長期困擾我和我的團隊的 bug 會帶來巨大的成就感。然而，這種成就感與陷入絕望時的沮喪是密不可分的。比如，花數小時去調試程序中一些令人困惑的行為，最后卻發現問題僅僅是因為我寫了 “initializer” 而非 “initialize”。這樣的經歷對于我們中的大多數人來說，是一種無休止的循環。難怪在社交場合中，很少有人笑得出來。
數十年來，我們經歷了計算能力的指數級增長、先進開發工具的出現，以及編程語言變得更加人性化。那么，為什么布魯克斯的觀點在今天仍然有強烈的共鳴呢？
概念壓縮與走向 AI 的路徑
在我 11 歲時，我夢想著能制作一款屬于自己的游戲。
那一年，我在公共圖書館找到了一本名為《游戲編程大師的技巧》的書。書的封面設計得非常酷，仿佛是一款類似于 DOOM 的第一人稱射擊游戲的包裝。我心想，“這就是我要的。”我隨手翻開了書的某一頁，記得非常清晰，我看到了這樣一個圖表：
其實，當時我認識其中的一些單詞而已。
我仔細翻閱了整本書，試圖找到任何我能理解的、或者看起來稍微“像是游戲”的內容。結果一無所獲。于是，我失望地合上了書，從此以后，我再也沒有告訴任何人我曾經想成為一名游戲工程師。
然而，因為“概念壓縮”的存在，下一代有志于游戲開發的年輕人會有全新的體驗。
以 2015 年為例，一個名叫 Toby Fox 的 23 歲年輕人發布了一款名為 “傳說之下（Undertale）” 的游戲。這款游戲完全是在他個人的家用電腦上開發完成的。盡管這款游戲是自主發布的，但它成功賣出了數百萬份，并獲得了業界的一致好評。許多媒體甚至將其評為“年度最佳游戲”，擊敗了許多擁有巨額預算的 AAA 級游戲。
“傳說之下” 是在一個名為 Game Maker Studio 的可視化工具中開發的，這正是概念壓縮的體現。
概念壓縮 是由 David Heinemeier Hansson（DHH）首次提出的，他是 Ruby on Rails 的創始人。這個 Web 開發框架不僅對我的整個科技職業生涯有著不可或缺的影響，也對我所在的 Kolide 公司非常重要。簡單來說，概念壓縮描述了編程從底層的二進制語言，到更接近自然語言的 Ruby，再到如今的低代碼或無代碼工具，以及 LLM（Language-agnostic Low-code Model）的發展過程。
Hansson 創造這個詞組的博客文章 摘錄：
“在計算機科學領域，構建應用程序意味著在多層抽象的基礎上進行開發。從 CPU、1 和 0，到匯編語言、C 編譯器、數據庫驅動、內存管理，以及其他無數關鍵概念，都是應用程序運行所依賴的基礎。然而，隨著這個行業的不斷發展，越來越少的開發者需要深入了解這些底層細節。
優化‘概念壓縮’算法，以便減少開發者需要關注的底層復雜性，雖然是一項巨大的挑戰，但絕對值得。我們越能有效地壓縮過去的復雜概念，進入這個領域的門檻就越低。如果我們希望更多的人參與應用開發，降低入門門檻是必不可少的。”
“概念壓縮”不僅讓 Toby Fox 能夠開發出“傳說之下”，還極大地推動了軟件工程領域新人的增長。然而，這些新入行者同樣需要面對這個行業帶來的各種挑戰和困擾。簡而言之，在降低編程的心理和情感負擔方面，讓編程“更易接近”并不意味著它也“更易操作”。
在開發“傳說之下”的續作過程中，Toby Fox 在多個進度報告中分享了他的經驗。他談到了更換游戲引擎所導致的時間損失、與其他工程師合作的挑戰、由長時間編程引發的手腕疼痛，以及因項目周期過長（已達 8 年并仍在進行）而導致的睡眠問題。
“雖然游戲尚未完全完成，但剩余的開發工作確實在逐漸減少。這是好事，因為在游戲完成之前，我每晚都會受到噩夢的困擾。”
那么，為什么即使“概念壓縮”增加了進入這個領域的人數，編程本身卻并沒有變得更簡單呢？尤其是對于那些在新型“概念壓縮”技術出現之前就已經在這個行業工作的人來說。
事實上，這里的情況相當復雜。雖然這些技術進步讓編程變得更容易，但并沒有從根本上降低編程所需的勞動強度。要理解這一點，我們需要討論一個在軟件開發領域長期缺失的概念——那就是“銀彈”解決方案。
ChatGPT 對開發者來說是銀彈嗎？
Fred Brooks 在 1986 年的具有里程碑意義的論文《沒有銀彈——軟件工程的本質與偶然》中開篇便提出了一個與本文討論密切相關的觀點：
“在各種流行的神話和傳說中，狼人常常是最令人恐懼的存在，因為它們能在你最不預料的時刻從一個熟悉的形態變為可怕的怪物。為了消滅這些威脅，人們常尋找能一擊致命的銀彈。
在非技術經理的眼中，軟件項目往往也具有類似的特性：它們看似簡單、無害，但卻可能突然變成一個超出預算、延誤交付并且充滿缺陷的問題項目。因此，人們急切地尋找那個能像計算機硬件成本一樣迅速降低軟件成本的‘銀彈’。
然而，當我們展望未來十年，我們并沒有看到這樣的銀彈解決方案。沒有任何單一的技術或管理方法能夠顯著提升生產力、可靠性或簡單性。”
盡管我建議你完整地閱讀這篇文章，但其中一個核心觀點是他對兩種不同類型復雜性的討論：偶然復雜性和本質復雜性。Brooks 強調，這些復雜性是編程工作中不可或缺的因素，因此沒有所謂的銀彈能完全解決這些問題。
偶然復雜性：工具導致的問題
在軟件工程領域，偶然復雜性是指由我們用于完成任務的工具和抽象層帶來的復雜性。這種復雜性也常被稱為附加復雜性，因為它與工程師試圖解決的核心問題幾乎無關，主要是因為我們使用的工具局限性導致的不必要復雜性。例如，編程語言、庫、框架、測試方法、Web 服務器，以及用于數據庫查詢的語言都是偶然復雜性的來源。
需要明確的是，“偶然”并不等于“不重要”。實際上，許多開發者經常遇到的問題往往與這種偶然復雜性有關。
編程中對人完美執行的高要求就是一個偶然復雜性的例子。與大多數偶然復雜性一樣，這種復雜性可以通過改進工具和流程來減輕，甚至有可能在未來完全消除。Brooks 也沒有否認這一可能性。
本質復雜性：問題固有的挑戰
在軟件工程領域，本質復雜性是與你所要解決的具體問題緊密相關的復雜性。以主題公園（如迪士尼樂園的 FastPass）的游樂設施預約系統為例，無論你選擇何種編程語言來實現這個系統，都需要解決一系列固有的復雜問題，以確保軟件的實用性。我們將在后文進一步深入探討這個案例。
本質復雜性也是導致開發難度增加的主要因素之一。你是否曾經想過，為什么程序員需要掌握如此多看似無關緊要、但實則極其復雜的細節呢？這些都是他們在多年的職業生涯中不得不面對的本質復雜性。
以斯坦威鋼琴工廠的員工為例，他們可能并不需要知道如何演奏鋼琴。然而，對于那些需要為數字音頻軟件開發一個模擬斯坦威鋼琴音效的插件的程序員來說，情況就不同了。為了精確地完成這項任務，他們不僅需要了解鋼琴的基本工作原理，還需要對和聲學和共振有深入的認識。甚至還需要掌握一些難以用語言描述的知識。這些知識更多地依賴于感覺和經驗。
那么，斯坦威鋼琴的音色為何如此引人入勝？它與其他如 Bösendorfer 或 Bechstein 鋼琴有何不同？想要在數字音樂領域做出有意義的貢獻，程序員必須全面了解這些因素。這也是他們常感到壓力巨大的原因。在面對這些本質復雜性時，為了在這由“純粹思想”構成的領域中脫穎而出，我們不僅需要對完美執行有高要求，還需要精細地管理和掌控這些復雜性。
幾乎所有軟件工程的進步都更多地減少了偶然復雜性而非本質復雜性。這甚至包括像 ChatGPT 這樣的大型語言模型（LLMs）。
大型語言模型（LLMs）可以視為一種數字化的信息中心，能即時訪問各種重要數據。在最理想的情況下，這些模型能夠理解人類在書籍、互聯網以及其他計算機相關文檔中的所有有價值的信息。
經過訓練后，LLMs 能根據輸入的提示進行概率性的回應。對于每一個可能的回應詞或“token”（可能是一個完整的詞或詞的一部分），模型會計算該詞作為下一個詞出現的概率，基于其在訓練數據中觀察到的模式。這個過程就像是一個基于訓練數據來猜測“下一個 token 會是什么”的游戲。
令人驚訝的是，這種看似簡單的方法已經是我們目前能夠實現的最接近人類智能的技術。ChatGPT 的最新版本甚至能完成大多數高中、大學和研究生級別的任務。它們也能通過律師資格考試，盡管這更多地反映了我們的考試方式，而不是模型本身是否能成為優秀的律師。盡管我不希望看到一個全由 LLMs 編寫的書籍世界，但我必須承認，不能忽視它們的能力和潛力。特別是，它們在減少軟件工程中偶然復雜性方面表現出色。
正因為 LLMs 的高度靈活性，它們可能是迄今最有效的工具，用于減少偶然復雜性對工程師時間的影響。LLMs 不僅能將你不熟悉的編程語言翻譯成你能理解的語言。它們還能教你如何高效地使用之前未接觸過的工程工具，并甚至能幫助你發現編譯器和 linting 工具難以識別的代碼錯誤。
更重要的是，與以往任何工具不同，LLMs 是我第一次遇到的能夠減輕本質復雜性負擔的工具以我們之前提到的迪士尼樂園“快速通行證”為例，如果我們想實施一個類似系統在自己的主題公園，應從何開始？以下是我與 ChatGPT-4 在這個主題上的一次互動。
ChatGPT 提供了一個極其詳細的答案。然而，很難判斷它是否僅僅是用更多的冗余詞匯復述了我的問題。它解決了任何本質復雜性嗎？讓我們來問問！
對于對主題公園預約系統一無所知的人來說，ChatGPT 的答案無疑是極具參考價值的。它甚至涉及到了我未曾考慮過的緊急處理方面。當然，專業的公園設計工程師可能會在這個答案中找出一些不足，但即便如此，這個答案為我提供了一個很好的出發點。
然而，這個答案更多地是對問題的描述，而并沒有給出具體的解決方案。那么，如果我們進一步利用 ChatGPT 的能力，甚至讓它開始生成代碼，結果會如何呢？
在代碼中，我們進一步看到了在特定緊急情況下將預約重新分配給其他景點的考慮因素。如果沒有可用的游樂設施，它會向客戶道歉并提供賠償。這會是最終用于生產環境的代碼嗎？當然不是。我將要花費很多時間來處理緊急系統的編寫復雜性。這種復雜性有沒有得到實質性的減少？答案是肯定的。
ChatGPT 的一個明顯短板是有輸入和輸出長度限制。以 ChatGPT-4 為例，其最大響應長度限制為 8000 個 token，大致等同于單詞數。這個數字聽起來似乎很大了，但在實際生成代碼的過程中，這一限制很快就會顯現，尤其是當你需要 ChatGPT 構建一個完整系統時。即使嘗試通過多次交互來突破這一限制，你也會發現 ChatGPT 開始忽略你最初提出的需求細節。因此，人類工程師仍需手動管理 ChatGPT 的“狀態”，以生成一個完整且連貫的工作成果。然而，這個限制可能不會永久存在。
ChatGPT 還存在一個可能無法解決的問題，即它有時會產生被稱為“幻覺”的錯誤。在這種情況下，ChatGPT 會編造信息，甚至可能扭曲基礎事實，以便更方便地回應你的問題。值得注意的是，當你指出這些錯誤時，ChatGPT 通常會承認并糾正它們。
人類在作為 Large Language Models (LLMs) 輸出的“質量控制”方面發揮著關鍵作用。尤其對于經驗較少的工程師而言，LLMs 可能具有潛在危險。這些工程師可能過去曾依賴于基于社交信號（如 StackOverflow 上的投票、Github 上的星標、Reddit 上的贊同）或僅憑同事的信任來驗證在線找到的不透明代碼。然而，當涉及到 LLM 時，這種方法并不可行。LLM 可能會用和給出好建議時相同的自信，提供不好的建議。
的確，和長度限制問題不一樣，這個限制可能是無法克服的。對于那些多年來一直使用 LLM 的人來說，它幾乎已經融入了技術的基本原理。對 LLM 進行專業級的人工監督是必要的 —在評估 ChatGPT 針對現今軟件需求的性能時，多數人關心以下幾個問題。作為一名資深軟件工程師、產品設計師、創業公司 CEO，以及 ChatGPT 的常規用戶，我將盡力給出這些問題的真實回答。
Q：ChatGPT 能否減少構建和維護產品所需的軟件工程師人數？
A：確實如此，尤其適用于小型團隊。ChatGPT 有效地降低了開發過程中的隨機復雜性，同時也在一定程度上減少了固有的復雜性，這樣你就可以在不需要大量專業人才的前提下，也能構建完整的系統。
Q：ChatGPT 能否增加可供招聘的工程師數量？
A：是的，ChatGPT 使得編寫現代應用程序對于初學者變得更為簡單。
Q：ChatGPT 能否減輕軟件工程的工作負擔？
A：是的，減輕程度顯著。
綜上所述，盡管 ChatGPT 存在局限性，但它實際上是現代軟件工程的一顆“銀彈”，這也是第一次證明布魯克斯的悲觀預測是錯誤的。
這里有一個值得思考的問題：我說 ChatGPT 使現今軟件編寫更簡單，但是，誰能保證未來不需要新的軟件呢？
45 分鐘的困擾：一個個人經驗
在 COVID-19 疫情期間，許多人開始了遠程工作模式。對于像我這樣初次體驗遠程工作的人，通勤時間從曾經的漫長車程或地鐵行駛瞬間縮短為從床到電腦的幾秒鐘。我的通勤時間從 45 分鐘瞬間縮短到了 3 秒。
那么，我用這些額外的時間做了什么呢？多休息？或是在床上放松？并非如此，我反而找了各種瑣事和無聊任務來填補我的早晨。比如，我開始步行 45 分鐘來回，只為了買一個我認為每天早晨必須吃的早餐三明治。當我們搬家后，我和我的妻子不得不駕車穿越兩個城市，以便讓孩子繼續在原來的日托服務中心。猜猜我們每天的通勤時間是多少？沒錯，還是 45 分鐘。
Bruce Tognazzini 是一位領先的可用性設計專家和 Apple 人機界面指南（HIG）的創始人。他在 1998 年的一篇文章中曾探討了軟件工程與 UI 設計的復雜性問題。該文章題為“復雜性悖論”，其中提出了 Tog 的“通勤定律”：
“‘通勤時間是恒定的，只有距離是可變的。’這句話意味著什么？無論我們如何努力減少復雜性，人們總會在生活中尋求相同或更高級別的復雜性。如果道路變得更暢通，人們會選擇更遠的居住地。
結合 Tesler 的‘復雜性守恒定律’和 Tog 的‘通勤定律’，我們可以預見到未來可能出現的二階效應。如果我們減少了人們在特定任務中感受到的復雜性，而人們仍然傾向于維持相同級別的復雜性，那么他們會選擇更具挑戰性的任務。”
不論我對早餐三明治或遠程日托服務的個人偏好如何，這種觀點同樣適用于我作為軟件用戶的經驗。
我第一次使用 Photoshop 是在 17 歲時。當時我父親擁有一臺早期的 Sony Mavica 數碼相機，該相機能將圖片直接燒錄到內置的迷你可寫 CD 上。由于我幾乎總是待在電腦旁，因此自然而然地成了負責“整理”這些照片的人。
我還記得第一張用于測試相機的照片，當時是我編輯的。照片是我站在全身鏡前的特寫，無論是鏡子還是我自己，都顯得不太整潔。我的襯衫上沾滿了面包屑，臉上有不明物質，甚至牙齒里還有黑色的罌粟籽。我立即開始使用 Photoshop 中最新推出的修復畫筆工具，以改善我的形象。經過一兩個小時的努力，雖然結果看起來有些不自然，但總體上比原來要好得多。接著，我開始編輯下一張照片，那是我妹妹坐在沙發上，兩側各有一只不太高興的暹羅貓。這張照片的問題更多：相機捕捉到了沙發和我妹妹黑色褲子上的所有淺灰色貓毛，背景的白墻因為過度曝光而變得過于明亮，以至于我妹妹的面部特征都模糊了。最終，我放棄了編輯，告訴家人不如保留原樣更好。“這樣看起來更自然，”我解釋說。我想他們接受了我的觀點。
如今，我大多會在手機上直接編輯為家人拍攝的照片。但說到“編輯”，其實我幾乎沒有做什么，因為現代 iphone 的照片質量已經相當出色。雖然少花時間處理照片能多陪伴家人，聽起來不錯，但實際情況并非如此。
出于某種原因，我總是想進一步優化這些照片。我會將它們導入到最新版本的 Photoshop 中，進行一些兩年前我還覺得不可思議的操作。例如，我會選擇一張照片，然后使用 Photoshop 的“Generative Outpainting（生成性圖像擴展）”功能，讓 AI 根據周圍的像素預測并擴展圖像。在另一張拍攝于城市中心、人群繁多的照片中，我會花費時間逐一刪除其他人，讓我妻子看起來仿佛是地球上唯一的人。
這是 Adobe Photoshop 當前版本中“生成性擴展”功能的一個示例。來源
然而，與近 20 年前使用修復畫筆的經歷相似，我逐漸對這些高級工具和隨之而來的復雜性感到厭倦。這些工具運行緩慢，容易出錯，通常需要多次嘗試才能達到滿意的效果。處理幾張照片后，我通常會覺得耐心已盡。然后，我就轉去做其他事情。
這正是 Tog 的“通勤定律”所揭示的一個簡單但令人沮喪的人性真相：我們生活中的許多復雜性和挫折不僅是自我造成的，還受到一種隱形但持久的平衡機制的影響。
在未來，程序的基礎復雜性可能會達到一個令人難以置信的程度。只有當我們將人類的創造性與 LLM（大型語言模型）的生產力相結合，這種復雜性才可能變得可管理。與此同時，由于大多數競爭市場的零和性質，我們仍然面臨著自計算機科學誕生以來一直存在的勞動問題。即使我們解決了所有已知的問題，新的挑戰和問題也會不斷出現，重新制造出相同的困境。總之，生活就像一場舞蹈，兩步向前，兩步向后。
在結束之前，我想說，盡管 ChatGPT 不能永久解決軟件工程的各種問題，但這并不意味著軟件開發的體驗不能得到改善。這就是為什么我們所有人都需要從現在開始關注這些模型。特別是那些對大型語言模型（LLM）持負面態度的人，因為這些模型仍處于發展初期并具有可塑性。
大型語言模型（LLMs）勢不可擋，但我們可以影響它們
盡管像 ChatGPT 這樣的 LLMs 存在多種問題，從短期和長期角度來看，工程師接納這些模型仍符合我們的最佳利益。它們不僅簡化了當前的軟件開發流程，而且可能是我們接近“無勞作”狀態的最佳途徑。更為重要的是，隨著用戶需求的不斷演變和 LLMs 帶來的生產力提升，這些模型將成為未來軟件開發的關鍵工具。
這并不意味著我們應無條件接受 LLMs 所帶來的所有副作用。實際上，工程師而非高層管理人員將最終決定這些工具如何整合到我們的工作流程中，以及在哪些具體項目中應用它們。此外，我們還需要明確哪些任務應由人類完成，以保留人的獨特價值。
如果你是一名軟件工程師，現在正是時候與你的管理層合作，讓他們理解并接納 LLMs 在其擅長的領域（比如，輔助軟件開發）的應用，同時也要引導他們規避潛在的風險（例如，完全替代人類完成關鍵任務）。
現在也是制定與 LLMs 交互的最佳實踐的好時機，比如堅持使用明確的提示和智能代碼補全，以及探索如何緩解它們的主要缺點（例如，通過添加社會信號來評估建議的質量）。此外，我們還需要為新入行的工程師做好準備，因為他們從職業生涯的第一天起可能就已經會使用這些工具了。
對于工程管理層，現在是時候與工程師合作，制定詳實和務實的政策，這些政策不僅接受 LLMs 的不可避免性，還著重于教育員工關于它們可能帶來的知識產權風險、安全隱患以及對程序員長期能力的潛在影響。這一點尤為重要，因為我們的一項調查顯示，雖然 89% 的員工定期使用 AI 工具，但只有少數人明確了這些工具的安全使用政策。
一旦你掌握了這些最佳實踐，與他人和公眾分享這些信息是至關重要的，這樣我們都能更好地適應這個由 AI 輔助的工程工具主導的新時代。我們目前正在 Kolide 上制定 AI 的可接受使用政策，并計劃在有成果后盡快與大家分享。
LLMs 雖然不完美，可能永遠也無法達到完美，但我們可以通過持續努力來改善這種情況。最終，LLMs 將成為每位軟件工程師工具箱中不可或缺的一部分。盡管如此，這個工具箱仍然會牢牢地依附于一個真實的人類，即使他的薪資很高，也可能并不總是面帶微笑。
你認為 ChatGPT 能拯救程序員嗎？你認為大語言模型對軟件開發將會有怎樣的影響？
參考鏈接
- Cobalt 最近發布的研究報告：https://www.cobalt.io/hubfs/State_of_Pentesting_2022.pdf
- 一名程序員因職業倦怠而崩潰：https://github.com/Docker/cli/issues/267#issuecomment-695149477
- 博客文章：https://m.signalvnoise.com/conceptual-compression-means-beginners-dont-need-to-know-sql-hallelujah/
- 進度報告：https://undertale.com/deltarune-update-092020/
- 沒有銀彈——軟件工程的本質與偶然：https://www.math.unipd.it/~tullio/IS-1/2004/Approfondimenti/BrooksNoSilverBullet.html
- LLMs 能根據輸入的提示進行概率性的回應：https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-doing-and-why-does-it-work/
- 我們的一項調查：https://www.kolide.com/blog/unmanaged-devices-run-rampant-in-47-of-companies
