我們恐怕只是把復(fù)雜的問題想得過于簡單。
軟件行業(yè)苦降本增效久已。蔓延開去的開發(fā)周期，遙遙無望的上線時(shí)間，以及不斷冒起的缺陷，怎么看都配不上這支精兵強(qiáng)將的隊(duì)伍。生成式 AI 似乎帶來了曙光，它的表現(xiàn)讓人耳目一新，不少人會(huì)這么想：生成式 AI 能自動(dòng)生成代碼，成本低，可重復(fù)，即拋的能力像云上的資源，這段代碼不合適的話扔掉好了，重新生成一段。這是不是意味著，不需要這么多精兵強(qiáng)將了？
生成式 AI 在回答我們的問題時(shí)，偶爾會(huì)拋出個(gè)煞有介事的答案，但如果你稍作檢索，就會(huì)發(fā)現(xiàn)這個(gè)答案徒有其表：不是查無此言，就是一派胡言，這與人工智能的威名不符。這即所謂生成式 AI 的幻覺，hallucination——因?yàn)闆]有真實(shí)可靠的語料，它自作主張拼湊了一個(gè)假的回答。
大模型技術(shù)仍然在不斷更新，能讓人感知到幻覺程度也在逐漸降低。但在它被投入到具體的領(lǐng)域和使用場景時(shí)，幻覺效應(yīng)仍在發(fā)生。在這篇文章里，我會(huì)分享下生成式 AI 在軟件開發(fā)領(lǐng)域的應(yīng)用，以及其帶來的三個(gè)幻覺。
01 幻覺一：更快的速度
不同的軟件工具廠商都在迭代更新自己的代碼助手產(chǎn)品，最著名的是 GitHub 的 Copilot,他們宣稱，可以加快程序員完成任務(wù)的速度達(dá) 55% 以上，那些清麗迅捷的演示視頻看起來也如飛一般。
但這是否意味著軟件的交付進(jìn)度可以加快 50%？
那些作為演示的代碼是可疑的，更多程序員在自己的項(xiàng)目中采用 Copilot 的反饋似乎也表明，提速基本只會(huì)出現(xiàn)在一些常用的功能實(shí)現(xiàn)上。比如數(shù)組的排序，數(shù)據(jù)結(jié)構(gòu)的初始化，或者是一些再簡單不過的模板代碼。
可重復(fù)的工具代碼交由 AI 也就罷了。但對(duì)于一個(gè)開發(fā)中的軟件而言，有多少類似的代碼需要重復(fù)開發(fā)呢？這恐怕值得討論。遑論多數(shù)時(shí)候，它們只需要一次成型，封裝待用。還有數(shù)量相當(dāng)可觀的業(yè)務(wù)代碼，程序員會(huì)以怎樣的速度來進(jìn)行？你可以把足夠數(shù)量的業(yè)務(wù)代碼交由 AI 來生成，但是否安全恐怕是一個(gè)更大的問題。
這里還有兩個(gè)問題值得關(guān)注。
一是程序員對(duì) AI 提供代碼的選擇。
AI 如此容易提供多套方法的實(shí)現(xiàn)，程序員難免要嘗試從中找出最優(yōu)的選項(xiàng)。
這個(gè)好？還是那個(gè)好？咦，竟然有五種不同的實(shí)現(xiàn)。需要先讀懂每一種代碼的實(shí)現(xiàn)，再切換到下一種。這個(gè)實(shí)現(xiàn)的方法很優(yōu)雅，但可惜單元測(cè)試失敗了。換下一個(gè)。
程序員的好奇心被代碼助手充分?jǐn)噭?dòng)。心猿意馬，線性的思維習(xí)慣碎落一地。程序員遺忘的不只是開發(fā)紀(jì)律，還有時(shí)間。
二是軟件自有生命周期。
很顯然，輪到程序員開始編寫代碼，很多事情已經(jīng)發(fā)生，而更多的事情還會(huì)繼續(xù)發(fā)生，直到系統(tǒng)上線。這些事情包括但不限于：收集需求，理解需求（從需求說明到用戶故事），測(cè)試，維護(hù)基礎(chǔ)設(shè)施，以及那些層出不窮的修復(fù)工作。
我的意思是說，即便 AI 幫助程序員寫得再快，這個(gè)階段也只是軟件生命周期中的一部分而已。早有相關(guān)的數(shù)據(jù)統(tǒng)計(jì)，程序員日常的工作，只有 30% 的時(shí)間是在編寫代碼，而更多的時(shí)間是在嘗試?yán)斫馑麄円獙?shí)現(xiàn)什么功能，以及設(shè)計(jì)和學(xué)習(xí)新技能上。
02 幻覺二：更少的 Bug
人編寫的代碼難免存在缺陷，這是軟件質(zhì)量的基本共識(shí)。而且似乎越有經(jīng)驗(yàn)的程序員，越容易生產(chǎn)出隱晦的問題，要過了很久才會(huì)被發(fā)覺。線上問題更讓人提心吊膽，但這樣的擔(dān)心很難避免。
AI 生成的代碼，聽起來也很高級(jí)，是不是會(huì)帶來足夠完美的結(jié)果？很可惜，答案可能會(huì)讓人失望。
生成式 AI 背后的大模型，以互聯(lián)網(wǎng)上大量的語料作為數(shù)據(jù)來源，盡管大模型技術(shù)一直在改善，但網(wǎng)絡(luò)上已經(jīng)現(xiàn)實(shí)存在的帶有偏見的數(shù)據(jù)量十分可觀。這也包括大量飽含缺陷的代碼。這意味著程序員在代碼助手中精挑細(xì)選的代碼，也可能存有缺陷。因?yàn)檫@段有缺陷的代碼，可能來自地球另一端的某個(gè)人，只是恰巧成為了地球這一端的選擇。
要命的是，生成式 AI 有放大器（amplify）的功效。簡單來說，就是如果程序員采用了存有缺陷的生成代碼，Copilot 會(huì)記錄這樣的行為，在接下來類似的場景，會(huì)繼續(xù)建議有缺陷或差不多的代碼。AI 并不能讀懂這樣的代碼，它只是被鼓勵(lì)繼續(xù)提供。我們可以預(yù)想最后的結(jié)果。
程序員要嚴(yán)守團(tuán)隊(duì)的開發(fā)紀(jì)律，保持統(tǒng)一的代碼規(guī)范，因?yàn)檫@樣別人才能讀懂，更容易發(fā)現(xiàn)潛在問題并修復(fù)它。但代碼助手提供的不同樣貌的代碼，似乎也提供了更多的混亂。
代碼有缺陷，只是軟件最后會(huì)爆出難以挽回的問題來源之一，甚至是很少的一部分。構(gòu)建軟件的過程，其實(shí)是知識(shí)生產(chǎn)和創(chuàng)造的過程。在軟件生命周期不同階段加入進(jìn)來的各角色，共同理解和分析軟件的需求，然后轉(zhuǎn)換其為代碼，也在團(tuán)隊(duì)和人員更替的過程中，傳遞這些表面為需求和代碼實(shí)則為知識(shí)的信息。
但通常，知識(shí)會(huì)衰減，知識(shí)資產(chǎn)的傳遞會(huì)不可避免地出現(xiàn)差池。
比如，讀不懂代碼，無法持續(xù)更新文檔，整個(gè)團(tuán)隊(duì)又被替換，等等。這些才是軟件不斷產(chǎn)生 Bug 和問題的原因所在。人工智能并未能解決這些軟件工程中棘手的問題，至少現(xiàn)在看短時(shí)間內(nèi)做不到。
03 幻覺三：更少的人
AI 的代碼助手看起來確實(shí)像見多識(shí)廣的程序員。甚至有人愿意把它當(dāng)成結(jié)對(duì)編程實(shí)踐的伙伴。用人成本一直是 IT 團(tuán)隊(duì)頭疼的問題，好手太貴，合適的人招不到，從頭去培養(yǎng)熟練的程序員又需要太久時(shí)間。有了人工智能和代碼助手的加持，是否意味著可以縮編快一半的人？
AI 和代碼助手不僅無法提供上述的速度快和質(zhì)量高保障外，也期待使用者要有足夠經(jīng)驗(yàn)的程序員才好，才能盡可發(fā)揮它該有的優(yōu)勢(shì)。這位有經(jīng)驗(yàn)的程序員，需要有能力判斷代碼的優(yōu)劣，判定對(duì)已有生產(chǎn)代碼的影響，還需要有精心調(diào)整提示詞的耐心和技巧。
在這篇文章里，作者講述了她在使用代碼助手時(shí)諸多要留意的問題，還有你能看到的她縝密的內(nèi)心戲。因?yàn)榇a助手帶來的不確定性，可能會(huì)引起兩類風(fēng)險(xiǎn)，一是影響到代碼的質(zhì)量，二是浪費(fèi)時(shí)間。這里其實(shí)顯示的是一位足夠資深的程序員的自省能力。
也只有這樣，代碼助手才可以心安理得扮演見多識(shí)廣的新手，而經(jīng)驗(yàn)程序員充當(dāng)守門員，她才是那個(gè)負(fù)責(zé)提交代碼的人。這樣說來，AI 改變的其實(shí)是編程體驗(yàn)。
（圖片來源：https://martinfowler.com/articles/exploring-gen-ai.html,作者把代碼助手想象成一個(gè)著急幫忙、固執(zhí)、說話清楚但缺乏經(jīng)驗(yàn)的角色，于是用 AI 畫出了這個(gè)卡通形象）
AI 和代碼助手在解決簡單重復(fù)性問題上，效果顯著。但在構(gòu)建軟件的過程中，有更多需要人和專業(yè)經(jīng)驗(yàn)的場景來解決復(fù)雜的問題。比如軟件系統(tǒng)日益增加的架構(gòu)復(fù)雜度和范圍，應(yīng)付市場和業(yè)務(wù)側(cè)的需求，跨角色之間的溝通和協(xié)作，還有那些更加時(shí)髦的涉及代碼倫理和安全的問題。
雖然判斷程序員是否足夠?qū)I(yè)和熟練，不像數(shù)數(shù)那樣一目了然，但我們也可以說，引入 AI 和代碼助手然后減員開發(fā)團(tuán)隊(duì)，能帶來的成效是不確定的，目前看弊大于利。
04 寫在最后
生成式 AI 的本質(zhì)是模式轉(zhuǎn)換，從文字的一種形式，轉(zhuǎn)換成另一種形式，高級(jí)的代碼助手的能力也不出其右。如果把涉足軟件構(gòu)建的 AI 代碼助手，認(rèn)為是解決諸多軟件工程難題的妙方，我們恐怕只是把復(fù)雜的問題想得過于簡單。
寫到這里，我們一直在談什么呢？
我們其實(shí)在談的是，在軟件開發(fā)上投資 AI 的成效該如何衡量。投資 AI 并不是簡單如購買代碼助手的 License,然后就可以坐享降本增效。不斷詢問“我們要如何衡量投資 AI 和代碼助手的效果？”，不如詢問“我們到底要衡量什么？”。從 DORA 定義的四個(gè)關(guān)鍵指標(biāo)開始，是個(gè)明智的選擇，它們是變更前置時(shí)間、部署頻率、平均恢復(fù)時(shí)間 （MTTR） 和變更失敗率。
以下幾條基本衡量原則供參考：
衡量團(tuán)隊(duì)效率，而不是個(gè)人績效。
衡量成效而不是產(chǎn)出。
查看隨時(shí)間推移的趨勢(shì)，而不是比較不同團(tuán)隊(duì)的絕對(duì)值。
用儀表板上的數(shù)據(jù)開啟對(duì)話，而不是就此結(jié)束。
衡量有用的東西，而不是容易衡量的東西。
本文來源：36氪
文章轉(zhuǎn)載于其他網(wǎng)絡(luò)，如有侵權(quán)請(qǐng)聯(lián)系我們及時(shí)刪除！
