🔧 阿川の電商水電行
「軟體工程問題已經解決了。」最近我在瀏覽LinkedIn、X或Reddit時，看到的都是這句話。
訊息很明確：開發商這行完了，我們都應該立刻轉型，去當水管工或電工。
這並非完全異想天開。人工智慧編碼工具的進步速度之快，對軟體開發的影響幾乎超過了其他任何白領領域。精通這些工具的開發者可以快速產生大量可執行的程式碼，而死記硬背語法、手動編寫所有程式碼的時代已經一去不復返了。
顯而易見的答案是，程式碼產生只是軟體工程的一小部分。我這麼說的時候，通常大家都會點頭表示贊同。
但我們很少討論剩下的部分究竟是什麼。如果程式碼產生問題基本上已經解決，那麼問題就變成了：還剩下什麼？
目前，人工智慧編碼工具的效果參差不齊。一些開發者表示，這些工具大幅提高了他們的工作效率。而有些開發者則認為，它們反而降低了工作效率，最終只能產生一些毫無用處的AI程式碼。
造成這種差異的主要原因在於人工智慧編碼工具相關係統的建構和使用方式。
軟體工程看似已臻完善，是因為程式碼產生技術發展迅速。理解背後的原因，才能解釋我們目前所看到的現像以及未來的發展方向。
一個好的切入點是提出一個簡單的問題：為什麼程式碼生成是生成式人工智慧的一個成功應用案例？
為什麼人工智慧程式設計如此簡單
軟體開發高度依賴模式。我們使用語言語法、框架約定、資料結構、標準模式、可重複使用元件和熟悉的結構。
大多數程式碼都遵循既定模式。這些模型的訓練資料包含大量來自真實世界範例和開源專案的程式碼。我們可以從數百萬個常見模式的實作中學習。
編寫程式碼很大程度上是將已知的模式應用於新的問題。你需要一個 REST 端點？這裡有成千上萬個範例。需要驗證使用者輸入？想要實現身份驗證？這些模式也都有非常完善的文件。
這就是為什麼大多數常見用例的語法和實作基本上都已解決的原因。這些模型已經驗證過這些模式數千次，只需稍作調整即可可靠地重現它們，以適應您的具體情況。
但僅靠模式匹配並不能解釋為什麼人工智慧編碼工具如此有效。還有另一個因素使得軟體特別適合人工智慧生成。
軟體是可驗證的
對於大多數非人工智慧相關的應用場景，合適的軟體具有一個簡單的功能：相同的輸入產生相同的輸出。這就是確定性。
實際實現方式可能有所不同。如果將同一個使用者故事交給兩位不同的開發人員，他們會給出兩種不同的解決方案。
結構、抽象概念和技術可能有所不同，但從最終使用者的角度來看，功能需求必須得到滿足。
這種特性使得軟體格外適合人工智慧輔助開發。非確定性系統可以產生許多可能的實現方案，但我們仍然可以衡量結果是否正確。行為要么正確，要么錯誤。測試要么通過，要么未通過。
軟體的功能是最重要的部分，它可以自動測量和測試。
但許多不同領域都有可衡量的產出，可以進行測試和迭代。為什麼軟體開發人員很可能成為第一批感受到人工智慧全面應用影響的族群之一？
自動化是我們的文化
部分原因是軟體工程已經高度機械化，而且我們的文化也傾向於盡可能地自動化一切。
我們擁有完善的持續整合/持續交付 (CI/CD) 管線、自動化測試、自動化安全掃描以及各種指標。我們已經掌握瞭如何建立反饋循環和自動化流程。現在，我們將這些技能和經驗應用到工作的其他方面，這在生成式人工智慧出現之前是無法想像的。而之所以發展如此迅速，是因為我們既是領域專家，也是系統的建構者。
這造就了極其快速的迭代，而這種迭代在其他領域不太可能自然發生。
如果一位開發者在周一發現了一種真正具有創新性的人工智慧工程技術，那麼到了周三，它就會出現在一篇擁有數千讀者的部落格文章中。到了星期五，已經有很多人嘗試圍繞它開發工具。幾週之內，如果沒有其他技術取而代之，這項技術就會被整合到主流工作流程中。如此循環往復。
但即便取得了這些進展，實作仍只是軟體工程的一小部分。要讓系統在生產環境中可靠地執行，還需要付出大量努力。
軟體工程的其他部分
程式碼能夠正常運作只是正確性的一個面向。生產就緒的軟體需要多個方面同時協調一致，例如安全性、可擴展性、架構、可維護性、整合性、效能、穩定性以及依賴關係。即使系統單獨運作正常，如果忽略其中任何一個方面，都可能導致系統崩潰。
這往往引出了一個觀點：開發人員最終都會轉型為架構師。如果實現過程實現自動化，人類就可以專注於更高層次的系統設計。
這話不無道理，我認為我們目前就處於這種境地。在當今市場，了解系統設計的開發者俱有優勢。但更高層次的設計是否會繼續完全由人來完成呢？這種假設已經受到了考驗。
編碼判決
軟體工程中許多最困難的部分最終都歸結為判斷。對於特定的系統而言，「好」的標準是什麼？哪些權衡是可以接受的？複雜性應該體現在哪裡？正是這種判斷區分了可執行的程式碼和可用於生產環境的軟體。
開發人員已經在嘗試將這種判斷編碼到自動化系統中。這些系統看起來不像聊天機器人，更像是協同運作的管線。其中一個元件產生實作程式碼。其他元件則透過執行測試來驗證行為，使用確定性工具掃描問題，並評估架構問題。還可以加入更高層次的審查，由模型評估權衡、一致性和設計決策。
從很多方面來看，這看起來像是持續整合/持續交付（CI/CD）的自然延伸。系統不再是在人編寫程式碼後進行驗證，而是在程式碼產生的同時進行驗證。反饋循環更加緊密。
這也是規範驅動開發日益普及的原因之一。如果模型產生實現，那麼開發者就需要精確定義行為，以便能夠自動測試其正確性。開發工作的重點從編寫程式碼轉移到定義正確的程式碼應該是什麼樣子。
這些問題都還沒解決。雖然許多團隊正在積極研究（但成效不一），但目前還沒有行之有效的模式來自動化處理架構評估和效能驗證等更高層次的問題。
採用過程將循序漸進，受監管行業的進展速度會更慢，因為可靠性和問責制比速度更重要。但工程判斷的每一個向度，只要被納入驗證步驟，就代表系統能夠處理的事情又增加了一項。
對於那些使用最新最先進工具的開發者來說，開發中最困難的部分已經從學習語法轉移到培養判斷力。這種轉變可能會讓軟體職涯的早期階段更加艱難，因為判斷力的培養需要時間和經驗。
我們完蛋了嗎？
軟體開發時代結束了嗎？還沒有。
或許未來會如此。但我認為，人類參與人工智慧發展的時間會比我們這些身處人工智慧泡沫中的人們目前所認為的要長得多。時間會證明我的看法是否正確。
然而，這份工作的變化速度比我們大多數人預想的要快得多。開發人員現在只需幾個小時就能交付過去需要幾天才能完成的功能。小型團隊就能打造出以前需要數十名工程師才能開發的產品。
短期來看，市場對能夠建立使 AI 生成的程式碼可用於生產的系統的開發人員的需求日益增長。
我們過去大部分時間都花在編寫程式碼實作上。現在這部分時間正在減少。而與之相關的一切都在增長：弄清楚正確的軟體應該是什麼樣的，以及建立驗證程序來證明這一點。
原文出處：https://dev.to/aws/is-software-engineering-cooked-not-yet-but-maybe-5e0j
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
