【CSDN 編者按】大模型快速發展的近兩年時間裏，不少程式設計師擔心自己開發的工作不保，有被替代的風險。不過，本文作者並不如此看待，接下來，他將從軟體開發的能力級別、外包開發、建模的復雜性、市場規模、業務邏輯定義等角度進行剖析，旨在說明軟體開發為什麽不會立刻消失。
原文連結：https://www.sheshbabu.com/posts/thoughts-on-the-future-of-software-development/
未經允許，禁止轉載！
作者 | Shesh babu Chinnakonda 譯者 | 彎月
責編 | 夏蒙
出品 | CSDN（ID：CSDNnews）
大型語言模型（LLM）能夠生成影像、文本和程式碼，在創意界引起了巨大的轟動。 這些模型最初的產物非常荒誕，畫出的人物手腳變形，生成的資料和程式碼也不準確。 但這些模型正在慢慢進步。 在這些模型出現之前，人們認為機器不具有創造性思維。 但如今這種觀點的底氣越來越弱。 接下來，我們該怎麽做呢？
思考未來會怎樣往往很難理清思路，所以我們需要依賴框架和類比。
框架：軟體開發能力級別
軟體開發不僅僅是寫程式碼。人們對程式設計師的刻板印象是：一個人坐在黑暗的房間裏盯著電腦，瘋狂敲程式碼。雖然整天寫程式碼聽起來非常吸引人，但軟體開發的大 部份時間都花在了與其他人溝通或其他管理工作上，而不僅僅是編寫程式碼：
收集業務使用者的需求。
提煉需求，以便將其建模成程式碼。
與其他團隊成員（如設計師和產品經理）交流，視覺化解決方案，並制定計劃。
與其他開發人員合作，制定技術設計並進一步細化。
設定基礎設施、配置、樣板等等。
實際編寫程式碼。
偵錯程式碼，理解其他人的程式碼、編寫文件等等。
部署到生產環境。
處理生產問題。
以及其他任務……
因此，「AI取代開發人員」就需要勝任以上所有任務，而不僅僅是編寫程式碼。
但是，仔細觀察上面的列表，你會發現有些任務也許將來可以自動化，而有些則不可以。我們如何透過框架呈現這個想法呢？
自動駕駛汽車提出了一種分類自動化程度的方法，從無自動化、到部份自動化、再到全自動化。我發現這種方法有很多優點：
清楚地描述了當前技術的能力。
防止我們以非黑即白的方式思考，並非 AI駕駛員完全取代人類駕駛員，而是可能存在灰色地帶，AI可以在緊急制軔、車道居中等方面輔助人類駕駛員。
那麽，對於AI驅動軟體開發，又該如何分類呢？
低階：舊時代，AI不參與軟體開發的工作。當然，我們之前也有其他型別的自動化，如編譯器、構建流程等，但這些不是AI，這些是人類編寫的確定性自動化。
中級：當前，開發人員使用ChatGPT或GitHub Copilot來輔助工作，使用AI來編寫測試、樣板程式碼、重構、理解程式碼/錯誤等。這就像與其他開發人員聊天，你可以提問並獲得一些幫助，但他們無法存取你的機器，因此無法建立檔、執行構建命令或部署到生產環境。
高級： 將計畫的一部份或整個計畫委托給開發人員。 這些 「AI編程人員」將接受需求，編寫程式碼，修復錯誤，並將最終產品部署到生產環境。 我認為，我們還需要付出大量努力，雖然目前AI只能執行一些簡單的開發任務，但未來可能會有所改善。
除了 AI模型可以做些什麽之外，我們還應該思考解決方案的準確性。 剛開始的時候，這些模型容易產生一些不太準確的答案，或者需要透過特定的提示才能得到想要的結果。 這會導致采用AI的阻力過大，大多數人因為這個問題而放棄了AI助手。 但這也在改善，更新後的模型不再需要那種程度的提示工程。 此外，AI模型應該能夠透過瀏覽網路來「學習」，而不僅僅是依賴訓練數據。 這一點很重要，因為新版本的庫和程式語言會不斷引入。
框架：外包軟體開發
既然我們已經確定了這些能力，那麽如何利用這些能力影響團隊或組織結構呢？各個公司開發軟體的方式多種多樣：
完全內部開發。
大部份內部開發，少量供應商。
大部份供應商，少量內部開發。
完全委托給供應商。
某種程度上，我們可以將 AI視為外包軟體供應商/顧問。 一些公司大量使用AI，而有些則不怎麽使用。 無論計畫的組成如何，我認為始終有必要透過一個內部團隊監督這些工作。 這是為了確保供應商的產出與組織的長期目標保持一致。 當然，你可以透過合約解決這個問題，但通常僅限於特定的供應商或計畫，你無法透過這種方法執行長期目標。 透過一個小型內部團隊來指導供應商更好。 同樣，即便AI可以像EC2例項一樣出租，透過一個內部軟體開發團隊來監督AI的工作會更好。
框架：軟體開發是建模復雜性
談到如何解決業務問題，讓我們花點時間來談談龐然大物： Excel 。眾所周知，Excel的全球使用者超過10億。Excel為組織數據、分析數據或自動化某些流程的業務使用者提供了非常低的門檻。然而，我們無法利用Excel梳理復雜的業務工作流程，因為它沒有提供細粒度的存取控制、與不受支持的系統整合、可測試性、可重用性或僅僅是供應商釘選等功能。「低程式碼」解決方案也有同樣的問題，如Power Automate等。
回到最初的問題， 業務使用者能否在沒有軟體開發人員的幫助下使用AI來建立復雜的工作流程？
想一想，Excel和低程式碼工具問世已經幾十年了，為什麽軟體開發行業仍然存在呢？歸根結底是因為這些解決方案認為軟體開發僅僅是編寫程式碼。然而，對於復雜的問題，我們需要能夠有效地管理這些復雜性並將業務問題從現實世界領域轉換為數位模型的人。
舉個例子，觀看短視訊，無需土木工程師的幫助，就能建造一個小木屋，但這並不意味著你就可以建造一座10層高樓。只有認真學習如何建造10層的建築，慢慢地你才能成為一名土木工程師。這就要看你是願意花時間認真學習，還是聘請一位經驗豐富的工程師來替你完成。
因此，無論這些人使用Excel還是最新的AI，如果他們正在對復雜的邏輯進行建模，那麽在我看來，他們就是軟體開發人員。只不過，他們使用不同的工具來表達業務需求：電子試算表公式、程式碼還有AI提示。
框架：市場規模
圍繞這個話題的大部份焦慮都假定軟體開發市場的規模保持不變，AI將逐步從人類手中奪走「市場份額」。
透過前面的討論，我們了解到「解決業務問題」的市場規模遠遠大於軟體開發。因此，
框架：正式的業務邏輯定義
業務邏輯必須透過某種明確的格式定義。這就是為什麽雖然程式語言使用「if」、「switch」等英語單詞，但依然對這些單詞的含義進行了嚴格的規定，如果使用錯誤的單詞，程式碼就無法執行。仔細想一想，Excel公式或低程式碼流程也是如此。
將來，即使AI能夠透過以對話的形式給出的指令生成軟體產品，我仍然相信後端生成的業務邏輯會有一個底層的正式定義。有可能這種正式的業務邏輯定義不同於我們今天使用的語言和框架，看起來很像「程式碼」。
也許將來AI能夠以確定性的方式根據對話生成這些業務邏輯，但在這之前，我們仍然需要能夠理解AI在後端生成的程式碼並根據需要修改這些程式碼的人。而這些人正是軟體開發人員。
總結
總的來說，我相信在可預見的未來，軟體開發人員仍然有市場，只不過工作性質將發生變化，使用的工具也有可能與現在大不相同。
推薦閱讀：
