(文中人名皆為化名)
我在一場社群聚會上,有一位非技術背景的講者小安,分享自己最近在公司用 AI 寫程式的感想。
小安只花了大約兩週,就拿到公司的權限,可以把自己和 AI 寫好的程式,直接併進公司網站的程式裡。
小安能這麼快拿到權限是因為小安的主管很支持。
主管本人不是技術出身,當時公司負責寫程式、維護系統的工程師也只剩一位,就是小林。
主管放權限給小安的時候說,錯了再改回來就好。
小林從要開權限的那一刻起,就如履薄冰,因為權限一開,什麼都碰得到。
小林平時很少說什麼,只有在要再開放權限給小安時,會出來確認一次,確認完還是讓權限開下去。
小林的心情從擔心、抗拒,慢慢變成只能放手。
從我的角度來看,小安的主管想讓團隊跑快一點,小林在意的則是使用者正在用的功能能不能一直穩穩地跑。
讓人放心的,是每次都會發生的檢查
我自己是工程師,如果主管要我開權限給同事,我大概也會像小林一樣,默默地開,然後默默地擔心。
小安後來特地去問了小林,怎麼看待主管要開權限讓小安用 AI 改程式這件事。
小林擔心非技術背景的同事,比較難判斷 AI 寫得對不對,也很難對 AI 的答案提出質疑。
小安也同意,要能質疑 AI,得先知道同一個功能還有哪些做法可以比較。
小林也擔心 AI 寫出來的程式跟公司原本的寫法對不起來,例如命名方式不一樣,能跑歸能跑,以後還是得找時間回頭整理。
偏偏公司只有小林一個工程師,AI 寫程式的速度又快,小林沒有辦法一行一行看過其他人的每次改動。
如果主管在開權限前,先問清楚小林擔心什麼,問題就解決了嗎?
還不夠。
就算當天把所有擔心都回答完,未來每次改動上線前,也就是放到使用者正在用的網站之前,還是沒有東西確保這次改動被檢查過。
從我的角度來看,小林真正在意的不是哪一個具體的擔心,而是背後信任的問題。
如果是我,不用親自看過每次改動,但要確定每次改動都會經過該有的檢查,才放得下心。
這裡說的檢查是每次改動都繞不過去的關卡們,沒通過就上不了線。
例如每次改完就自動跑一輪的測試,也就是用程式自動確認功能還正常。
也可以是把系統設定成改程式的人不能自己核准,要另一個人照著清單逐項對過、按下核准,改動才上得了線。
上線前的檢查,可以從清單和自動測試開始
錯了確實可以改回來,但如果上線前先檢查,出錯的改動比較有機會在使用者碰到之前就被發現。
要動到正式系統,也就是使用者和同事每天在用的網站和系統,我會建議先把自動測試、核准這些上線前的檢查架好,再開權限。
小安開始用 AI 改程式時,小林寫了一份上線前的檢查清單,小安直接拿來用,真的抓出一些小問題。
小林的檢查清單得有人拿出來逐項對照才有用,算是起步的做法。
我接手的一個網站,每次改完、上線之前,都會自動跑一輪測試,確認畫面和功能還正常。
程式彼此牽連,改了這裡,可能弄壞那裡,所以連這次沒動到的地方也要一起檢查。
上線前的檢查寫進每次上線都會走的流程,比靠人記得去做更不容易漏掉。
做 AI 模型的公司 Anthropic,大約 80% 的程式是 AI 寫的,但也替 AI 設了檢查。
負責查問題的 AI 只能讀紀錄、寫報告、在公司頻道發言,修好的程式不能自己放上正式系統,要交給另一套由 AI 和人類一起把關的審查流程。
該檢查哪些地方,主管、同事和工程師可以一起討論,例如大家最怕哪裡出錯。
實際把檢查架起來,通常是工程團隊在做。
至於要花多少成本,每間公司的狀況不同,檢查多半也是一邊使用系統一邊慢慢補齊,不用一開始就做到完整。
把信任放在檢查上
說實話,我自己到現在還沒有遇過原本不寫程式的同事要直接改正式系統的情況。
但我相信不寫程式的同事也能改正式系統,只是信任要盡量放在每次都會執行的檢查上,不只放在人身上。
有了這些檢查關卡,想用 AI 改程式的同事比較能放手去做,工程師少一點擔心,主管也更能安心讓團隊加速。
假如你也希望團隊用 AI 跑快一點,同時把風險降低,可以先想一個問題。
權限開下去之後,如果哪裡出了錯,會先在上線前被發現,還是由客戶先發現?
參考資料