作者 | Rachel Laycock

大約兩個月前，我成為了Thoughtworks的首席技術官。在那之前，我一直領導Thoughtworks的現代化平臺和云服務，而數字化轉型的基礎就是現代化已經存在于系統內部的軟件。領導團隊跟我說：“嘿，你即將成為Thoughtworks的首席技術官。祝你好運。在未來的10年、20年里，最具顛覆性的技術即將擺在你面前，你需要關注它?！?我在這個行業已經有20年了，無數次看到一些技術達到炒作周期的高峰，元宇宙、區塊鏈、移動技術，任何你所能想到的，它們的確改變了很多東西。

但對我來說，這一次的不同之處在于，AI 對于Thoughtworks的業務模式多么具有顛覆性。我們通過技術來解決客戶的問題，而使Thoughtworks如此偉大的秘密武器是我們交付軟件的方式。我們使用的原則、方法以及我們關于持續交付和微服務的書籍都源于我們構建軟件的方法。所以當一項技術出現并聲稱：“嘿，我可以寫代碼，你不再需要人了。”作為首席技術官，我需要警覺并迅速制定技術戰略，這影響著我們向客戶交付軟件的方式以及我們所要提供的建議。

編碼并不是軟件的全部

世界上每家咨詢公司、每家軟件開發公司都雇傭著數百名專注于這個領域的人，因為我們都在互相競爭。我很快意識到，每個人的談論都集中在編碼部分。但我在想，等等，這里好像不對勁。交付軟件遠不止編碼。

多年來，我一直在強調，當人們關注代碼時，他們認為構建軟件就是坐在電腦前，面對IDE編寫代碼，這似乎就是全部內容。這也是為什么Thoughtworks多年來一直在使用極限編程實踐包括結對編程。多年來，我們的客戶一直在問，為什么我要支付兩名開發人員的工資來編寫相同的代碼？這很昂貴。我們不得不做很多解釋工作，實際上這是一個巨大的錯誤假設，因為這項工作是有設計部分的。同時由兩個大腦來開發代碼，提出的設計方案最終會交付更高質量的代碼，更少的缺陷和更低的成本。

技術的快速變遷需要重新構建軟件

但真正的問題是，編碼并不是全部工作。軟件在不斷變化。正如我所說，我曾經負責現代化平臺和云服務。我認為世界上大約有20%或更少的軟件是在云上運行的，畢竟其中許多軟件已經存在了很長時間，遷移起來并不容易。現代化是非常昂貴的，因為你并不能簡單地重寫這些軟件。

說到底，你閱讀代碼的次數要比你編寫代碼的次數多得多。大約20年前，我大學畢業后的第一份工作被稱為系統分析師。那是他們稱呼畢業生的方式，這份工作的實質就是修復錯誤和缺陷，這被看作是讓我們了解代碼庫的一種方式。但我學到的是，編寫代碼的錯誤方式和壞的代碼風格要比正確方式和好的代碼風格多得多。這激發了我的興趣，想知道如何編寫良好的代碼，使其易于維護，并允許在未來繼續發展業務，而不會受到代碼的束縛。因為構建軟件不僅僅是關于能多快地構建軟件，更是關于是否首次就構建了正確的軟件。我們都聽說過技術債這個詞，技術債越多，改變軟件就越困難。

那么我們該怎么辦？我們重新構建它。你的組織中有多少系統已經被重新構建過？很多，對吧？否則世界上就不會有成千上萬的技術顧問和開發人員不斷地重建和重寫軟件。有時這是因為它最初編寫得很糟糕，或者它使用了無法遷移到云的技術棧編寫的。但有時是因為你的業務正在變化，你需要新的產品和新的軟件。技術就在我們腳下不斷變化。

我們一直在借用建筑領域的術語。我的兄弟是一個真正的建筑師，他建造真正的建筑物。當他們在建筑方面做決策時，如果做得正確，它們可以立足百年。而軟件卻與此完全不同，它是一個不斷變化的領域。因為你不斷重建代碼，而成功與否取決于代碼的狀態、最初編寫時的質量，以及不斷變化的業務環境。

關注Thoughtworks的人都知道，我們在過去的10多年中一直在編寫技術雷達。雷達的隱喻體現了我們應該關注什么技術、平臺、技巧和工具。它是由我們的前任首席技術官出于內部組織的目的而創建的，而伴隨著人員的增長，跟蹤所有這些變化變得非常困難，所以她創辦了一個技術咨詢委員會來幫助她理解這一切。

你會注意到每六個月就會有新技術、新平臺、新技巧出現。事實上，上一份技術雷達是在上周開始制作的，通常會在一個月左右發布?？紤]到目前基于大語言模型和生成式AI的工具太多，我們不得不單獨評估它們。與其逐個評估，我們甚至不得不把它們全部放在一起來進行相對評估。這就像一個已經非常瘋狂的領域，我們正在處理的復雜性令人難以置信。

生成式 AI 成為新的編碼伙伴

讓我們回到閱讀代碼比編寫代碼更多的話題，回到結對編程以及我們使用這些方法的原因上。

這是Jean Bartik。她是最早的程序員之一。你們可能不知道，在編程的歷史上，大多數最早的程序員實際上是女性。她說她們當時總是成對編寫代碼，因為她們發現這樣可以相互檢查對方的設計，提出批評意見和更多的想法。我認為這就是生成式AI最令人興奮的事情之一，因為它也可以做。

在編寫代碼時，你要把它視為合作伙伴，因為軟件工程實踐真的很重要。如果你不合作或不進行代碼審查，或者不花時間進行設計，而只是繼續重寫，繼續修復錯誤，你會遇到更多的麻煩。

我們調查了許多主要客戶，并將我們與他們的內部軟件開發人員以及供應商進行了比較，盡管他們可以更快地推出產品，但這其中也有更多的缺陷、更多的錯誤、更多的問題、更多的重復工作。

這就是為什么在開發過程的早期你就要仔細地考慮設計的想法。因為最終，當我們到達部署階段，如果能夠持續地部署而沒有問題或者問題較少時，我們的成本就會更低。你必須能夠全面看待整個開發周期，因為這不僅僅關于編寫代碼。其實我沒有告訴你任何新東西，這些事情早已存在，我們整個行業只是不斷地重建軟件。

因此，只是考慮生成式AI如何幫助你更快地編寫代碼，是非常狹隘的。你需要思考整個交付周期，以及生成式 AI 如何成為整個交付周期的一部分。這樣，你就可以獲得可以工作的、高質量的軟件。否則，你只能在小范圍內獲得好處。

生成式 AI 幫助改進軟件流程

一份來自Github的研究表明，人們實際上坐下來編寫代碼的部分在日常工作中只占26%到27%。所以我們知道開發軟件遠不止于此。

關于生成式 AI，我們學到的另一件有趣的事情是，即使它可以讓人們更快地完成開發軟件或刪除代碼等許多重復任務，好處實際上只存在于中級工程師及以上的級別。因為說到底，它不是Google，它不會給你答案。它只會提供以前已經做過的事情的模式。如果你不是高級工程師，你無法判斷得到的信息是真是假，這樣反而會減慢開發的速度，接收了太多的選擇和太多想法，卻不知道哪一個是正確的。

所以當我們思考如何將生成式AI應用于構建軟件時，它并不是為了讓開發人員更快，而是為了改進整個流程。這將帶來很多機會，因為生成式AI可以在軟件開發生命周期中為你的人員提供很多幫助。接下來我會快速地介紹一下。

我們擁有的大語言模型在不斷變化，目前它在哪些方面表現良好呢。讓我們從簡單的模式匹配開始。它可以接受自然語言，比如“為我做一些計算”，然后它可以生成代碼，對于重復性的任務來說，完成得也不錯。正如我前面所說，它對已經具有經驗的人來說是一個很好的伙伴。

因為我一直工作在現代化改造領域，而在現代化改造中，一個很大的問題是沒有人真正解決大型主機的問題。有多少人嘗試過現代化改造他們的主機系統，然后因為成本太高而放棄？人們通常只是重新編寫它，或者只是在它周圍包一些包裝器。

所以我們即將開始進行一些實驗，因為如果生成式 AI 可以將自然語言轉化為代碼，將代碼轉化為自然語言，那么也許它可以解決這個問題。我昨晚聽說IBM已經發布了一些東西，他們聲稱可以做到這一點，但我相信這只是個開始，這非常令人興奮。生成式 AI 還可以做一些瘋狂的怪事，比如用星球大戰的隱喻來解釋代碼，所以你可以玩得很開心。

20年前，你可能是一名Java工程師，或者是一名C#工程師。但現在情況不同了，尤其是作為在我們這樣行業的一名顧問，你需要學習Ruby、Python的各種概念，你要能在IDE內提供上下文。使用了 Copilot，它可以幫助你記起已經模糊的東西。在使用生成式 AI 之前，你必須去 Google 自己搜索答案。如果你有一個異常消息，作為一名初級開發人員，你會將它輸入到Google中，再放入Stack Overflow中尋找答案，最后選擇最受歡迎的那個答案。這樣做的好處是，如果你選擇了最受歡迎的答案，那么它可能只是一個好答案而已，但使用Copilot之類的工具，你可以獲得具備上下文的答案，從而加快你的工作流程。

使軟件交付變慢的原因之一是對瀑布方法的抱怨，即各階段的交接問題。在不同的階段之間，你只是在不斷地傳遞東西，有人提出需求或者是一個想法，然后依次進入代碼、測試、部署階段，哦，出現了問題，那我們把它全部回退吧。但這個問題可能發生在兩年后，早期的程序員已經離開了，因為他們只在組織里待了兩年。所以現在如果你是一個初級程序員，你看著這個問題，可能要花上三倍甚至四倍的時間來弄清楚發生了什么，以及如何解決它。但如果你創建這些想法、用戶需求、測試、部署的反饋循環越快，你就越能減少重復工作，并更快地實現你的目標。

所以你可以開始思考軟件開發生命周期的所有這些不同部分，讓生成式 AI 扮演其中某部分的不同角色，以及可以做的事情和工具。這聽起來真是既令人驚嘆，又令人恐懼，又令人興奮。

我們一直專注于構建、編寫好的軟件和代碼，即便有了生成式 AI，你仍然需要有好的方法和方法名稱，但 AI 可以為你生成文檔。想象一下，你離開兩周后回來了，代碼庫發生了什么變化？你讓 AI 給我一個總結，總結過去 190 次提交中代碼庫中的所有變化，它就可以幫助你來做一些研究和發現。

關于軟件架構和設計的一個難點是考慮到所有的跨功能問題，如安全性問題、可訪問性問題和性能問題。生成式 AI 可以告訴你，這里有大約 10 個問題，如果你是一位經驗豐富的軟件架構師，你就應該考慮并關注這些問題，你能辨別當前的情境下有 8 個問題與你無關，但剩下的2個問題很重要。但如果你不是一位經驗豐富的軟件架構師，如果你為解決這 10 個問題都修改了代碼，那么最終你將得到很難更改和使用的軟件。這就是為什么我會提到這一點，即人們的專業知識仍然如此關鍵。

實際上，作為技術領導者，我的擔憂之一是，我們如何培養員工的專業知識？有 AI 之前，當我一開始讀了某些人的代碼，我會想，這到底是怎么回事？這個人寫代碼時吸食了什么瘋狂的迷幻藥嗎？有了生成式 AI，這種情況就不太會發生了，它會告訴你它做了什么。它給你一些實現的選項，但如果你沒有經驗和專業知識來對這些選項做出判斷，那么可能會生成更多糟糕的軟件。這是我的預測之一，即在我們真正看到這項技術如何幫助創建更好的軟件之前，我們將首先生成更多糟糕的軟件。

在我早期評估所有 AI 這些不同技術及其對軟件生命周期的影響時，我發現一切都回歸到了現代軟件的核心原則。任何真正在構建現代軟件的人都知道，現代軟件的關鍵在于流程。它的關鍵在于從系統中消除浪費，并使開發和交付團隊進入流程狀態，以便盡快將最高質量的產品交付給客戶。

亞馬遜的新 CEO Andy Jassy創建了一個工程效率開發者體驗團隊，因為他認識到在軟件開發生命周期內存在很多浪費。生成式 AI 可以幫助減少某些浪費，比如查找一些信息。再次強調，AI 還可以幫助減少認知摩擦。它是否可以減少開發者體驗摩擦？可能吧。它是否可以減少運營模型的摩擦？可能不行。所以生成式 AI 還有很長的路要走。

但生成式 AI 可以消除許多流程中的障礙，這就是為什么你必須觀察整個軟件開發生命周期，包括思考我們如何培養未來的工程師成為優秀的工程師。因為我們大多數人都是通過從困難的事情中學習來取得進步的，這是人類不幸的真理之一。我們的父母學到了一個艱難的教訓，然后他們嘗試教給我們。但是，我并不聽你的，我要自己學習這個艱難的教訓。這幾乎是人類天性：從困難的事情中學到東西。那么在沒有機會學習困難的事情的情況下，我們如何培養出優秀的工程師呢？

因此，這將是我們必須解決的問題。正如我所說，生成式 AI 可以幫助解決很多問題，但也有一些問題它不能解決，我們作為領導者仍然需要關注這些問題，仍然需要思考如何使用精益原則以消除浪費，以使人們在他們的角色中能夠高效地發揮作用。

生成式 AI 會取代開發人員嗎？

生成式 AI 會取代開發人員嗎？我覺得不會很快，多年來與客戶合作的經驗告訴我，產品需求永遠不會減少，它總是會變得越來越大。我們想要越來越多的東西，我們需要完成的事情越來越多，技術領域不斷變化，我們總是試圖進行變革，這就是原因。

因此如果我們能夠讓團隊效率提高 20% 到 30%，或者未來可能是 50%，那會意味著我們會減少 20%、30% 甚至 50% 的人員嗎？不，我們可能只會將 20%、30% 或者 50% 的軟件添加到系統中。而且如果沒有對其進行嚴格審查，如果沒有工程師查看輸出，那么這些軟件可能會被編寫得更加糟糕。因此，這可能會導致更多的遺留代碼，制造混亂。

這就是我個人的預測，短期內，它可能會產生更多的挑戰和復雜性，但我們必須應對這一挑戰，找出讓事情變得更好的辦法。

我認為使用精益原則確實是正確的方法。當然，我也提醒了風險。但具體來說，在軟件交付生命周期內，風險通常只是一種幻覺。所以你必須從兩方面考慮它。最后，我想說的是，AI 可以讓你更快地編寫代碼，因為它消除了很多重復性任務，這的確很棒。但你必須考慮整個生命周期，以及它影響的不僅僅是編碼，而是真正高速生成的高質量的軟件。這些工程實踐更加重要。

但等等，我們未來還需要軟件嗎？

未來我們還需要軟件嗎？

這是我在思考的問題，因為作為一名領導者，我必須思考，如果在我們的系統中構建的軟件，特別是我們擁有的內部業務軟件，真的只是用于暴露和回答我們的問題，并添加新的信息，然后繼續暴露并回答問題。我們還需要多少新的軟件？我不知道。當然，這可能是明年或后年的一個話題。

但在短期內，我們可能會創建更多的軟件。因此，我認為重要的是在不被落下的同時，采取深思熟慮的方法。我可以保證，你組織中的每位軟件工程師都已經在使用生成式 AI。我還可以保證，侵犯知識產權的情況已經在發生。因此，了解整個軟件生命周期，知道如何治理這些問題，在未來幾年對于我們所有的技術領導者都將非常重要。