編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
“AI是未來的新生產力，但現在還是差點意思。”
我們看到越來越多的AI Coding產品，但不管是企業高管、還是我們評論區的開發大佬，近期都不約而同的拋出了一個業內真相：
“我們確實在用AI寫代碼，但速度并沒有更快。”“我們只是寫出了更多代碼，卻沒能更快交付！”
一周前，一家知名智能體平臺公司CEO毫不掩飾地揭露出這一點。“AI參與代碼生成沒問題，但AI交付代碼，沒人敢這么干！”
近期，大洋彼岸也被AI帶火了一個“WorkSlop”（工作糊料）的詞匯，表達的也是這個意思。
“問題在于：更多的代碼并不意味著你能更快測試、更快部署、更好地保障安全或合規。代碼寫出來之后，還有一整套需要完成的工作。”
Harness 聯創兼CEO Jyoti Bansal 表示，“問題在于：更多的代碼并不意味著你能更快測試、更快部署、更好地保障安全或合規。代碼寫出來之后，還有一整套需要完成的工作。”
圖片
越來越多企業開始意識到，用AI來“寫更多代碼”并不一定能加快交付速度。所有這些代碼仍然需要經過測試與集成，而這些環節往往成為新的瓶頸。
所以，單純靠AICoding工具顯然是不明智的。Jyoti 認為，其實大部分開發者時間，都浪費在讓代碼可上線的環節，在這個環節大有機會和文章可做。
在采訪中，Harness暢快聊起了自己如何在“交付環節”這個真正的開發瓶頸上持續多年的嘗試。
這家公司成立于2017年，早期采用了機器學習的方法，當2022年ChatGPT爆火之后，他們自然而然把GenAI的能力內嵌到了產品之中。
當我們開始探索生成式 AI 時，第一步是用 LLM 簡化配置，比如自動生成流水線、自動修復安全漏洞。這是早期的應用場景。
后來我們發現，很多問題其實更適合用 AI Agent 來解決。于是我們構建了一套基于智能體的系統——現在用戶使用 Harness 時，其實是在和一組 AI 智能體打交道。我們叫它 Harness AI。
這個系統由十幾個頂層智能體組成，分別服務于開發、測試、安全、SRE 等任務。每個大智能體下面還有很多專門執行小任務的子智能體。
他還跟團隊強調，關鍵是解決問題，而非是必須使用什么技術。
比如，如果一個 AI 模型要 30 秒才能給出結論，而你寫個規則只要 1 秒，那用戶顯然更愿意等 1 秒。“所以我們要判斷哪種方法最適合：有時先用 AI 探出最優方案，再固化成確定規則，這樣效率更高。AI 不是目的，它是達成目標的手段。”
此外，他也同意，目前生成式AI市場處于泡沫之中。作為活躍的創業投資人，但他對AI泡沫的態度卻相對樂觀。
“AI領域確實很‘泡’，但泡沫不一定是壞事。它往往出現在顛覆性技術爆發期——人們以為兩年能從1做到100，結果五年才做到。但從1到100依然是巨大的飛躍。”
他以互聯網泡沫為例：當年雖有崩盤，但也孕育了幸存的巨頭。如今AI公司眾多，最終只有少數會存活。
“這正是生態的正常演化方式。最終會有贏家，也會有老牌企業吸收創新成果。所有這些都在合理地發生，只是進展可能比預期更快。”
還有一個小插曲，Bansal 曾是上一家初創公司 AppDynamics 的主要代碼編寫者（后被思科以37億美元收購）。
盡管他中途多年不再寫代碼，但借助AI工具，如今他又重新開始編程。
“我又開始‘危險’起來了，”他笑稱。AI讓他在產品管理與需求文檔編寫上也大幅提速。
但他并不認為AI會取代人類開發者或產品經理：
“AI改變的是節奏。競爭壓力更大，以前開發新功能或進入新市場可能需要一年，如今縮短到六個月。
生產力提升后，你會少雇人嗎？目前我看到的更多是——人沒減少，但大家做的事情更多了。”
ok，料還很多，小編為大家整理了原汁原味的對話內容。希望對大家有所幫助和啟發。
AI不是目的，解決問題最關鍵
主持人：這些年我們已經聊過好幾次了，對吧？
Jyoti Bansal：是啊，我也記得。
主持人：我印象最早一次是你剛提醒我的——在溫哥華，大概是 2017 或 2018 年。
Jyoti Bansal：我記得更可能是 2018 年。
主持人：對，我記得那次你航班延誤，我還拿這事調侃你。當時你剛以 37 億美元賣掉 AppDynamics，卻還得在機場等加拿大航空的航班。
Jyoti Bansal：（笑）對對對，沒錯沒錯。
主持人：現在你該能坐頭等艙了吧？
Jyoti Bansal：（笑）是的，是的。
主持人：好，回到今天。其實我特別想請你來聊聊軟件交付這件事。現在幾乎所有人都在用各種 AI 工具寫代碼，但我覺得真正的瓶頸還是在交付環節，也就是 delivery pipeline。所以我們一會兒重點談這個。不過在那之前，我想先問，Harness 現在也已經七八年了吧？在最初創辦時，你有考慮過 AI 嗎？當時的機器學習、深度學習已經開始流行，但生成式 AI 應該還沒出現在視野里吧？
對，那時候當然還沒有 LLM 或生成式 AI。不過有趣的是，Harness 從一開始就和 AI 有關。我們在 2017 年發布產品時，新聞稿標題就是「Harness 將人工智能引入持續交付（Continuous Delivery）」。那是 2017 年底。
之所以這么說，是因為我們的持續交付產品核心就是用 AI 來判斷某次部署是否可能出錯。當時的 AI 還不是語言模型，而是基于神經網絡和機器學習的模型。我們一直在這方面探索。后來我們推出 CI（持續集成）時，也用了一個叫 “Test Intelligence” 的 AI 模型，通過分析代碼變更來決定需要跑哪些測試，從而把構建速度提升四五倍。
所以其實在 LLM 之前，我們就已經在用 AI 優化軟件工程和交付流程了。人們有時候會忘記這一點——AI 在軟件開發領域的應用，并不是從 LLM 才開始的。當然，現在我們進入了一個百倍、千倍加速的新時代，但那只是延續，不是起點。
主持人：確實，有時候我們面對的一些問題，用傳統機器學習也能很好解決。但現在很多公司反而強行往生成式 AI 上靠。
Jyoti Bansal：沒錯。我一直和團隊強調一點——關鍵是解決問題，而不是非得用什么技術。有些問題用智能體（agent）最合適，有些則用規則引擎或者傳統 ML 模型。有些問題甚至靠確定性自動化更高效。比如，如果一個 AI 模型要 30 秒才能給出結論，而你寫個規則只要 1 秒，那用戶顯然更愿意等 1 秒。所以我們要判斷哪種方法最適合：有時先用 AI 探出最優方案，再固化成確定規則，這樣效率更高。AI 不是目的，它是達成目標的手段。
主持人：對，AI 還沒到“萬物終點”那一步。
Jyoti Bansal：（笑）那是另一個話題了。
團隊70%的時間都耗在外環上
主持人：那你們在什么時候決定真正引入生成式 AI？當時的考量是什么？
Jyoti Bansal：我先解釋一下我們看待軟件工程問題空間的方式。我們把它分成兩個環節：內環（inner loop）和外環（outer loop）。內環是開發者在本地寫代碼的過程；外環則是代碼寫完之后，從提交到上線的整個交付過程。
很多人以為軟件開發主要花在寫代碼上，但其實大部分工程團隊有 60%-70% 的時間都耗在外環上。為什么？因為交付環節涉及大量工作：各種測試（集成、負載、API）、安全掃描、開源庫檢查、合規審批、部署、數據庫變更、基礎設施配置、功能灰度發布、回滾、成本優化等等。
這大概有三十多種工作流，也正因此流程非常慢。Harness 的目標就是——能不能重新想象整個交付過程，讓開發者更少重復勞動、更自動化。從最初的持續交付（CD），到持續集成（CI）、再到特性開關（Feature Flags），我們現在平臺上有 16 個模塊在解決這些問題。
當我們開始探索生成式 AI 時，第一步是用 LLM 簡化配置，比如自動生成流水線、自動修復安全漏洞。這是早期的應用場景。
后來我們發現，很多問題其實更適合用 AI Agent 來解決。于是我們構建了一套基于智能體的系統——現在用戶使用 Harness 時，其實是在和一組 AI 智能體打交道。我們叫它 Harness AI。
Jyoti Bansal：這個系統由十幾個頂層智能體組成，分別服務于開發、測試、安全、SRE 等任務。每個大智能體下面還有很多專門執行小任務的子智能體。比如當用戶讓系統「幫我創建一個應用的部署流水線」時，AI 會先了解：你公司的安全標準是什么？合規要求是什么？生產環境架構如何？
為了做到這一點，我們還會為每個客戶生成一個知識圖譜（knowledge graph），包含他們的服務依賴關系、安全工具、SLA 要求等。各個智能體在執行任務時會從這個知識圖譜里提取恰當的上下文。因為你不能讓一個大模型一次性處理所有上下文，那樣效率太低。必須拆成多個小智能體，讓它們在合適的時間獲得合適的信息。
這就是我們今天的 AI 架構——一組面向具體任務的智能體，配合客戶的知識圖譜和上下文，共同完成交付流程中的各個環節。
智能體落地生產環境前，要讓客戶先信任它
主持人：這里面有幾個很有意思的點。首先，你提到現在很多用戶其實是通過智能體來使用 Harness 的。那你們是怎么讓客戶接受這種全新交互方式的？畢竟他們以前習慣了傳統的工具模式，現在還得學會“信任智能體”。
Jyoti Bansal：這是個非常現實的問題。我們做的第一件事就是讓客戶清楚地知道：這些智能體到底在做什么。現在我們的智能體不會直接操作生產環境，而是幫你創建生產部署的流水線。
這條流水線是確定性的、可審計的——每個步驟都可以被人工復查，滿足安全和合規要求。換句話說，AI 不會直接動你的生產系統。坦白講，很多客戶也暫時不會愿意讓它那樣做，這是合理的。
所以我們給 AI 定義的角色是——助手。它幫你創建、優化、修復流程，而不是替你直接執行。比如部署失敗時，AI 會幫你快速定位問題：可能是配置錯了、代碼有 bug、或者版本沖突。AI 能加快診斷、減少重復勞動。
通過這種“人類在環（human-in-the-loop）”的方式，我們讓客戶既能享受到自動化帶來的效率，又能保留控制與審查的權力。
AI參與代碼生成，OK，AI交付代碼？對不起
主持人：對吧？我們現在依然保留那些確定性的工具，如果我想修改某個視頻內容，依然能做到。
Jyoti Bansal：是的。你知道，現在整個行業其實還沒完全做好心理準備。我們現在合作的對象中，有全球前十銀行里的七家。沒錯，他們確實在用 AI 做代碼生成。
但你要看到一個關鍵區別——AI 寫代碼這件事，哪怕準確率是 95%，甚至未來能到 99%，都可以接受。
可如果 AI 參與的是“代碼交付”——也就是把代碼推送到生產環境——那就完全不同了。因為，一行錯誤的代碼，就可能讓整個系統癱瘓。
你看最近的 CrowdStrike 事件，就是一個例子。全世界的系統因為一行 bug 宕機。所以在這個環節，你沒有犯錯的余地。
這也正是為什么，軟件交付過程里會有那么多檢查、驗證和流程。
這些流程是為了確保每一步都是確定性的、有人工審批的、符合監管標準的。監管機構會要求企業證明自己具備相應的流程，以避免那“一兩行代碼”引發生產事故。
優先開發哪些場景的智能體？
主持人：是的，完全理解。那么你們在決定優先開發哪些智能體時，是怎么排序的？因為我剛剛在記你們產品里提到的那些智能體，記到一半就記不下去了（笑）。那你們是怎么確定哪些要先做、哪些后做的？
Jyoti Bansal：我們會從用戶面臨的最核心、最迫切的問題開始。首先，排名第一的當然是流水線（pipeline）的搭建。要實現端到端自動化的交付流水線非常復雜。
你可以想象一下，如果你是一家大型銀行或科技公司，從開發者寫完代碼到代碼上線生產，要經歷各種自動化測試、審批和安全校驗——這整個 CI/CD 流程非常復雜。而這正是 Harness 一直以來的核心優勢所在。
所以我們的第一批智能體，重點都是圍繞這一流程設計的，目標是幫企業系統化、自動化地創建這些流水線。
而這些智能體并不好做，因為每個企業都有不同的安全策略、治理規則和合規要求。我們必須讓智能體學會理解這些企業特有的上下文，才能生成正確的流水線方案。所以這部分是我們優先投入的第一方向。
第二個重點領域是“測試”。開發者現在生成代碼的速度遠快于測試的速度。雖然生成式 AI 能幫你寫一些測試，但那遠遠不夠。
我們看到開發團隊迫切需要的是更高效、更智能的測試體系——包括健壯性測試、端到端測試、單元測試、混沌測試等等。
AI 智能體能在這些領域顯著提升效率。
第三個重點方向是“安全”。隨著 AI 寫代碼越來越多，安全漏洞也隨之激增。代碼安全、應用安全變成了開發交付中的痛點。我們正在通過 AI 智能體來幫助自動檢測、優先排序、甚至修復漏洞。比如，它能判斷哪些漏洞是真正可觸達的、哪些是虛假警報，避免開發者被大量噪音淹沒。
這三個領域——流水線、測試、安全——是我們現在看到最具即時價值的 AI 應用場景。
主持人：明白。剛才你提到應用安全，你們前段時間收購了一家公司，我忘了名字的讀音，好像是……Quiet？
Jyoti Bansal：對，很多人都知道它之前叫 ShiftLeft，后來改名叫 Qwiet（讀音接近“quiet”），大概是兩年前改的。
主持人：因為那幾年大家都在說要“shift left”（左移安全），對吧（笑）？那你們為什么決定要收購它？畢竟你們過去大多數產品都是自研的，只有偶爾才會并購。你們當時是怎么做這個決定的？
Jyoti Bansal：主要原因在于：應用安全領域的問題已經發生了根本轉變。過去的重點是“發現漏洞”——只要能掃描出漏洞就算合格。但現在，最大的痛點變成了“管理漏洞”。
許多企業現在面臨的困境是：漏洞太多，工具太多，噪音太大。比如，一個安全掃描器可能會告訴你有 500 個漏洞，但其實只有不到 10% 是真正需要處理的。
原因很簡單：假設你引用了一個開源庫，這個庫有 100 個功能，而你只用其中 2 個。安全掃描器依然會報告那剩下 98 個你根本不會觸及的漏洞。于是工程團隊被淹沒在無意義的漏洞警報中。
Qwiet（原 ShiftLeft）在解決這個問題上有非常強的技術優勢。他們開發了一個叫“Code Property Graph”的技術，可以分析代碼的可達性關系，也就是“哪段代碼能真正被執行、哪些漏洞是可被利用的”。
這樣我們就能判斷哪些漏洞是真實可達、必須優先修復的，哪些可以忽略。
現在我們正把這項技術整合進 Harness 的 AI 系統里，讓 AI 智能體能自動檢測、排序、甚至修復高風險漏洞，把安全工作從“應付噪音”變成“聚焦關鍵風險”。
為什么要做統一智能體
主持人：明白。那么現在你們的客戶已經能使用這么多智能體，那用戶體驗現在是什么樣的？他們需要分別和不同的智能體交互嗎？還是會統一在一個界面里？實際使用時是怎樣的？
Jyoti Bansal：這是個很好的問題。其實在實際使用中，用戶并不會直接看到這些不同的智能體。他們看到的只是一個統一的界面——Harness AI。我們稱之為“統一智能體（unified agent）”，因為它把所有功能性的智能體都整合在一起。
未來，越來越多用戶會直接從這個統一界面開始，就像你打開 ChatGPT 一樣。不同的是，我們會主動給出一些“可能的任務建議”，基于我們對用戶行為的理解，比如他們最常做哪些操作、最關注哪些環節。
AI 的一個關鍵能力在于“記憶”。Harness AI 會根據每個用戶的行為模式進行學習。比如，它會發現某個用戶主要在處理生產環境的部署流水線，那系統就能推測出，他接下來最有可能執行的任務是什么。
于是我們會提前推薦這些操作，甚至不需要用戶自己輸入提示詞。他們只要點一下，就能執行。
再比如，如果系統發現某個用戶每次登錄都在做成本優化，那下次打開界面時，我們就直接建議相關任務入口。這樣，整個體驗就變得非常簡潔自然。
對用戶來說，這就是一個“單一的 Harness AI”。至于它背后如何把任務分配給不同智能體、再由子智能體完成協作，這些全都是內部細節，用戶無需感知。
主持人：明白了，也就是說未來用戶甚至能自己創建自主型智能體？
Jyoti Bansal：沒錯。我們正在推出這樣的功能，用戶可以自己創建一個自主智能體來完成特定任務。比如，你可以讓它自動把代碼庫從某個依賴庫的 1.7 版本升級到 2.0，智能體會在后臺執行相關任務——驗證所有測試是否通過、檢查 CI/CD 流水線是否正常，并在確認一切無誤后完成升級。這類能力正在逐步開放給用戶。
主持人：那這樣一來，你們的系統其實也會直接觸達用戶的代碼，對吧？
Jyoti Bansal：是的，確實如此。這也是最有意思的地方之一。
AI轉型帶來的技術棧變化：AI重構軟件交付智能體驅動工作流自動化
主持人：我還挺好奇的——像你們這樣的公司，在這幾年 AI 轉型的過程中，技術棧和團隊能力結構上發生了什么變化？
Jyoti Bansal：這個變化確實很大。其實早在 2017 年 Harness 創立之初，我們就開始在做 AI 和機器學習相關的工作，所以公司內部一直有比較強的數據和 AI 基礎架構能力。這也讓我們比很多開發者工具公司更早意識到，可以通過 AI/ML 來解決開發與交付中的問題。
Jyoti Bansal：不過，現在我們確實進入了一個“AI 優先（AI-first）”階段。有趣的是，我們發現幾乎所有優秀工程師，都有潛力成為“AI 工程師”。寫智能體代碼，和寫傳統軟件代碼的技能本質上是相通的。人們樂于學習這種新方式。
Jyoti Bansal：當然，我們仍然需要一些特定的基礎能力。比如，必須有非常扎實的數據基礎設施，還需要懂模型原理的數據科學家。但我們并不自己訓練基礎模型。我們建立在 Anthropic、OpenAI、Gemini 等平臺之上。我們的重點是“在應用層構建智能體”，讓這些智能體具備深厚的領域知識，能理解上下文、解決真實的開發交付問題。
所以我們的工程文化也在經歷轉型。現在整個團隊都在向“AI-first”的思維方式轉變——用 AI 重構軟件交付過程，用智能體驅動工作流自動化。可以說，我們的工程團隊已經很好地完成了這種轉變。
按人頭收費，按Token量收費？
主持人：AI-first 不僅是技術方向的轉變，對商業模式來說也意味著新的挑戰。現在幾乎所有 AI 模型都是基于“按量計費”（consumption-based），模型調用越多，花費越高。你們在運行這些模型時成本也不低吧？怎么平衡這種變化？
Jyoti Bansal：這是個很現實的問題。其實對我們來說，這種轉變相對自然。Harness 從創立開始就是一個“按使用量計費”的平臺，我們的主要定價邏輯從來不是“按人頭（seat-based）”收錢。
我們的產品是一個模塊化平臺，現在大概有 16 到 17 個模塊，覆蓋代碼部署、CI/CD、特性開關、可觀測性、安全測試等多個領域。客戶可以按需選擇要用的模塊，然后根據實際使用量計費。這套邏輯本身就和“消費導向”的模式天然契合。
舉例來說，部署模塊的計費邏輯是：你部署了多少個服務；成本優化模塊看的是：你通過我們節省了多少云成本；特性管理模塊則根據你運行的實驗數量計費。
所以我們早就不是“按用戶數收費”的模式，而是“按消耗計費”的模式。
現在加入 AI 后，我們的定價仍然保持一致：
AI 成本已經內嵌在這些模塊的使用計費里，不會單獨收取“AI 版本”的額外費用。有些廠商會推出“非 AI 版”和“AI 加強版”，價格不同；但我們不希望團隊在體驗層面人為區分“有 AI”和“無 AI”。我們希望 AI 成為體驗中無縫的一部分。
比如，持續交付模塊過去是按部署量計費，現在我們在其中內嵌了智能體功能，但價格結構并沒有因為 AI 而拆分成兩種版本。
我們認為，AI 是交付體驗的自然組成部分，不需要額外標簽。
寫更多代碼，不等于更快上線！
主持人：明白，這樣你們也不用維護兩套產品邏輯（AI 與非 AI），不然確實會變得復雜。那現在的客戶在使用這些智能體時，有什么出乎意料的地方嗎？
Jyoti Bansal：最大的驚喜來自企業客戶的“主動性”。我們開放了基于 MCP的接口，讓企業能將 Harness 的 AI 智能體接入他們自己的系統。
令人意外的是，連那些傳統印象中“行動緩慢”的大型企業，都在迅速采用這種集成方式。
比如，我們有一家全球最大的航空公司客戶，他們基于 Harness 的 AI 打造了自己的內部工具鏈，讓所有工程師都能通過統一界面操作各種任務，從部署到優化全部整合在一起。我們看到很多類似的創造性用法，企業正在用 AI 重塑軟件工程流程。
這其實反映了一個更深層的趨勢。過去大家都在熱衷“AI 寫代碼”，但后來發現——寫更多代碼，并不等于更快上線。因為測試、部署、安全和合規等環節仍然滯后。于是企業開始意識到，真正的突破不在“生成代碼”，而在“交付代碼”。他們現在用 AI 去解決這部分的問題。
MCP究竟好在哪里
主持人：為什么這股采用 MCP 的浪潮會來得這么快？十個月前幾乎沒人提這個協議。
Jyoti Bansal：我認為原因很簡單：靈活性。MCP 本質上是“新一代 API”。過去人們通過傳統 API 集成系統；現在，MCP 提供了一種更智能的方式去“傳遞上下文”。
MCP 允許你把外部智能體無縫接入自己的工作流，并在上下文中共享信息和任務。以前企業會自建一個開發者門戶，讓工程師集中操作各種工具；現在，這個門戶就是他們的“AI 界面”，MCP 則成為它的集成底座。
主持人：那這對 Backstage（開發者門戶平臺）意味著什么？
Jyoti Bansal：Backstage 依然很重要。事實上，我們是企業級 Backstage 最大的服務提供商之一。
我們有一個專門的 IDP 模塊，就是基于 Backstage 搭建的，幫助企業快速落地，不用花一兩年時間自建。
更有意思的是，我們現在在 Backstage 上疊加了 AI 能力。比如我們新推出的“知識智能體（Knowledge Agent）”，它能通過 Backstage 的服務目錄回答問題，查詢服務、環境、基礎設施等信息，還能幫助新開發者自動化上手流程。
40%以上的代碼是AI生成
主持人：明白，那我好奇——你們現在內部寫代碼時，AI 的使用比例大概有多高？
Jyoti Bansal：幾乎所有開發者都在用 AI。目前大概有 90% 到 95% 的工程師每天都依賴 AI 編碼。我們內部甚至討論過是否要把“使用 AI 編碼”設為默認要求（笑）。
有三四十位工程師是 AI 的“重度用戶”，他們熟練使用 Cursor、Windsurf 等工具，效率極高。我們做過一次內部評估，現在大約 40% 以上的代碼是通過 AI 生成或輔助生成的。我相信這個比例未來還會繼續上升。
如何用好AI Coding工具？這點兩點最重要
主持人：那么，你認為在使用這些工具時，什么能讓開發者特別高效？你在觀察到哪些特征？有哪些最佳實踐是你從優秀開發者身上學到的？
Jyoti Bansal：這是個很好的問題。我們其實一直在研究這個——為什么有些開發者的效率特別高？后來我們就安排他們做一些“午餐學習會”，讓他們分享：你為什么比別人更高效？
總體來看，現在大家都在逐漸摸索怎么更高效使用 AI。這已經不再像一年前那樣，優秀開發者和普通開發者之間的差距那么大了，整體水平在提升。
不過，最關鍵的一個點是“配置”。花一點時間去設置規則、定義 Markdown 模板、明確參數。比如，你讓編碼智能體幫你寫代碼，但如果你不給它任何參數或上下文，來回溝通就會很慢。
相反，如果你花幾個小時寫清楚代碼風格、公司內部規范、設計約束，這樣 AI 生成的代碼質量會更高，來回修改的次數也會更少。這可以算是我認為最值得推廣的最佳實踐之一。
還有一點很重要：任務拆解能力。很多人以為可以把一個大任務丟給 AI，但實際上 AI 更擅長處理被拆成 5 到 10 個小任務的工作。優秀的工程師其實正在進化成“任務拆解者”——他們懂得怎么分解問題、設定好每個任務的邊界和參數，然后審查輸出。
在 Harness，我們自己的工具鏈也讓開發效率非常高。我們通過自研工具優化交付流程，從部署、構建、測試到安全和治理，幾乎都自動化了。
我們相信，編碼環節用 AI 提效是一面，交付環節用 AI 優化是另一面。我們在兩端都在用 AI。
有了AI，人并沒有變得更輕松
主持人：老實說，如果你們自己不用 AI，我反而會失望（笑）。那現在你自己還寫代碼嗎？
Jyoti Bansal：哈哈，有一點。我之前確實很久沒寫代碼了。在我創辦第一家公司時，我寫了大概一半的產品代碼，因為團隊太小。后來在 Harness 我基本沒怎么寫。但現在有了 AI，我又開始“危險地動手”了（笑）。不過我更多是在用 AI 幫我做產品管理和規格文檔。
以前寫一份產品規格要花我很多時間，我會跟產品經理溝通，來回幾周才能定稿。現在我直接用 AI 花一個小時就能做出一個結構清晰的初稿，再交給團隊完善。整個過程從原本的三四周縮短到一兩天。對我來說，這種在產品文檔上的效率提升是最明顯的。
主持人：那以前那個你常去找的產品經理，現在怎么辦？我想問的是——你怎么看“AI增強人類”與“AI取代人類”的關系？你覺得現在還處在“增強”的階段嗎？
Jyoti Bansal：我覺得更準確地說，是整體節奏變快了。AI 讓競爭壓力、創新速度都加快了。以前某個功能從想法到落地要花一年，現在可能六個月就得上線。
所以雖然 AI 提高了生產力，但并不是大家因此“更輕松”了，而是做得更多。
企業的選擇很現實：要么用同樣的人做更多事，要么落后。現在基本上是前者——大家更高效，也更忙（笑）。
AI真的在重塑一切
主持人：你同時也是一位活躍的投資人。最后一個問題——在 Harness 之外、在 CI/CD 之外，你最近對哪些方向最感興趣？
Jyoti Bansal：我共同創立了一家早期投資機構 Unusual Ventures，專注種子輪。我們會非常深度地參與被投公司的成長，不只是投錢，而是幫助他們搭建銷售、市場、運營等能力。
現在是一個非常令人興奮的階段。我們在看很多 AI 基礎設施項目，也在投不少垂直領域 AI——比如醫療、金融、制造等行業的專用解決方案。
我最近問團隊：我們收到的項目里，有多少是 AI 相關的？我以為答案是 50% 或 60%，結果他們說：100%。這說明所有創業者都在用 AI 重塑各自領域。
我們在投的方向包括：AI 重新定義 CRM、重新定義 SRE、重新定義制造、設計等。幾乎每個領域都有人在用 AI 重新發明流程。
所有AI領域都存在泡沫，問題是誰會死掉，誰能活著
主持人：我這周剛去了 OpenAI Dev Day，Sam Altman 當時提到某些 AI 領域有點泡沫化。我問他是哪些領域，他沒回答（笑）。那我來問你：你覺得現在有泡沫嗎？
Jyoti Bansal：我覺得 所有 AI 領域都有泡沫，但這并不是壞事。每當有顛覆性技術出現時，市場都會高估它的短期速度、低估它的長期影響。互聯網就是這樣——人們以為“一年后人人都上網”，但其實花了更久才實現。
AI 也一樣。是的，現在有些估值虛高、競爭過熱的現象，但從長遠看，AI 的變革是真實的。
在任何熱門賽道里，也許 20 家創業公司中最終只有 4、5 家能活下來，其余都會失敗。但這正是創新生態的本質——競爭、試錯、進化。泡沫本身不一定是壞事，它往往是大浪潮前的必經階段。
主持人：是啊，說到這里，從“泡沫中的死亡”到“幸存者的成功”，真是個既現實又振奮的話題。今天非常感謝你的時間，跟你聊天總是很有啟發。
Jyoti Bansal：謝謝，真的很高興聊這個話題。
主持人：同感，謝謝你。
好了，文章到這里結束了。這篇文章的采訪對象本身就是一位技術大牛，所以他的視角可以說非常真實。現階段，AI的確存在成分，市場估值遠超其現在所能創造的表現。
但泡沫什么時候不存在呢？既然注定是未來，那問題就變成了：怎么在這場泡沫中成為贏家！
