過去一年，我的日常工作發生了一種我至今仍在試圖理解的變化。我還是工程師，還是在設計系統、讀程式碼、除錯、審查實作，有時候也會自己動手做一些東西。但我寫的程式碼比以前少得多，這讓我感到有點奇怪。
在我職涯的大部分時間裡，產出軟體就是我正在工作的可見證據。你有一個問題，你設計解法，你寫出程式碼，到了今天結束時，原本不存在的東西就存在了。努力和產出之間有非常直接的關係。
而現在，這種關係正在消失。
我身邊大量的實作工作，現在都可以由 AI 生成。並不是完美的、不是自主完成的，也不是不需要監督，但已經便宜到足以讓「第一版實作」越來越不再是最困難的部分。如果我需要一個 API 端點、一個資料庫遷移、一個資料轉換、一組測試、一次整合，或某種內部工具，我可以描述問題、提供足夠的上下文，然後出乎意料地快速拿到一個看起來合理的實作。
真正昂貴的部分是在之後：它真的能運作嗎？
不只是「程式能跑嗎？」或「測試會過嗎？」真正的問題是，這個功能在我們真正關心的各種情境下，是否都能正確運作。這個問題慢慢變成我工作中更大的一部分，也改變了我看待自身價值的方式。
一年前，我花更多時間思考要怎麼實作某件事。現在，我花更多時間思考它會怎麼失敗。當模型收到我們沒預料到的輸入時會發生什麼事？當兩個元件彼此不一致時會怎樣？當看起來正確的答案其實包含錯誤證據時呢？當評估器本身有偏差時呢？當一個模型有 95% 的成功率，但剩下的 5% 正好包含對業務最重要的那些失敗時，會怎麼樣？當備援機制悄悄切換了供應商、區域、延遲、成本或行為時，又會怎樣？當一切都回傳 HTTP 200，但系統還是錯的時候呢？
實作往往不再是最困難的智力問題。失敗偵測才是。預防失敗才是。定義「夠好到可以上線」究竟代表什麼，也才是。
這造成了一種奇怪的倒轉。幾十年來，軟體工程都把測試與驗證視為實作之後的事。先把東西做出來，再由某個人檢查它是否能運作。在 AI 系統裡，我越來越感受到相反的情況。生成實作變得更便宜，而知道你是否該信任它，卻變得更昂貴。
例如這週，在我休假一段時間之後，團隊請我為某個功能做一個新的評估器。乍看之下，這幾乎像是 QA 的工作，我承認自己對這個想法有一部分是負面反應的。我花了好幾年學習如何打造軟體。我是不是正在慢慢變成那個檢查別人工作的人？
但我認為，這種解讀沒有抓到真正正在發生的事。
建立評估器真正困難的地方，很少是寫出評估器本身。AI 在這件事上也能提供很大幫助。真正困難的是，先決定評估器到底該衡量什麼。什麼算失敗？哪些失敗可以用確定性方式檢查？哪些需要統計評估？哪個資料集能足夠代表現實？盲點在哪裡？評估器本身會不會被欺騙？兩個看似獨立的檢查，其實是不是犯了同一個錯？什麼樣的門檻才足以把東西發佈到正式環境？
這些其實不是在問測試實作的問題，而是在問正確性的操作定義。對 AI 而言，正確性正變成一件我們必須工程化處理的事情。
傳統軟體給了我們一個相對安心的契約。對於相同的輸入與狀態，確定性軟體通常應該產生相同的輸出。LLM 打破了這個假設。它們能在極大的輸入空間中產生看似合理的輸出，而且它們可以產生在結構上正確、語言上優美、內部一致，卻完全錯誤的結果。
所以我們把它們包在軟體裡。加上限制、驗證輸出、比較訊號、建立備援路徑、在機率性行為外圍加入確定性檢查、建立評估資料集、衡量迴歸、觀察正式環境的追蹤紀錄。然後，幾乎不可避免地，我們又發現某種以前不知道存在的失敗模式，接著再次修改系統。
我現在有相當大一部分工作，就處在那條邊界上。不再是創造智慧，而是讓機率性的智慧足夠可靠，能成為真實產品的一部分。
這也因另一個理由讓我感到不安。如果 AI 可以生成實作，那為什麼不能有另一個 AI 最終也生成評估？為什麼我不能描述我的原則、我的不信任方式、我尋找邊界案例的方法，然後把這些都編碼到另一個代理中？
答案大概是：我可以。而且我應該這麼做。
如果我發現了一種可靠的失敗模式，我就想自動化它的偵測。如果我反覆進行同樣的審查，我就希望有系統替我做。如果一個確定性的閘門可以取代我的人工判斷，那麼建立這個閘門就是進步。我的價值不能依賴於保護某些任務不被自動化，因為那會是一種註定失敗的策略。
所以，也許重要的區別不是人類能做的工作和 AI 能做的工作，而是已知問題與未知問題之間的區別。
一旦某種失敗模式被理解，它就會變得更便宜。我們可以把它寫進測試、建立評估器、加上政策，或教一個代理去尋找它。然後困難就會移到別的地方。前線會變成下一個我們還不知道怎麼衡量的東西，而這似乎正是我越來越多工作的所在。
我現在的產出越來越不是程式碼，而是定義、限制、架構、失敗分類法、發佈標準，或包在機率性事物外圍的確定性防護。有時最後的成果只有二十行程式碼，但那二十行可能代表了兩天對究竟該防止什麼的思考。
這改變了生產力的感受。如果我一週產出了一千行正式環境的程式碼，我很容易指著它說這就是我做出來的東西。但如果我花了同樣一週去研究某個微妙的失敗模式，最後加上一個很小的檢查來防止它，表面上的產出看起來就小得多。然而經濟價值可能大得多。
系統已經知道怎麼生成。更困難的問題是，我們能不能信任它生成的東西。
我還不確定這個角色最後應該叫什麼。AI 工程師仍然適合。可靠性工程師涵蓋其中一部分。架構師又涵蓋另一部分。評估工程顯然正變得越來越重要。這些標籤都無法完全捕捉我正在經歷的轉變。
我確實知道的是，我正逐漸遠離「主要負責產出實作的人」這個角色。我正在變成那個先問：在我們信任它之前，這個實作必須證明什麼的人。
這種感覺很奇怪，因為軟體工程一直訓練我們把自己認同為建造者。程式碼是工藝、是產出、也是證明我們有用的證據。AI 正讓程式碼變得充裕，而當某件事變得充裕時，價值通常會移到別的地方。
也許軟體工程下一個稀缺的資源不是實作。也許是能夠在現實替你發現之前，先判定某個實作何時出錯的能力。
越來越便宜的部分，正在被生成出來。更昂貴的部分，是知道它會在哪裡失敗，並確保它不會失敗。
人類概念，AI 寫得真好。
原文出處：https://dev.to/marcosomma/i-write-less-code-than-i-used-to-that-may-be-the-point-3kk
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
