(聚會中的人名皆為化名)
我參加過一場工程師聚會,大家聊到後來,話題轉到了人類看懂程式碼的速度跟不上 AI。
工程師阿哲說,團隊裡不只一個人在用 AI 加速,大家來不及審查彼此寫的東西,程式碼越長越大。
審查是工程師互相檢查程式碼的步驟,英文叫 review,就是除了負責寫程式的本人以外,還要有別人讀過、看懂,按下同意,改動才會合進主程式。
在資安公司任職的工程師宗翰說,團隊也遇到一樣的狀況。
宗翰要求每次送出的改動不能太大。
改動送給人看之前,還會先讓好幾個 AI 交叉檢查一輪。
不過宗翰也坦白說,照 AI 產出的速度,人類很難趕得上,所以就算有這兩道檢查,有時候心裡還是不太踏實。
程式還在跑,團隊卻可能欠下認知負債
在 Google、Amazon 任職過的資深工程師 Maddy Zhang 提醒過一個現象。
工程師如果把寫程式的決定一個個交給 AI,按下同意的雖然還是自己,卻可能已經說不出這段程式碼為什麼這樣寫。
程式碼一包一包合進去,可能就像囫圇吞棗,整顆吞下,沒有人真的嚼過。
軟體工程師 Addy Osmani 把這個現象稱為認知負債。
意思是 AI 寫程式的速度一旦超過人類看懂的速度,團隊對自己系統的理解,就可能一點一點流失。
認知負債跟技術債不一樣。
技術債欠的是程式本身,為了趕時間先用比較粗糙的寫法,之後要回頭補。
認知負債欠的是團隊對程式碼的理解,程式還在跑,但能說清楚它為什麼長這樣的人卻越來越少。
我自己是工程師,想到團隊欠下認知負債,我會有點沒有安全感。
以前系統出問題,我打開系統執行時留下的紀錄 log,看一看心裡馬上就有底氣,因為我知道程式碼寫了什麼。
如果完全不知道程式碼寫了什麼,我可能連那份底氣都沒有。
系統正式開放給使用者用之後,面對的不只是照規矩使用的人,也可能有存心搞破壞的人。
當初做產品時,想像的那條順順走完的使用路線,使用者未必會照著走。
如果團隊看得懂的程式碼越來越少,使用者走到沒人想過的地方時,團隊反應的速度也可能跟著變慢。
不是每一行都要看懂
話說回來,我不認為解法是要求每位工程師把 AI 寫的每一行都看懂。
照現在的趨勢,團隊可以不用每一行程式碼都看懂,但要另外補上相對應的做法,例如先分出哪些地方影響最大,再把每次交給人看的改動切小。
我自己審查 AI 寫的程式碼,會先看這段程式碼影響有多大,再決定怎麼看。舉幾個例子。
- 個人官網這類出錯影響不大的,我都交給 AI 做,不一定會看程式碼。
- 影響中等的功能,我會看自動測試有沒有寫對,自動測試就是讓電腦自動確認功能正常的程式,然後我也會看應該測試的場景有沒有都寫進去。
- 對公司影響很大的功能,像資訊安全,或是付款、退款這類跟錢有關的金流,測試和程式碼我都會看。
Maddy Zhang 的分法也很接近。
樣板程式碼這種每個專案都長得差不多、照格式填就好的部分,還有測試和文件,Maddy Zhang 願意交給 AI。
Maddy Zhang 會自己緊緊握著的,是核心的商業邏輯,例如折扣怎麼算、訂單什麼時候成立,還有資料要怎麼分類存放的設計,以及跟安全相關的部分。
對帶領工程師團隊的技術主管來說,審查的力氣可以重新分配。
與其平均分給每一個改動,我會建議集中在資訊安全、金流這類影響最大的地方。
把改動切小,一次只疊一塊積木
光分風險還不夠。
如果一包改動大到看不完,再重要的地方也可能被漏掉。
我寫程式用的是疊積木的方式。
一次只請 AI 做一個小功能,做完看過、合進主程式,再做下一個,所以每一次要看的量都不大。
Maddy Zhang 也建議,一次只請 AI 做一件兩分鐘內就驗證得完的事。
Maddy Zhang 的理由是,早期一個小小的錯誤假設,會影響後面每一個決定。
改動越大,錯誤可能像利滾利一樣越滾越大。
最後可能產出一段讀起來很乾淨的程式碼,快速掃過看不出問題,卻只在某些特殊情況下出錯。
聚會上的宗翰要求改動不能太大,理由也一樣,改動太大,人就很難看完。
改動小,人比較有機會真的看懂。
改動一大,審查就容易只剩蓋章。
先決定哪裡要有人看懂,改動要切多小
AI 讓寫程式的速度快了很多,但人類看懂程式碼的速度沒有跟著變快。
我會建議團隊先決定兩件事,哪些地方需要有人看懂,以及每次交給人看的量要切多小。
如果你帶的團隊也在用 AI 加速,可以先問自己一個問題。
團隊裡最重要的那段程式碼,如果明天要改,能多快確認改完之後不會影響客戶?
參考資料