手工軟件工程師的時代已經結束！一位連續創業CTO的判斷

作者 | Michael Redlich

譯者 | 劉雅夢

策劃 | 丁曉昀

生成式 AI 正在改變軟件工程的基本形態。代碼生成能力變得越來越普遍，單純依賴“寫代碼”的工程師價值正在被重新定義。在這期 InfoQ 播客訪談中，連續創業者、Tessi.ai CTO Ben Greene 分享了他對工程師未來角色的判斷：手工軟件工程師的時代已經過去了，工程師需要把精力從單純編碼轉向理解問題、設計系統以及連接真實業務場景。

他認為，未來工程師最重要的能力不再只是技術深度，而是系統思維、業務理解以及與人協作的能力。同時，一種新的能力模型正在出現——工程師需要學會“AI 編排”，讓多個 AI 工具與系統協同工作，而不是親自完成所有代碼。與此同時，在自動化越來越強的技術世界里，人類的同理心、溝通能力和對真實問題的理解，反而會變得更加重要。

換句話說，未來最有價值的工程師，不是寫代碼最快的人，而是能夠理解復雜系統、協調 AI 與人類協作、并真正解決現實問題的人。

InfoQ 對訪談進行了翻譯并經過不改變原意的編輯，以饗讀者，以下為翻譯全文：

Shane Hastie：大家好，我是 Shane Hastie，這里是 InfoQ 工程文化播客。今天，我將采訪 Ben Greene。Ben，歡迎。感謝你今天抽出時間來接受我們的采訪。

Ben Greene：謝謝你邀請我，Shane。很高興來到這里。

Shane Hastie：我通常的開場白是，誰是 Ben？

Ben Greene：好問題。我也還在試圖弄清楚。我曾多次在創業公司擔任 CTO，目前正在創辦一家名為Tessi.ai的新公司。我們利用結合地理空間影像的 AI 技術，幫助人們在自然災害發生后更快地修復和重建家園。

我也聯合創辦過其他幾家公司。上一家叫Outcomes4Me，是一家面向消費者的健康科技公司，目前正在進行 B 輪融資。

此外，我還在Techstars Boston擔任過幾年的 CTO，也做過一些創業和技術方面的導師工作。不過現在，Tessi 是我全職投入的新項目。

Shane Hastie：是什么讓你成為一個連續創業的首席技術官？

Ben Greene：我一直很喜歡解決問題。那些規模大、復雜甚至有點嚇人的問題，反而特別吸引我。我會反復思考這些問題，然后想辦法把它們解決。

在這個過程中，我逐漸意識到一件事：如果只看到解決方案的一部分，是遠遠不夠的。你必須能夠看到整體。

因為當你構建一個解決方案時，你希望它能夠持續運行、不斷成長，并最終不依賴于你個人。你不希望自己成為那個必須一直在機器旁邊搖動手柄的人，而是希望即使你離開了，這個系統仍然能夠繼續運轉。

某種程度上，這也是我選擇通過科技創業來解決問題的原因。

不過我自己其實也是個挺急性子的人。正因為這樣，我反而被初創公司這種環境所吸引——它們某種程度上“獎勵耐心”。在創業公司里，你永遠覺得自己進度不夠快，無論已經做了多少事情、走了多遠，總感覺還有很多要追趕。

這種節奏其實很符合我的性格。雖然有時壓力不小，但我很享受這種狀態：總有事情要做，而且通常沒有太多繁瑣的流程。

1 “手工軟件工程師”的時代已經過去了

Shane Hastie：對于那些考慮進入初創公司環境的工程師，你有什么建議？

Ben Greene：從來沒有比現在更好的時機了，這太有趣了。作為工程師，我認為“手工軟件工程師”的時代已經過去了。生成式 AI 可以極大地提升生產力，遠遠超出很多人的想象——前提是你愿意真正去擁抱它。

某種程度上，這是一種類似于管理他人的能力：你需要學會把問題委派出去。很多優秀的工程師其實不太擅長委派任務，因為他們會擔心：如果自己還沒有完全弄清楚如何完成某件事，就把任務交給別人，結果可能達不到自己心中的標準。

但這是工程師需要克服的一點。你必須學會在不完美的工程條件下工作和管理。所以從工程的角度來看，我認為這是一個偉大的時代。

不過還有一點同樣重要：工程師需要意識到，自己不僅僅是在寫代碼。你不僅僅是在用 0 和 1、用各種功能模塊來構建系統。很多時候，你其實是在構建一個業務系統。即使是在非營利組織中，本質上也仍然是在構建一個有輸入、有輸出的系統。

如果你不去思考你構建的東西如何為這個系統創造價值，又如何受到這個系統的影響——那么你很難真正構建出一個可持續的系統。

Shane Hastie：

典型的軟件工程師往往不太關心整體格局或人與人之間的關系。之前我們聊天時，你說過一句話：“把規格說明從門縫塞進來，再給我點披薩就行。”聽起來這種工作方式現在可能已經行不通了。

Ben Greene：

是的，我認為那樣的時代已經過去了。

如今，如果軟件工程師想真正具備價值，就必須理解自己所交付的更大的成果和目標是什么。

隨著生成式 AI 的發展，設計師、產品經理、銷售人員以及團隊中的其他角色，都開始可以借助 AI 直接接觸甚至編寫代碼。如果一名軟件工程師不主動擴大自己的視野，只局限于代碼層面，那么他的能力就會顯得相對單一。

當然，目前像Claude Code這樣的工具在高層次工程思考方面還不算特別強，但它們一定會不斷進步。而當這種情況發生時，工程師真正的價值在于：不僅知道如何最大限度地利用這些工具，還能夠指出它們沒有考慮到的問題，并從更高層次去思考整個系統。

現在，當我思考“系統”時，我考慮的已經不僅僅是軟件本身，還包括我周圍的人——不僅是和我一起工作的同事，也包括合作伙伴和客戶。

我依然在解決問題，也依然在構建系統。只是現在我使用的工具不再只有代碼、API 和各種托管服務。現在，我處理的是整個世界的模糊性。但從本質上來說，我仍然是在解決問題，而軟件依然是其中的一部分，只是不再是唯一的部分了。

2 抽象層繼續上升，但軟件本身正在“貶值”

Shane Hastie：

在過去幾十年里，我們一直在不斷增加新的抽象層。這次的變化只是又多了一層抽象，還是說出現了某種不同的變化？

Ben Greene：

我認為既可以說是增加了一層新的抽象，也可以說是某種意義上的“抽象層坍塌”。

從編程語言（PL）的角度來看，我們一直在做的一件事，其實就是把一種語言不斷翻譯成另一種語言。舉個例子，從瀏覽器中運行的語言，到最終變成處理器可以執行的指令，中間可能要經過很多次轉換。

具體有多少層，我其實也記不清了。也許是七八層，也可能是十幾層。但從更高的層面來看，其實已經沒有必要理解所有這些層次。

比如說，我并不了解V8 引擎，或者 Chrome 現在使用的其他引擎的內部細節，而且坦白說，我也不想了解。我只需要它能夠正常工作就行了。

我真正關心的是如何解決我正在面對的問題。尤其是在創業公司里，我們總是試圖站在巨人的肩膀上，在已有的技術基礎上繼續往前走。很多開源驅動的開發模式其實也是這樣。

如果現在我們做的事情，只是在描述層面構建系統，甚至不再直接寫代碼，而是用自然語言，比如英語來描述需求，那其實也沒有什么問題。

但從更宏觀的角度來看，這對軟件意味著一件事：僅僅依靠軟件本身，已經很難像過去那樣創造大量價值了。你必須與現實世界建立更緊密的聯系。因為簡單地移動比特、處理 0 和 1，已經不像過去那樣稀缺或獨特了。

Shane Hastie：

這么看來，軟件工程師的角色正在發生很大的變化。如果回顧大多數工程教育體系，其實并沒有為這種變化做好準備。

Ben Greene：

確實如此。最近出現了一個很有意思的趨勢：所謂的“前線部署工程師”（Frontline Deployment Engineer）。不知道你是否注意到，現在有不少公司開始招聘工程師，讓他們直接到客戶的辦公室工作。

這些工程師既是自己公司平臺的專家，同時也逐漸成為客戶系統和業務問題的專家。他們會直接嵌入到客戶的環境中，與客戶團隊一起工作。

我其實很喜歡這種模式，因為這是學習如何把技術真正應用到實際問題中的最好方式——你就坐在那些正在面對問題的人身邊。

其實，多年來我們一直在這樣建議產品經理：不要只通過訪談了解用戶，而是要真正走進他們的辦公室，觀察他們如何工作，觀察他們是如何與你的產品互動的。

而現在，我們開始讓工程師也這樣做。我很喜歡這種變化，因為工程師應該停止那種“我只是坐在鍵盤前寫代碼”的思維方式。工程師也應該走出去，與人交流，理解他們正在面對的問題。

換句話說，同理心這種能力——也許過去很多軟件工程師并沒有真正去培養和使用——現在變得非常重要。而且說實話，我對這樣一個未來感到很興奮：一個人們愿意花更多時間去理解他人的世界。我認為這會是一個非常積極的變化。

Shane Hastie：

那我們應該如何在組織中培養這種文化呢？

Ben Greene：

我真希望自己有一個完美的答案，但說實話，我也還在不斷摸索。

不過有幾件事我覺得非常重要。首先，就是要經常談論你的客戶，并花時間與他們相處。僅僅坐在辦公桌后面是不夠的，你必須走出去，真正去看他們是如何工作的，甚至親自參與到他們的工作中。

同時，你也需要在公司內部建立一種共識：客戶所做的事情是重要的，客戶本身也是重要的人。

舉個例子，我們目前有一個合作伙伴，是一個在災害發生后參與救援工作的志愿者組織。他們所做的事情非常令人敬佩，說實話，要理解和認同他們的工作其實很容易。

但我認為，不管你的客戶是誰，你都需要意識到：在 B2B 軟件場景中，你可能只是銷售一個分析平臺，但在另一端，使用這個平臺的是一個具體的人，他們希望通過你的軟件獲得更好的業績，或者推動某個項目成功。

如果你不了解你的軟件將如何幫助他們在工作和職業發展中取得成功，那么你其實并沒有真正理解他們為什么會使用你的產品。因此，你需要在人的層面上去幫助他們，也需要從人的角度去思考問題。

對于消費者產品來說，這一點可能更容易理解。但即使是在企業軟件領域，人們同樣希望獲得成功、得到認可，甚至獲得晉升。他們的這些目標是合理的，而你的軟件也應該幫助他們實現這些目標。

Shane Hastie：

根據我的經驗，這種視角與大多數軟件工程師剛進入行業時的想法其實很不一樣。你之前也提到過產品經理、銷售人員等角色，現在似乎每個人都在“寫代碼”。

Ben Greene：

目前來說，還是要打個引號的“寫代碼”。

3 工程師真正的競爭優勢：系統思維

Shane Hastie：

那么在這樣的環境下，作為一名工程師，我應該如何體現自己的價值？工程師真正獨特的競爭優勢是什么？

Ben Greene：

我認為軟件工程師最大的優勢之一是系統思維能力。

比如在會議上，當有人提出一個新功能時，工程師往往會立刻想到各種可能出問題的地方，因為我們習慣去思考各種邊界情況和潛在風險。

這其實是一種非常寶貴的能力。坦白說，我們應該把這種能力從單純的軟件開發中帶出來，用在更廣泛的業務和組織系統中。

舉個簡單的例子：如果客戶打電話到呼叫中心，但雙方說的不是同一種語言，會發生什么？軟件工程師通常會很自然地想到這些問題。

我們可以幫助組織中的其他團隊，讓他們的流程和系統更加穩健，減少漏洞，提高整體可靠性。因為在構建系統這件事上，工程師擁有大量經驗。

當然，未來仍然會有很多復雜的問題需要工程師去解決，只不過這些問題會更加具有創新性。它們不會再是那些我們已經反復構建過無數次的標準 SaaS 功能。那些事情完全可以交給生成式 AI 去完成——說實話，這其實是一件好事，不是嗎？

我們真的還想繼續一遍又一遍地重復構建這些功能嗎？

不如把精力放在真正新的問題上：探索以前沒有人解決過的問題，把新的理論和新的思考方式帶入軟件工程領域，同時讓那些更常規的工作由自動化工具來完成。

Shane Hastie：

回到你作為連續創業 CTO 的經歷，當你創建一家新的創業公司時，你通常是如何設計組織文化的？

Ben Greene：

有幾件事情對我來說一直都很有效。

在設計組織結構時，我通常會參考一些基本原則。比如康威定律（Conway’s Law）：系統的結構往往會反映組織的結構。

所以我通常會從系統設計反推組織結構。我會先思考：我希望最終的系統是什么樣的？系統的接口應該在哪里？哪些部分需要能夠獨立擴展？哪些模塊可以保持松耦合，從而實現獨立發展？

在明確這些之后，我會嘗試把組織結構設計成能夠自然支持這種系統架構的形式。這是從結構層面來看。

而從文化和團隊協作的角度來看，我通常會先思考一件事：有哪些行為是我希望團隊成員能夠模仿的。因為在創業初期，我往往是工程團隊里的第一個人，我的行為會直接影響團隊成員之間的互動方式。

某種程度上，企業文化其實只是溝通方式長期積累的結果。文化本質上是人與人互動所形成的產物。

在我之前創辦的Outcomes4Me公司里，有一件事情我一直非常重視：代碼質量，尤其是代碼的可讀性。

這對我來說非常重要。因為當你從 0 到 1 創業、尋找產品市場契合（product-market fit）的過程中，你一定會不斷調整產品和系統。如果團隊成員無法理解代碼為什么這樣寫、當初是如何設計的，那么后續修改系統就會變得非常困難。久而久之，代碼庫里就會出現很多沒人敢碰的地方，人們只能繞著這些代碼走。

于是就會出現一種情況：當有人提出一個聽起來很簡單的功能需求時，你卻不得不說，“這個功能可能需要三個月時間”，因為你必須非常小心地繞開那些自己也不完全理解的代碼。

那么，如何避免這種情況？

在代碼評審時，我有一條非常明確的原則：在保證代碼正確的前提下，始終優先考慮閱讀代碼的人。

如果代碼評審者說：“我看不懂這段代碼”，那通常就說明代碼本身存在問題。此時就應該修改代碼，直到評審者能夠輕松理解它。

目標是在任何時候都盡量降低代碼的認知負擔。不過這里還有一個挑戰：工程師往往不太愿意承認自己看不懂某些東西。我們很多人都會受到“冒名頂替綜合癥”的影響，沒有人愿意顯得自己不夠聰明。

所以我在團隊里采取的一種做法是：主動示范這種行為。

我其實并不介意讓自己看起來有點傻。有時候我會直接說：“這個我沒聽懂。”而且很多時候我也確實是真的沒聽懂。

當團隊看到 CTO 也會坦然承認自己不理解某件事時，大家就會意識到：原來不懂某件事是可以接受的，請別人解釋也是正常的，甚至要求別人把事情講得更簡單一些也是合理的。

這種氛圍會逐漸形成一種文化：承認不懂是可以的，提問是被鼓勵的。

4 AI 時代的新工程師能力模型

Shane Hastie：

隨著初創公司不斷成長，你也需要引入新的工程師。最近我們經常聽到一種說法：剛畢業的工程師甚至很難找到工作。在這樣一個快速變化、不斷增加抽象層的行業中，我們應該如何幫助新人進入這個領域？

Ben Greene：

我認為首先需要改變的是：我們對工程師崗位的理解。

我現在招聘軟件工程師，并不是為了讓他們來寫代碼，而是為了讓他們參與構建產品和系統。

如果我招聘一位有 10 年經驗的工程師，而他希望加入團隊后負責把所有代碼都寫出來，那我可能不會錄用他。

相反，如果我在尋找的是一個能夠真正把事情做出來的人，而某個剛畢業的學生已經掌握了一種方法，可以利用 AI 智能體來協調其他智能體完成任務，那么我會非常愿意把他招進團隊。

當然，這樣的人其實并不多見。但如果有人已經找到了一種穩定的方法，能夠持續地產生可靠的結果，那么我們就必須認識到：這是一種新的技能。

未來我們真正需要尋找的能力，是AI 編排（AI orchestration），而不僅僅是寫代碼。

當然，對代碼本身的理解仍然非常重要。但在招聘時，我始終最看重的一點是：速度。

在創業公司里，我們通常并不完全確定自己要解決的問題是什么，也無法確定最終會使用哪些技術。

我當然希望能找到熟悉相關技術的人，但現實往往是：我們最終使用的，很可能是之前從未接觸過的新技術。

因此，我更希望找到這樣的人：他們喜歡學習，不害怕學習，而且會主動學習。我認為很多剛畢業的工程師，其實正好具備這樣的心態。

Shane Hastie：

在軟件工程領域，目前有沒有一些你認為大家還沒有充分意識到的重要趨勢？

Ben Greene：

我認為我們需要更清晰地討論一個問題：哪些問題適合用基于智能體的推理來解決，哪些問題仍然需要通過傳統代碼來實現。

現在有很多公司在銷售各種基于 AI 智能體推理的解決方案，它們往往宣稱系統可以達到95% 的可靠性。但在很多工程場景中，95% 的可靠性其實意味著徹底失敗。

我認為，在當前大家都在爭相采用生成式 AI、AI 推理和 AI 智能體的熱潮中，同時工程師也在努力理解這些新工具、保持自身價值的情況下，我們其實并沒有認真討論這些工具什么時候適合使用、什么時候不適合使用，以及如何負責任地使用它們。

也許其中一個原因是，我們往往不太愿意展開這種討論。市場營銷的聲音太多，很容易淹沒這些更理性的判斷。但我認為，工程師應該更多地參與到這種討論中來。

Shane Hastie：

對于處于職業生涯中期的專業人士，你有什么建議嗎？

Ben Greene：

我不確定自己是不是有什么特別有用的建議。某種程度上，我現在也正處在那個階段。

對我來說，我通常只是去尋找那些能夠真正讓我投入大量精力去追求的事情。很多時候，我更多是憑直覺做決定。

這在一定程度上也與創業有關。創業是一件非常艱難的事情，所以我總會問自己一個問題：我對這件事情是否有足夠的熱情，能夠支撐我投入幾年時間去做它？如果答案是肯定的，那我通常就會去嘗試。

我認為，如果你能夠找到自己真正想投入其中的事情，你就會擁有足夠的動力去克服過程中遇到的各種問題。

從更大的角度來看，軟件工程本身其實是一門創造性的學科。我們實際上是在從無到有地創造新的能力、新的可能性，甚至新的“世界”。因此，我們需要保持這樣的想法：不斷思考如何把這些技能應用到全新的領域和問題中。

如果有一天我再也不用寫 CSS 或 HTML 了，我一點也不會難過，這對我來說并不重要。但一想到我們可以構建更好的解決方案，讓更多人能夠用得起以前難以負擔的技術，幫助他們更高效地工作，甚至改善他們的生活，這些事情會讓我非常興奮。

所以，找到真正讓你有熱情的事情，并持續投入其中。其他很多事情，往往也會隨之慢慢展開。

Shane Hastie：還有什么重要的問題是我沒有問到，但你希望傳達給聽眾的？

Ben Greene：

我覺得，從技術發展以及社會變化的方式來看，有一點非常值得我們重視：人與人之間的溝通能力需要被放在更重要的位置。

技術和社會其實是緊密交織在一起發展的。因此，我們需要更加重視人與人之間的互動，以及與他人協作所需要的各種能力。人與人之間的交流非常重要。同時，我們也需要學會如何與 AI 有效溝通，以及如何通過代碼與計算機溝通。

這三種溝通方式——人與人、人與 AI、人與計算機——雖然形式不同，但都同樣重要。

因為從某種意義上說，我們每個人都只是一個更大系統中的一部分，而系統中各個“節點”之間能否有效溝通，往往決定了整個系統的運行效果。

如果我們回頭看看技術的發展，就會發現：計算機與計算機之間的溝通會越來越高效。

但在社會層面，真正的薄弱環節反而是人與人之間的溝通。所以，我們需要認真對待這一點，并努力去改善它。

Shane Hastie：

那我們應該從哪里開始？

Ben Greene：

我認為答案其實很簡單：從同理心開始。也就是試著去理解坐在桌子另一邊的人是誰，他們正在面對什么樣的處境。

很多年前我聽過一句話：在工作中、在街道上、在商店里，你遇到的每一個人，生活中都可能正承受著某種你完全不了解的困難。你不知道那件事情有多嚴重。也許是一場悲劇，也可能只是某種煩惱。但總有一些事情正在影響他們的生活，而這些事情你并不知道。如果你帶著這樣的假設去與人交流，你往往會變得更加善良、更體貼，也更有同理心。

而如果你是一個解決問題的人——我認為真正的軟件工程師本質上都是解決問題的人——當你意識到每個人都在面對自己的問題時，你會突然發現，這個世界其實有很多地方可以產生積極影響。

軟件和計算機技術仍然擁有巨大的潛力。它們可以讓世界變得更好，可以讓企業運作得更高效，可以讓社會運轉得更加順暢，甚至能夠幫助改善民主機制。我們其實有很多事情可以去做。但前提是：我們必須真正關心這些問題。否則，我們甚至不會意識到這些機會的存在。

Shane Hastie：我們確實需要關心這些事情。Ben，非常感謝你今天抽出時間與我們交流。在結束之前，如果聽眾希望繼續與你交流，他們可以在哪里找到你？

Ben Greene：LinkedIn 可能是最好的方式。我通常都會回復消息。如果有人向我發送連接請求，也可以順便給我發一條信息。一般來說，如果我沒有與某個人面對面聊過，我不會主動聯系對方。但如果有人主動說：“我想和你聊聊”，那我通常會很樂意安排時間。

事實上，有一次我在 QCon 做完演講后，有位聽眾沒來得及和我交流，他后來在 LinkedIn 上聯系了我。我們在美國感恩節后的第二天通了一次電話，聊得非常愉快。

希望下次我去德國的時候，還能見到他，一起喝一杯。所以，如果有人想交流，我隨時歡迎。

https://www.infoq.com/podcasts/beyond-code-engineers-evolve-ai-era/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。