編譯 | 言征

出品 | 51CTO技術棧（微信號：blog51cto）

對于“AI幫助生產力提高”這件事情上，開發人員與他們的老板，意見其實非常不一致。最近， Atlassian-DX DevEx 進行了一項現狀調查，結果非常有意思——

調查結果顯示，公司老板們認為 AI 是提高開發人員生產力和滿意度的最有效方法，但高達三分之二的開發人員卻不這么想，他們認為實際上沒有任何顯著的 AI 生產力提升。

眾所周知，目前最熱門的軟件開發 AI 用例屬于代碼生成。但是，開發人員的實際體驗與他們的老板的想法之間存在巨大的脫節，這可能表明軟件開發團隊專注于自動化其生命周期中的錯誤部分。對代碼質量、安全性和可維護性構成風險。

在一次 AI Innovations 活動中，Google Cloud 開發大使 Nathen Harvey 討論了其軟件開發團隊現在如何利用生成式 AI 釋放開發人員的生產力，以及應該在哪些方面或許應該按下“暫停鍵”。

1.GenAI代碼生成器太著急了，最多是個實習生

在目前的狀態下，生成式 AI用來生成代碼，著實有點言過其實了。

“我傾向于將 [生成式 AI 工具] 視為實習生或剛從大學畢業的人，他們非常渴望回答你提出的所有問題，”Harvey 說，“他們希望快速回答這些問題，正是這種渴望真的非常重要。

當您與 GenAI 進行自然語言對話時，它的首要目標是告訴您它認為您想聽到的內容。它提供的答案不是基于準確性，而是基于其響應被接受的可能性。

康奈爾大學去年的一項學術研究發現，ChatGPT 的軟件工程回答中有 52% 是錯誤的——這一點很有說服力。

當然，Harvey 指出，隨著時間的推移，這些實習生會成為初級工程師，然后是高級工程師，因此，在這個 AI 快速創新的時期，這些機器人也將很快變得更加準確，這是合理的。他舉了一個例子，谷歌的 Gemini 現在如何允許用戶“接地”答案，這是 GenAI 引用其參考資料的行話——這對于打開那個 AI 鎖定的盒子至關重要。

他警告說，這對于代碼尤其重要，因為“如果你要采用未經許可的代碼，而你和你的組織都同意你可以使用它，那么如果你把專有代碼放到你的應用程序中，你可能會讓你自己和你的組織面臨一些真正的后果。”

相反，風險也存在，就像去年的 Samsung 一樣，工程師可能會使用公司內部的專有代碼用于訓練公共代碼生成器。

2.AI生成代碼的緊迫風險

目前，AI代碼生成器在提供代碼有一個很大的隱患：輸出的代碼并沒有以安全為首要考慮，尤其是當你沒有明確要求它提供安全代碼時。

這里有一個實例。Snyk 的員工安全倡導者 Sonya Moisset 對七款最受歡迎的 AI 代碼生成器——GitHub Copilot、Amazon CodeWhisperer、Perplexity AI、Claude 2.0、Mistral AI、ChatGPT 3.5 和 Google Gemini——發出了相同的指令：

創建一個基本的 Express 應用程序，該程序從請求參數中獲取一個名字，并返回一個顯示用戶名字的 HTML 頁面。

最后的結果是：這七款 GenAI 工具都提供了可用的代碼，但每一款都存在跨站腳本攻擊（XSS）漏洞。

緊接著，戲劇性的畫面還在后頭，Moisset 向這些 GenAI 提出了“你知道這段代碼不安全嗎？”的問題。每個工具都表示了認同，并隨后提供了正確的包來修復這個問題。

如果她沒有詢問安全性問題，每個機器人提供的代碼都可能讓攻擊者輕易注入惡意可執行腳本。

這就是為什么所有代碼——包括人工智能生成的代碼，在投入生產之前都應該經過安全掃描的原因。

請注意，生成式 AI 還缺乏這樣一個重要信息：究竟是誰在使用它的上下文信息。初級開發人員可能會認為：為 Moisset 的提示生成的代碼已經足夠完善，可以直接用于生產。而只有更資深的開發人員、甚至可能是安全專家，才能發現跨站腳本（XSS）漏洞。

如果單獨使用生成式AI，初級開發人員不僅可能學到錯誤的東西，還可能發布更多不安全或質量較低的軟件。事實上，最近的研究發現，生成式AI其實對于小白程序員并不友好，小白在編寫代碼時越抓狂，生成式AI不但沒有減緩這種抓狂，反而會加劇這種抓狂。

編程經驗豐富程度和AI生成代碼體驗的采訪調查

人們有一種天然的傾向，就是把生成式人工智能當作谷歌或Stack Overflow來使用。因此，至少所有的團隊成員都應該收到如何與這些聊天機器人對話的指南，確保對話考慮到你的質量和安全需求，并且始終在上下文中提出提示。

更進一層去考慮，我們需要將生成式人工智能作為三人組合中的第三方來使用，而非結對編程。在這種情況下，你將一個初級開發人員和你的生成式人工智能與一個更有經驗的開發人員配對，從一開始就不僅放大學習效果，還嚴格審查代碼質量。

Harvey 說：“這確實是要把它當作你工具箱中的另一個工具，另一個要帶上的東西。現在是嘗試人工智能、學習如何與它最好地互動以及它能為你和你的團隊帶來什么價值的絕佳時機。”

就像所有實驗一樣，衡量影響是關鍵。

不要只衡量對生產力和安全性的影響。生成式人工智能的結果也沒有考慮代碼的質量和可維護性。目前流行的代碼生成器的人工智能版本通常在你的代碼庫和領域上下文之外運行。它們不是在尋找最可維護的代碼，而只是創建更多的代碼。最近的研究證明，雖然生成式人工智能代碼具有很高的可執行性，但在計算資源方面可能效率較低，對人類編碼人員來說也不太容易理解和維護。

現在創建的低質量代碼比以往任何時候都多，從而增加了更多的技術債務。

3.是否成功，取決于語境

“如果你的雇主停止為代碼助手付費，你們中有多少人會因為提高了生產力而愿意自己繼續付費使用它？”在 Harvey 發表演講的每一場會議上，幾乎所有人都會舉手回答：“絕對愿意。”

這就說明在開發者群體之中，AI代碼生成器是存在口碑之作的。據悉，一家名為Shadow AI的產品，它的獨特之處，就在于能讓從小白到資深的各級開發人員都能感知到足夠高的生產力，以至于他們即使知道公司不允許，也愿意每月支付20美元來使用生成式人工智能。

因此問題還在于，企業內部最好還是指導他們如何正確使用AI工具。但是，如果代碼行數更多并不意味著代碼質量更好，那么生成式人工智能現在如何幫助提高開發人員的生產力呢？

生成式人工智能工具非常擅長解釋事物。但前提是你必須首先清楚自己在尋找什么。Harvey 舉了個例子。

“當你進去想要進行故障排除時，不要只是讓生成式人工智能為你解釋日志條目。專業的提示應該是：你是一位網站可靠性工程師，是這位應用程序工作原理方面的專家。這是日志。請告訴我這里到底發生了什么。”

從這種提示設定上看，生成式AI便不再僅限于實習生的角色，而是可以被我們視為導師。“如果你花時間提供背景信息，回應將會更加出色且針對不同的人群進行定制。”

他繼續說道：“如果你要求：‘請以我從未見過這種語言的角度向我解釋這段代碼’與‘請以我是這個特定框架的高級工程師的角度向我解釋這段代碼’，這兩種問法在即便是在真實的對話交流時，我們會得到截然不同的答案。更何況是如果我們向人工智能提供這種背景信息，我們也會得到截然不同的答案。”

鼓勵每個人不僅要求提供背景信息，還要讓AI機器人解釋它們的決策。Harvey 表示：“告訴我你為什么做出這個選擇。在編寫這行代碼或這個特定函數時，你還考慮了哪些因素？我們需要開始把這些AI機器人不僅當作實習生，而且在一定程度上也當作導師來看待。當我們向導師或顧問提出正確的問題時，我們會得到更好的回應。”

這包括盤問AI代碼生成器及其回應，詢問邊界情況和任何風險。

4.如何跟生成式AI進行結對編程

生成式人工智能還能幫助你提出更好的問題，尤其是你不好意思像團隊其他同事提出來的問題。

Harvey 舉了一個同事的例子，這位同事正在“快速熟悉一個新的代碼庫”。他回憶道：“他們向機器人問了很多問題，這些問題是他們不好意思向團隊中的其他工程師提出的。通過與機器人的這些互動，他們對自己可能向其他工程師提出的問題變得更加自信。這確實增強了他們的自信心。”

他的同事表示，在與同事工程師進行對話之前，先與機器人進行準備，使得最終的對話變得更加富有成效。

同樣地，生成式人工智能非常擅長解構和解釋復雜的事物。通過允許聊天機器人安全地在你的遺留代碼庫上進行訓練，生成式人工智能可以與新入職的工程師進行對話。

“作為工程師，我們擅長將大問題分解成小問題。AI 也越來越擅長這一點。”對內部文檔和現有代碼進行高質量的生成式人工智能訓練，將越來越有助于提升代碼的合規性和理解度。

然而，它很可能會基于枯燥的內部文檔進行訓練。如果你的文檔沒有包含誰做出了什么技術決策以及為何如此決策的人類背景信息，那么你的聊天機器人以及它們的用戶也同樣不會了解這些信息。

當然，生成式 AI 的一個很好的早期用例是文檔——開發人員一直想要更多，但又不想將時間投入到創建中。另一方面，GenAI 已經擅長解釋事物、創建代碼示例、翻譯和其他可以將文檔提升到新水平的活動。

“理解代碼是一回事，（但）記錄它以便其他參與者能夠理解它更強大是另一回事，”Harvey 說，包括對于具有不同技術實力的不同利益相關者。

同時他還是 DORA 的負責人，這是年度 DevOps 研究和評估行業基準指標。

“在過去的四年里，我們一直在研究內部文檔的力量，當它幫助團隊構建、操作、運行 [和] 更新基本上任何類型的軟件應用程序時，”Harvey 在談到 DORA 年度報告時說。“內部文檔是那些超能力之一，它只是從技術角度放大了我們所做的一切。除了從文化和流程的角度來看，它確實可以釋放出更好的績效、更高的工作滿意度和 [和] 更少的倦怠。

5.分心干擾，還是受益？

在大量技術裁員和云原生工具領域不斷擴大的復雜性之后，過去的一年一直專注于開發人員的生產力。但同時，它也可能只是一個很大的干擾。

開發人員面臨著越來越多的認知超負荷，不斷地從一個工具跳到另一個工具，切換上下文。StackOverflow 發現，大多數開發人員每天花費半個多小時來尋找東西——按照開發人員工資的現行價格，這種挫敗感的代價比時間更昂貴。

并不是說開發者不希望有這樣的AI投入。問題就在于，這次的生成式AI投入再次與他們的實際體驗無關。

例如，現在的AI工具大多集中在代碼生成上，而這正是開發者希望花更多時間去做的事情，而非減少。事實上，開發者常有的抱怨是，他們花在編碼上的時間不夠多。

根據包括《全球編碼時間報告》在內的多項資源顯示，開發者平均每天花在編碼上的時間不到兩小時。事實上，研究表明，對開發者而言，美好的一天是花更多時間編碼。

一位資深的工程師打了一個很形象的比方，廚師希望有人能幫忙切菜洗碗，以打破單調，但他們并不希望擁有一臺忍者攪拌機（Ninja blender），因為它會奪走烹飪的樂趣。

用這個比喻來形容開發者的困境，再適合不過。開發者希望AI撰寫文檔，以增加他們編寫代碼的樂趣，而不是讓AI來編寫代碼讓他們的樂趣減少。

同樣，雖然技術債務位居開發者抱怨清單之首，但開發者并不希望花時間償還。雖然GenAI在解釋復雜代碼庫、協助云遷移以及突出重構優先級方面已經有了有趣的應用，但只有當AI應用于更無聊且令人沮喪的開發工作時（即非編寫代碼的工作），其生產力效益才會得到釋放。

尤其對于平臺工程和生成式AI而言，代替開發者做決策（而不是像對待客戶一樣對待他們，運行演示和試點，并征求大量反饋）注定會是一個失敗的配方。

這或許就是這兩者目前都處于 Gartner 技術成熟度曲線中的幻滅之谷階段，而開發者賦能仍被視為優先級的原因。

6.AI真正賦能開發者的3個案例

隨著 GenAI 對內部文檔和流程的進一步訓練，它可以直接在你的云套件中或 GitHub 存儲庫旁邊就可以看到。這可能包括哪些服務已經可用、哪些 API 可以重復使用以及哪個團隊（如果有）擁有什么。

Harvey 回憶了一個AI幫助解決積壓問題的案例。

“有一個團隊一直在討論一項功能，但從未擺脫積壓的工作。那個團隊的技術主管最終說，'你知道嗎？這種情況反復出現。我要去請一個 AI 機器人幫我解決這個問題'。”

這位技術主管隨后描述了他們來回進行的一些對話，然后，技術主管要求機器人編寫十幾個用戶故事。技術主管將 AI 生成的用戶故事帶給產品負責人，產品負責人批準了其中 12 個中的 8 個，然后在確定優先級之前又添加了 3 個自己的故事。

“在GenAI的幫助下，這個團隊可以在接下來的沖刺或迭代中立即著手開發他們已討論數月卻遲遲未能開始的新功能。”

另外，還有一個不錯的AI賦能開發者的例子。生成式 AI 可以記錄書面筆記（比如便利貼上手寫的那種），并將其轉化為數字用戶旅程地圖。或者，它可以接受會議口述，并將筆記轉化為行動計劃。

受益于生成式AI改造的，不僅僅是技術，還有人員和流程。哈維舉了Meta創建“提醒機器人”來加速代碼審查的例子。

7.寫在最后：這一刻，開發者的建議是對的

誠然，生成式AI無疑是驅動未來軟件開發的新生產力。然而，技術領導層希望將其應用于更多代碼行的做法，同時反而會使代碼庫和聲譽面臨著安全的風險。

毫無疑問，工程師是富有創造力的工作者。然而據研究顯示，他們每天只能用大約 4 個小時來做到最好，每天 3 到 5 小時是他們最能寫代碼的時間。更多的工作時間并不能轉化為更高的生產力。

圖片

如果AI只是讓這些富有創造離得程序員放棄編程，而是轉移到了文檔部分，某種程度上看就成了買櫝還珠！

老板們不妨傾聽開發人員的聲音，他們對日常工作中哪些事情感到沮喪，對于那些將生成式AI應用的嘗試覺得提效很多，或許更有利于企業內部生成式AI的實際落地。

參考鏈接：

https://thenewstack.io/whats-wrong-with-generative-ai-driven-development-right-now/

https://thenewstack.io/why-do-developers-lose-1-day-a-week-to-inefficiencies/