第一個 AI 程序員 Devin 的公司,已經開始用 Devin 來構建「Devin」了。
去年 12 月,Cognition 推出了全球首個 AI 編碼程序員「Devin」,定位是一名無需人類干預、能獨立寫代碼并獨立完成整個項目的虛擬工程師,訂閱價格為 500 美元/月。
產品上線后的 6 個月內,Cognition 完成了數億美元的 A 輪融資,估值翻了一番,達到近 40 億美元,成為 AI 編程賽道的絕對明星公司。
目前 Cognition 的工程團隊只有 15 人,但每位工程師都配備了一個由 5 個 Devin 智能體組成的「虛擬團隊」。現在,Cognition 內部約有四分之一的 Github Pull Request 由 Devin 完成。創(chuàng)始人 Scott Wu 預計,一年后這一比例將提升至 50%。
在近期做客 Lenny’s Podcast 時,Scott Wu 也更詳細地講述了 Devin 從一個概念走到能端到端執(zhí)行任務的「初級工程師伙伴」的過程,它如何融入現有的軟件開發(fā)流程,以及他如何思考 AI 浪潮下工程師的角色變化。
以下是全文:
核心內容:
- 用 Devin 構建 Devin:把 Devin 看作一個并肩作戰(zhàn)的初級搭檔。每位工程師在構建 Devin 的過程中,都會大量用到 Devin 本身。
- Deivn 讓工程師從「砌磚工」變成「建筑師」:你可以給出高層級的指令,指定你想要的實現方式。這仍然需要你來掌控方向、定義規(guī)范,但你一天能完成的事情、能構建的系統(tǒng),已經完全不在一個量級了。
- 開發(fā)會越來越像異步寫協(xié)作:關鍵在于,明確你要解決的問題,定義你要構建的系統(tǒng),其余的交給 Devin 異步處理。你只在需要專業(yè)判斷的節(jié)點介入。
- Devin 擅長處理清晰、具體的任務:你應該給 Devin 任務,而不是問題。必要時多加引導,確保它沿著對的方向走下去。
Devin 讓工程師的能力成倍增加
Lenny:讓我們先談談 Devin,讓大家了解一下 Devin 到底是什么,這是你們公司的主要產品。理解 Devin 最簡單的方式是什么?
Scott Wu:Devin 是一個完全自主的軟件工程師,它能夠端到端地完成任務。現在市面上有很多很棒的工具,覆蓋了 AI 編碼工作流的各個環(huán)節(jié)。Devin 的特別之處在于它是一個完整的異步工作流(Asynchronous workflow)。你可以在 Slack 的某個問題討論中 @Devin,或者在 Linear 里標記 Devin,然后 Devin 就會在你的 GitHub 中創(chuàng)建 Pull Request。所以,它完全是為了與工程團隊協(xié)作而設計的,就像你的初級工程師一樣。
Lenny:我記得你們剛推出這個產品的時候,宣傳語大概是「你的新 AI 工程師」。它在很多方面表現出色,但在其他方面還有待提高。從你們推出到現在大概一年了吧?
Scott Wu:是的。
Lenny:如果用工程師的資歷水平來衡量 Devin,你覺得剛推出時的 Devin 和現在的 Devin 大概處于什么級別?這是否是衡量 Devin 能力的一個好方法?
Scott Wu:一年前我們首次發(fā)布 Devin 時,大家甚至覺得智能體很難實現。那是一個非常不同的時代。2024 年初,AI 模型的推理能力還處于相當早期的階段。
從那時起,它有了顯著的發(fā)展。從實用技能方面來講,我們偶爾會做些比較,最開始的時候,它就像一個高中學計算機的學生,后來逐漸成長得更像一名大學實習生,而現在則相當于一位初級工程師。
不過這些判斷標準比較粗略,因為我很贊同 「參差不齊的智能」 這個說法,它在某些領域比人類強出不少,可在另一些方面又不如人類。
在過去一年里,我們收獲了許多經驗,不只是關于編碼智能體,更是關于智能體本身 —— 包括怎樣構建智能體,以及如何將其融入工作流程,使之與人協(xié)同工作。
當時,Devin 還沒有 Slack、GitHub、Linear 集成,也沒有交互式的規(guī)劃階段,更沒辦法修改它生成的代碼。所以,從那時起我們開發(fā)的諸多產品功能,基本都是為了找到最佳方式,讓與 Devin 協(xié)作以及向 Devin 分派任務的體驗盡可能順暢。
Lenny:所以很多工作不只是單純地提升 Devin 成為最優(yōu)秀的工程師,而是讓其更好地適應與人的協(xié)同合作。
Scott Wu:我覺得這兩方面是各占一半的。一方面是 Devin 的能力有了顯著且可衡量的提升。另一方面是產品界面、工具等的優(yōu)化。現在大家普遍知道如何使用聊天機器人并與其協(xié)作,但對于智能體,我認為用戶仍需花費一些時間和精力去學習如何使用它們并最大化地發(fā)揮其價值。所以,看到許多其他公司如今也紛紛在智能體領域投入精力,真的讓人感到很興奮,這是我們所有人在共同探索的方向。
Lenny:關于 Devin 目前的規(guī)模,你能分享一些信息嗎?任何你方便透露的都行。然后,你認為一年后 Devin 的編碼能力會達到什么水平?
Scott Wu:我們與各種階段和規(guī)模的公司合作。最小的,有只有一兩個人的初創(chuàng)公司,他們使用 Devin 來構建他們最初的原型或產品;大的有大型上市公司、財富 100 強公司或上市銀行等,他們在整個工程團隊中使用 Devin。
總的來說,我們看到了非常廣泛的應用場景。顯然,在一兩個人的初創(chuàng)公司所做的工程工作與在一家上市銀行所做的工作是非常不同的。
但貫穿始終的是,Devin 都是你那個能讓你更快行動、真正放大你能力的初級伙伴。它可以通過讓你與自己的 Devin 團隊協(xié)作,而不是必須完全同步地處理單個任務,來放大你作為工程師的能力。
然后,它也像是在放大你的團隊和團隊的知識庫,因為 Devin 在與你團隊的每個成員合作的過程中,確實積累了大量的知識,并能將這些知識帶入每個新的會話中。
產品體驗將從「文本補全」模式轉向「智能體」模式
Lenny:讓我們先回到旅程的起點。Devin 的起源故事是怎樣的?這一切是如何開始的?
Scott Wu:創(chuàng)始團隊的大多數人認識很多很多年了。對幾乎所有人來說,這是我們第一次一起工作,但我們認識很久了。在過去十年左右的時間里,我們都在 AI 領域有著各自的探索。就我而言,在此之前我在做一家名為 Lunchclub 的公司,這是一個用于職業(yè)社交的 AI 產品,我做了大約五年。
我的聯合創(chuàng)始人之一 Steven,是 Scale AI 公司的首批工程師之一,這家公司顯然成長了很多,做得非常出色。
我的另一位聯合創(chuàng)始人 Walden,是 Cursor 的早期工程師,這家公司顯然也成長了很多,做得非常好。
我們整個團隊差不多都是這樣,我們很多人是通過編程競賽和數學競賽認識的,但在那之后的幾十年里,我們一直保持著非常密切的聯系,并且都有各自的發(fā)展。
我們有一個曾在 Nuro 負責團隊的人,一個曾在 Waymo 工作的人,還有一個自己創(chuàng)辦了 YC 孵化的機器學習工具初創(chuàng)公司的人。
我們非常興奮能一起做點什么。這大約是在 2023 年底,也就是一年半前。剛開始時,有幾件事我們堅信不疑。其中之一是強化學習確實有效,并將成為能力上的下一個重大范式轉變。
當時 ChatGPT 于 2022 年首次推出,那些模型在 AI 領域,我們稱之為模仿學習(imitation learning)?;旧暇褪亲屇P烷喿x互聯網上所有能找到的文本,然后訓練它像互聯網上的某個人那樣說話,這是最初做法的核心。它非常了不起,通過了圖靈測試,并且對很多事物擁有百科全書般的知識。
我們過去一年進入的這個新范式,是真正高算力的強化學習。這是一個截然不同的范式:它能夠去執(zhí)行任務、整合事物,然后根據結果的正確與否進行評估,并利用這些知識來決定下一步行動并從中學習。我們堅信這一定會發(fā)生。
對我們來說,代碼是很自然的選擇,有幾個原因。一是因為我們自己都是編程愛好者,所以代碼對我們來說再熟悉不過。另外,代碼本身就有一個完整的自動化反饋循環(huán),你可以運行代碼,這種自動化反饋正是強化學習所需要的,也使得這些模型在編碼方面表現出色。
另一件我們堅信不疑的事情是,產品體驗將從「文本補全」模式轉向「智能體」模式。從根本上說,文本補全領域已經有很多很棒的體驗。它被用于市場營銷、客戶支持、教育和編碼,例如 GitHub Copilot 是那一波浪潮中真正的主導產品。
但我們真正預感到的重大轉變,是從這種文本到文本的模型,轉向一個能夠做決策、與現實世界互動、接收反饋、迭代并采取多個步驟解決問題的真正自主系統(tǒng)。我們稱之為智能體,這正是我們當時真正興奮的事情。所以,方向一直是編碼,一直是智能體。這看起來像是一開始就應該很明確的,但即便如此,在過去一年半的時間里,在編碼智能體這個大方向內,我們感覺自己好像已經調整了八次方向左右。
Lenny:我最近注意到,所有頂級的 AI 公司,不是所有,但很多公司的成功產品,其名稱都與公司名稱不同,這很不尋常。比如 Cursor 和 Anysphere,Bolt (bolt.new) 的 StackBlitz,你們是 Cognition AI,Vercel 的 v0。這告訴我,這些產品都是在公司發(fā)展后期出現的,他們嘗試了很多東西,然后發(fā)現「哦,這個東西成功了」。在這些頂級公司中,這種情況如此普遍,真的很有趣。
Scott Wu:是的,甚至還有 OpenAI 的 ChatGPT,Anthropic 的 Claude,Google 的 Gemini。這很有趣,是的,我同意。
所以,當我們剛開始時,它甚至算不上一個公司,更像是一個項目,或者說幾乎是一個黑客松。我們基本上在感恩節(jié)前后租了幾周 Airbnb,聚集了一群人,興奮地想做些項目,構建一些酷的東西。
有趣的是,我們最初構建的東西實際上更像是解決那些類似編程競賽的問題,并使用一種智能體循環(huán)來在這些問題上做得更好。顯然,如果你在測試用例上運行代碼,你可以進行評估,這里面有很多智能體可以做的工作來嘗試做得更好。我們最初花了一些時間在這上面。
然后,我們公司整個的故事在某種意義上就是從一個黑客松到另一個黑客松。在那之后,我們又搞了一個黑客松,Devin 最初的一些想法就是在那時產生的,真正構建一個軟件工程智能體,而不僅僅是一個編碼智能體,并讓它與許多這些工具互動。但即便如此,還是有很多迭代。甚至,與 Devin 對話的想法,也是我們必須想出來的。
最初,它只是你交給他一個任務,然后它工作,最后給你展示整個完成的代碼。而現在顯然是,你可以隨時介入,可以就計劃獲得反饋,你們可以一起確定任務范圍。當你與 Devin 一起工作時,很多這些東西我們都必須逐步開發(fā)出來。當然,我們對使用場景、產品形態(tài)學到了很多,我們在能力上取得了很多重大改進和階躍式提升,Devin 使用工具、調試和做決策的能力都得到了提升。所以,這是一段有趣的旅程。
對我們來說,根本性的問題,也是我們一直在思考的問題,就是軟件工程的未來是什么樣的?我們應該如何與 AI 合作來編寫代碼?因為歸根結底,這才是我們所有產品決策的基礎。
Lenny:你們是什么時候開始嘗試著搗鼓開發(fā)的?Devin 是什么時候推出的?這期間有多長時間?
Scott Wu:我們是從 2023 年 11 月開始的,當時還只是黑客松模式。我們在 2024 年初正式成立了公司。然后我們的首次發(fā)布是在 3 月份。所以,那段時間簡直是馬不停蹄。實際上,在過去的 17 個月里一直都是這樣。從發(fā)布到與企業(yè)合作,再到大量開發(fā)產品,構建它并使其適用于許多實際用例,然后在去年 12 月實現完全自助服務,以及幾周前剛剛推出的 2.0 版本。對我們來說,這是一段非常忙碌的時期。
Lenny:簡直是世紀性的輕描淡寫。
用 Devin 來構建 Devin
Lenny:將 Devin 視為一個「人」,為 Devin 創(chuàng)造個性的這個想法,這與其他任何 AI 應用都不同。我覺得市面上沒有其他 AI 應用會擁有名字,讓你把它當作一個人來看待。你們當初為何決定采用這種設計思路?又是如何設計它使其運作良好的?
Scott Wu:這是我們相當自豪的一個決定。市面上有很多不同的產品體驗。而真正讓 Devin 在其所做的事情中獨一無二的是,你可以真正地把任務交給它。
我們越來越多地看到,向人們解釋 Devin 的體驗的最好方式就是解釋說:「是的,這是你的初級伙伴?!惯@一點適用于流程的很多部分。
比如在 onboarding 階段,最初我們確實有很多用戶進入界面后只看到空白屏幕,完全不知所措,或者他們會問「我打算對整個代碼庫進行大規(guī)模重構」。
而我們隨著時間推移學到的是,要引導用戶轉變思路,比如「等等,讓我們先搞定代碼庫的設置」。讓我們先給 Devin 分配幾個簡單的小任務,讓它熟悉一下代碼庫。讓我們確保如果 Devin 需要能夠測試代碼、運行 linter 或 CI 之類的東西,我們得確保 Devin 有自己的虛擬機設置好來做這些。
同樣地,用戶的使用模式起初也不清晰。顯然,你可以坐著看 Devin 一步步地執(zhí)行操作。但我們發(fā)現,作為一個需要構建大量東西的團隊,最佳的工作流是與多個 Devin 協(xié)作,讓它們異步執(zhí)行任務,啟動它們,然后僅在你需要提供反饋或引導計劃時才介入。
從很多方面來看,Devin 這個名字,正是我們試圖捕捉產品靈魂的一種嘗試。它確實是被視作一個自主實體來對待,你可以把任務交給它,與它協(xié)作,并且在長期使用中教導它并與它一起學習。
Lenny:我想聊聊 Devin 對軟件工程的影響,以及軟件工程將如何改變。這個話題可以拆分為兩部分:以今年使用 Devin 的情況為例,對于那些企業(yè)而言,作為一名工程師,其從工作方式和構建方式正在發(fā)生怎樣的變化?
Scott Wu:我們都是軟件工程師,我骨子里依然是個程序員。
從宏觀層面來看:計算機正變得越來越智能,能夠做的事情也越來越多。也許有一天,計算機真的能完成我們所做的一切,人類不再需要負責任何事情。
我不認為這會很快到來。但在此之前,只要我們人類還需要編程,最重要的任務之一,就是指導計算機我們想要什么、想構建什么、想做什么。
所以從這個角度來看,我認為隨著 AI 變得越來越強大,編程只會變得越來越重要。對我們來說真正令人興奮的是,看到這種迭代式的轉變。
目前的情況是,我們可以把 Devin 看作一個初級伙伴,或者一個由初級伙伴組成的團隊,你可以和他們一起工作。
我們團隊里的每一位工程師,在構建 Devin 的時候都會大量使用 Devin。因此,Devin 每個月會將數百個 Pull Request 合并到 Devin 代碼庫的生產環(huán)境中。
我們整個團隊只有大約 15 名工程師,所以 AI 輔助編碼在我們編寫的所有代碼中占了相當大的比例。我們每個人都擁有自己的 Devin 團隊。
如果你要處理各種問題、功能請求、bug,或者研究你想構建的新范式,很自然地,會有很多交接點。在這些交界點,你就可以 @Devin,然后告訴它:「現在情況是這樣的,你能幫忙處理一下嗎?」
有時候 Devin 能夠百分之百自主地完成任務,直接創(chuàng)建 PR,然后你合并 PR;有時候,你可能需要自己介入,做 10% 或 20%的工作,也許在具體如何界定范圍或如何架構這個功能方面有一些細節(jié)需要你處理,或者你可能想在最后自己去測試前端,確保它看起來完全符合你的要求,并在之后給出你的一兩句反饋。但在大多數時候,都是與 Devin 一起工作,讓它并行處理更多事情,構建更多東西。
四分之一的 PR 由 Devin 完成
Lenny:目前你們的 PR 中,Devin 提交的和人類提交的比例分別是多少?
Scott Wu:我得查一下,但 Devin 大概占我們所有 PR 的四分之一左右。
Lenny:那六個月前是什么情況呢?
Scott Wu:相比六個月前,它在我們內部呈指數級增長。Devin 的發(fā)展關乎兩個方面:能力和產品界面。
首先,它的智能水平提高了很多。
另一方面,我們也花了很多時間來研究如何構建它的界面:在這個界面上,即使 Devin 只能完成 80% 或 90% 的任務,你也能獲得 Devin 的價值。
Devin 顯然不是完美的,它會犯錯。很多問題是,你最初如何與 Devin 一起初步確定任務范圍,然后讓 Devin 去做你想讓它做的事?你如何在最后階段介入審查并提供反饋?你如何確保 Devin 隨著時間的推移而學習?你如何能夠根據需要進行檢查并在需要時糾正方向?
Lenny:今天你們大約四分之一的 PR 是由 Devin 提交的。你認為到今年年底這個比例會達到多少?
Scott Wu:到今年年底,預計會超過一半。而且我們觀察到的一件事是,你能夠異步完成越來越多的工作,并且能夠交接越來越多的任務。
我認為編程的靈魂、軟件工程的靈魂,無論是以前還是現在,無論你使用的是匯編語言、Pascal 語言,甚至在打孔卡時代,基本上就是定義你面臨的問題,并真正深入思考你想要的解決方案究竟是什么。思考架構,思考細節(jié),并在你的腦海中精確地規(guī)劃出你到底想構建什么,以及你想讓你的計算機做什么。這是軟件工程的偉大之處,也是它最有趣的部分。
然而,這些工作可能只占普通軟件工程師大約 10% 的時間,其他 90% 的時間,你可能遇到了 Kubernetes 的錯誤,你必須 debug,你必須找出問題所在,或者是系統(tǒng)崩潰了,或者你某個端口沒關導致了問題,又或者你需要遷移代碼,需要升級到新版本之類的,更多的是類似執(zhí)行層面的工作。
我們思考和構建 Devin 的一種方式,就是真正讓工程師可以從「砌磚工」轉變?yōu)椤附ㄖ煛埂?/strong>很多時候,關鍵在于達到這樣一個程度:你可以進行高層次的指導,并且可以精確地指定你想要的方式。
我認為這仍然非常需要由人來掌控,由人來進行完整的規(guī)范定義,但同時極大地放大了你在一天、一小時或任何時長內所能做的事情和所能構建的東西的量級。
未來,軟件工程師仍需要學習寫代碼
Lenny:未來,假設有人想進入軟件工程領域成為一名工程師。首先,你認為人們是否還應該學習編程?其次,對于今天的工程師來說,你認為哪些技能會變得越來越重要,哪些會變得不那么重要?在我們討論從「砌磚工」到為「建筑師」的轉變時。
Scott Wu:我很喜歡這個問題。就「是否仍需學習編程」 這一問題而言,我的答案是絕對肯定的。
當你上計算機科學課程,學習這些基礎知識時,當然你會學到一些關于特定語言如何工作的知識。但你學到的大部分內容實際上是關于邏輯分解問題的能力;其次是對于計算機模型以及長期以來我們構建的各種決策和抽象概念的理解,比如什么是數據庫?應如何理解數據庫?什么是垃圾回收系統(tǒng),它們的運作原理是什么?以及所有這些不同的組成部分。
我們在編程領域已經經歷過這些階段。未來的發(fā)展階段我覺得會更快、更大規(guī)模,但許多方面與當下情況相似。比如,當你現在使用 Python 時,實際上已經有很多內容被抽象化了。50 年前的人可能已經會說 Python 就是「你用英語解釋你想要什么,然后計算機就為你做了」。這非常強大,它打開了大門。我們現在的程序員數量顯然比以往任何時候都多,就是因為這個。
但當你作為一名工程師培養(yǎng)技能時,深入理解這些抽象概念并探究其底層原理非常有幫助。比如說,如果人們真的想對一段代碼進行性能優(yōu)化,他們會使用匯編語言。為了構建好的系統(tǒng)并理解這些東西,你肯定想要理解這些抽象概念,比如網絡是如何工作的?TCP/IP 到底是什么?或者這段 Python 代碼在被解釋時會發(fā)生什么?或者所有這些細節(jié)。
我們會達到一種狀態(tài),即使沒有任何經驗的人,也能夠憑借描述自己的需求來構建一些很酷的產品,完成很了不起的工作。但同時我認為,在相當長的一段時間里,人們依然需要能夠精準地思考細節(jié),揭開抽象的面紗,非常精確地定義想要構建的東西以及構建方式。
Lenny:你認為對于工程師而言,哪些技能會變得愈發(fā)有價值,他們應著重在哪些方面發(fā)力?
Scott Wu:我認為是架構方面的技能。工程領域已經有「架構師」這一術語,我覺得它在發(fā)展方向上是合理的。常規(guī)的實現、編寫樣板代碼等事情,AI 編程已經讓我們在這方面快了不少。
關鍵問題在于理解復雜的系統(tǒng),在整個公司的大背景下開展工作,思考正在構建的產品或正在從事的工作,弄明白我們想要解決的問題是什么?應如何解決這些問題?我們究竟想要構建怎樣的解決方案?以及將要做出的關鍵決策和權衡是什么?
那些能夠出色完成這些工作的人,將會越來越多地發(fā)揮自己的影響力。所以,如果說有什么不同的話,我認為幾年后,程序員和工程師的數量會比現在多很多。而且,成為程序員的具體形式顯然很快會發(fā)生改變。我們能構建的東西將會多得多。
人們常常提及「杰文斯悖論」,軟件確實是杰文斯悖論的典型例證。我們人類社會總能找到越來越多的事物,為其構建軟件、編寫更多代碼,真的還有很多事情可以去做。
Lenny:對于那些不知道杰文斯悖論的人,你能簡單解釋一下嗎?
Scott Wu:當然可以。杰文斯悖論簡單來說就是,當某樣東西的價格下降時,總支出反而可能上升。你可以用金錢、時間或資源來思考這個問題。但這里的直接版本是,隨著編程變得越來越容易,編程變得越來越有效,我們將擁有更多的程序員。
從一種零和博弈的角度來看,你可能會說,我們在軟件工程方面的速度將提高 10 倍,這意味著我們需要的軟件工程師將減少 10 倍。但我認為,實踐中真正會發(fā)生的是,我們實際上將構建超過 10 倍的代碼量。因為我們所做的所有工作顯然都受限于我們實際構建、執(zhí)行和迭代的能力,我們將會有如此多偉大的想法,如此多偉大的產品。人們將會構建更多個性化的體驗,等等。將會有很多事情要做。
隨著技術能力不斷提升 ,開發(fā)工作會越來越向異步工作流轉變
Lenny:你說每位工程師都擁有一支 Devin「團隊」。在你們公司,現在大多數工程師通常會同時與多少個 Devin 一起工作?
Scott Wu:這個過程是異步的,你可以根據需要隨時啟動和關閉 Devin。團隊中的大多數人,通常會同時與多達 5 個 Devin 一起工作。這是一種很好的工作流程,你有 5 件事要做,可以讓 Devin 1 號做第一件事,Devin 2 號做第二件事,以此類推。我們花了一些時間才真正適應并達到這種狀態(tài),讓它對我們來說非常直觀。
這確實是一種不同的體驗,你可以將大部分事情異步地交接出去。你每個任務的目標是在那些真正需要你專業(yè)知識的部分出現,精確定義你正在解決的問題和你正在構建的東西,或者在一些比較復雜的部分,你需要引導 Devin 朝著你想要做的特定類型的更改方向發(fā)展。例如,我希望這個類別這樣設置,我們應該去修改所有下游對這個的引用。但基本上是讓 Devin 異步地為你完成大部分工作。
Lenny:你們大概有多少工程師?
Scott Wu:我們現在的工程團隊大約有 15 人。
Lenny:15 人?哇哦。每個人大約有五個 Devin。所以 Devin 的數量是工程師的五倍。我喜歡這一點的原因是,這簡直就是向未來的一瞥。你們在使用 AI 工程師方面遙遙領先于其他公司,所以觀察你們的運作方式,基本上就能了解大多數公司最終將如何運作。
Scott Wu:是的,而且我們自己已經看到了這種轉變。在團隊層面,大家不會花那么多時間僅僅編寫樣板代碼或者只是進行純粹的功能實現。人們可以將更多的時間專注于思考真正核心問題,比如,我們如何讓 Devin 變得更好?最合適的 Devin 交互界面是什么?什么樣的流程或功能組合才能真正讓 Devin 體驗盡可能出色?這就是我們喜歡的方式。
Lenny:那么什么時候你們會達到這樣一個臨界點,即 Devin 的發(fā)展速度遠遠超過其他所有人?比如,一旦你有足夠多的 Devin 在做所有這些事情,你就領先了 10 年、20 年、30 年、100 年。
Scott Wu:全球的工程師們,都將思考這個問題,圍繞這一方向開展開發(fā)工作,并逐步適應這些新技術。隨著技術能力的不斷提升,即使在今天的穩(wěn)定狀態(tài)下,事情會越來越多地向這種異步流程轉變。
其中一個原因在于,你始終受到現實世界約束的限制??梢赃@樣理解(不過這些數字并非精確數據),最基本的邏輯是:能夠編寫文件、完成函數或某行代碼之類的任務,已經帶來了巨大幫助,使用體驗也非常出色。但構建軟件的很多部分幾乎完全不是這樣。
例如,當你修復一個 bug 時,需要啟動本地服務器,在前端點擊產品嘗試復現這個 bug。一旦出現錯誤,要去查看 Datadog 了解情況,并嘗試在日志中查找其他錯誤。還要查看哪里出了問題,做一些修改,甚至重新運行整個流程,以確保修改后的結果是正確的。這很大程度上就是作為一名軟件工程師意味著什么。這些過程都需要真實的時間。
隨著我們越來越多地轉向這種智能體工作流程,從某些方面來說,這就像未來幾年我們通過軟件工程來實現 200%、500% 甚至 1000% 增長的真正途徑。
Devin 的一大優(yōu)點是它總是充滿熱情
Lenny:讓我們向大家展示一下 Devin 的工作原理到底是什么樣子吧。
Scott Wu:好的,與 Devin 協(xié)作的整個過程顯然是異步進行的。所以,我想我們可以實際觀看一下 Devin 的工作過程,然后我們可以看一些 Devin 完成的其他工作示例,或者 Devin 為我們團隊所做的事情。然后我們可以異步地回來看看我們最初運行的那個 Devin。
我想強調的關鍵是,想想我們作為軟件工程師,或者工程團隊、產品經理等等,思考我們想要構建什么,想要交接什么。所以,我們已經用我們自己的 Devin 代碼庫設置好了 Devin。所以,我會為它啟動一個 Devin。我會說:
「嘿 @Devin,我和朋友 Lenny 在一起。你能修改一下 Devin 的 web 應用,把 Lenny's Newsletter 作為 Devin 網站的一部分展示出來嗎?就在真實的 Devin 網站上吧。」
所以我們啟動這個任務。如你所見,Devin 立刻開始工作并做出回應。你可以異步地處理這個,也可以同步處理。這次,我們就稍微深入一點,看看具體發(fā)生了什么。但如你所見,Devin 正在瀏覽文件,查看很多東西。所以,我們可以根據需要在這里跟進,看看哪些是有意義的。你可以看到 Devin 已經指出了幾個特定的部分。比如側邊欄,這是我們在前端實現的。那里有一些部分,我們將擁有一個新的組件,這個組件將鏈接到 Lenny 的網站。這聽起來都不錯。Devin 在問我們是否有什么問題。同樣的情況,你可以讓 Devin 自己做決定并交接,或者你可以提出更多想法。比如按鈕應該在新標簽頁還是應用程序內打開? 我會說,「讓它在新標簽頁中打開吧」。
Lenny:你可以在任何時候回答這些問題嗎?它是在等你嗎?
Scott Wu:你可以在任何時候回答這些問題把任務交出去,也可以再收回來。
Lenny:它不會說:「天哪,我剛寫成這樣,你為什么不早點告訴我?」
Scott Wu:沒錯。關于 Devin 的一個重要優(yōu)點是,Devin 總是充滿熱情,總是準備好投入時間。
我們會給 Devin 一點時間工作,它會瀏覽這些文件,然后為我們創(chuàng)建一個 PR,我們會看看結果如何。但我覺得展示一些 Devin 在其他場景下的例子也很有趣。
其中一個例子是今天早上我剛用 Devin 做的,我讓 Devin 幫我復習一下關于這次播客的一些背景信息。顯然,我是這個播客和 Newsletter 的忠實粉絲。我問 Devin:「嘿,Devin,我要上播客了,你能幫我研究一下關于 Lenny 的所有信息,并為我制作一個漂亮的網站測驗,這樣我能確保自己掌握了事實嗎?」
所以 Devin 在今天早上做了這個,我大概展示一下 Devin 做了什么。看起來它首先去了維基百科。不幸的是,維基百科上沒有 Lenny 的頁面,Lenny,我們得努力一下了,Devin 對你太不尊重了。我們需要一個頁面,然后,它去 Spotify 上找到了。
Lenny:所以你在實時觀看它研究的過程?
Scott Wu:是的。顯然這是今天早上的事情。
Lenny:這是 Devin 所做事情的回放。這是 Devin 的一部分功能,你可以回看它做了什么。
Scott Wu:是的。特別是當你在構建工程項目或類似的東西時,你可以看到 Devin 采取的每一步?;蛘呷绻?Devin 在本地測試了代碼,你顯然希望能夠去看看 Devin 點擊了什么,測試了什么,或者類似的事情,它找到了 Newsletter,它正在查看這個,將要閱讀所有這些內容。
然后它說:「好吧,讓我們開始把代碼整合起來吧。我已經研究了這些,正在寫所有這些,把應用組合起來?!?它實際上自己玩了自己的測驗。讓我們看看,看看我知道多少。
Lenny:播客的名字是什么?
Scott Wu:Lenny's Podcast。
Lenny:播客有多少訂閱者?
Scott Wu:一百萬。
Lenny:Lenny 關注的三個主要話題是什么?
Scott Wu:產品、增長和職業(yè)。
Lenny:非常好!這是個好測驗。除了播客,Lenny 還做什么?
Scott Wu:我會說,寫作、天使投資和顧問。
Lenny:Lenny 多久發(fā)布一次?
Scott Wu:每周一次。我們可以完成所有這些。我當然也做了這個測驗,以確保我準備充分。但這只是其中一個比較有趣的例子。
Lenny:Scott,我的 newsletter 有多少訂閱者?
Scott Wu:超過一百萬。我再展示最后一個例子,之后也許我們可以回到我們最初運行的那個任務。
Devin 的諸多功能旨在與現有代碼工作流程無縫協(xié)作。例如,我們當時在 GitHub 探索 DeepSeek 代碼庫,將其導入 Devin 并建立獨立分支(fork)。
我想在這里展示幾件事。一是 Devin 會建立自己的 wiki,全方位呈現對代碼庫的深度理解。當 Devin 索引代碼庫時,它會構建代碼庫的表現形式、持續(xù)學習并優(yōu)化,這是其核心能力之一。
有意思的是,我們發(fā)現人類也渴望了解代碼庫的表示形式,所以推出了 Devin Wiki。你可以瀏覽各個部分,看到每一項不同的內容。這里是 FP8 操作,這里是 SGLang 集成,有關于不同層如何構建和組合的圖表,有部署操作,還有很多關于架構的細節(jié)。你可以據此提問。
比如,你可詢問:「DeepSeek 如何處理為推測性解碼設計的多 token 預測?」 Devin 會搜索整個代碼庫,給出有理有據的回答。我們常常使用這項功能,尤其在規(guī)劃任務與提供初始提示時,即便沒有特定任務也十分實用。
Deivn 擅長處理明確任務而非問題
Lenny:隨著我與越來越多做 AI 的公司和應用交流,我了解到他們在能夠集成多大的代碼庫方面存在很大差異。這對于現有公司、初創(chuàng)公司、以及那些擁有龐大現有代碼庫的公司來說都是個大問題。人們應該如何看待 Devin 能夠接入什么樣的代碼庫?
Scott Wu:是的。所以我們要盡可能處理規(guī)模最大的代碼庫。作為工程師,我們思考大型代碼庫的方式通常是,更改或思考特定任務時,不會一次性記住每一行代碼,而是先形成高層次抽象概念,審視后逐步聚焦,再獲取更清晰的細節(jié)。
Devin 的工作方式與此非常相似:它首先會梳理出代碼庫的高層架構,理解其功能用途等基本信息,然后針對每個組件,它也能深入挖掘并提供更詳細的分析。比如 FP8 到 vFloat16 的轉換機制具體是如何設置的,代碼庫的各個組成部分分別發(fā)揮什么作用等。同樣,我們在設計時就確保了 Devin 的可擴展性。
Lenny:這基本上又回到了工程師作為架構師的觀點,Devin 正協(xié)助你理解架構。
Scott Wu:沒錯。我們發(fā)現了一個有趣的用例,用戶經常借助 Devin 來引導新加入團隊的工程師。剛加入團隊時,你對代碼庫和程序設置充滿疑問,有時向導師或經理提問會稍顯尷尬,尤其擔心問題幼稚。此時,直接詢問 Devin,瀏覽其生成的 wiki,理解內部表示形式,就很有幫助。
Lenny:這很有趣,又回到了你的觀點,Devin 不僅是初級工程師,而是具備「能力參差」的智能,像資深工程師一樣理解代碼庫。通常,你得詢問長期在此工作的工程師,這個東西是干啥的、在哪、怎么運作,而 Devin 在這方面的表現得令人驚訝。
Scott Wu:是的,檢索和處理大量代碼與 token 正是語言模型的強項,它能在你需要時提供幫助。
Devin Wiki 是我們上周剛推出的功能,與 Linear 完全集成。如果你在 DeepSeek 代碼庫有任務,只需要添加 Devin 標簽,Devin 就會給出對任務的看法。你可以查看每個特定文件,或它標記的重要代碼片段。若認可構建內容和結論,就可以啟動 Devin 會話,來實際完成任務。
Lenny:聽起來是個簡單想法,但本質上,你在說 Linear 中有修復和功能任務,現在 Devin 可以直接幫你搞定。
Scott Wu:這是個需要手動操作的過程。當 Devin 規(guī)劃任務或提供想法時,你當然希望參與其中。Devin 還會告知它的把握程度,比如對某個部分的理解可能性,這有助于加快進度。
正如你所說,很多產品經理喜歡用 Devin 和 Linear 更好地理解事物、代碼庫等。例如,Launch Darkly 的 Claire Vo 是 Devin 的重度用戶,她喜歡規(guī)劃任務,詢問數據相關問題,或者某個功能是否已合并到生產環(huán)境,又有多少人正在使用某個功能等。這是一種簡潔地獲取智能的方式。
Lenny:我喜歡它與 Linear 的集成,依然保持簡單。你可以添加一個小工單,比如將某個內容鏈接到主頁,Devin 能精準理解并展示。
Scott Wu:是的。Devin 看起來完成了工作。似乎 CI 方面出了點問題,它現在正在調試。但它已經提交了最初的第一版 PR,我們可以看一下。這是 Devin 的網站,顯然是在這個自定義部署中。我們這里有 Lenny's Newsletter。
Lenny:把這個部署到生產環(huán)境吧!太神奇了。
Scott Wu:Devin 顯然可以訪問我們的 Devin 代碼庫,它在這里做了很多工作,所以它對這里的所有部分都非常熟悉。
Lenny:很漂亮。是的,我喜歡它的樣子。它會帶來一些不錯的增長。你鏈接到我的網站,我們搞點 PageRank。
Scott Wu:是的。
Lenny:我的 Newsletter 有一個多么漂亮的網站啊。這是否就是 Devin 非常擅長的那種事情的一個好例子?比如,「這里有一個非常具體的關于網站的修改需求」。
人們應該如何看待 Devin 擅長的領域以及可能出問題的地方?
Scott Wu:我認為 Devin 在處理明確任務時表現出色,你應該給 Devin 分配任務,而不是問題。比如快速的前端功能請求、bug 修復、添加測試和文檔等。
讓循環(huán)變得非常好的一個因素是能夠快速迭代和測試。例如,直接調出預覽查看鏈接是否有效,Devin 也很容易做到這一點。
Devin 經常會登錄 Devin,啟動一個 Devin 會話,并確保它在我們自己的代碼庫上工作,這有點搞笑。但你通常想要一些容易驗證和容易測試的東西,這是最主要的。你也可以處理更大的項目或更大的請求。但在那種情況下,你應該預料到需要更多地引導 Devin,以確保它朝著正確的方向前進。
Lenny:這很有趣,因為這與人們談論合成數據和強化學習的方式非常相似,創(chuàng)建那些非常容易有明確答案的數據,是或否非常清晰。
在你們設計和構建 Devin 的過程中,爭論最多的是什么?
Scott Wu:我想到了幾個例子。其中一個我想說的是一個我稱之為 「我們應有多固執(zhí)己見」 的問題。
我們有各自常用的 Devin 工作流程,它能集成到 Slack 和 GitHub,在我們的代碼倉庫中為我們創(chuàng)建 Pull Request,響應問題報告等。當然,我們也會遇到很多其他各種各樣的情況,很多人在使用 Devin,創(chuàng)造出不同的用例,甚至有人用 Devin 點 DoorDash 外賣。而且還有許多人從頭開始構建很酷的網站,或者做類似的事情。
這對我們而言是一個有趣的權衡,我會這樣描述它:我們產品中構建的大部分功能肯定是針對創(chuàng)建 Pull Request 和工程團隊使用的用例。但我覺得,如果人們想將 Devin 用于其他目的,我們也會確保他們充分了解局限性以及可能遇到困難的地方。
生成式 AI 很有意思,我看到的最常見的創(chuàng)業(yè)建議之一是:專注于一個非常細分的群體,做那些無法規(guī)?;氖虑?,打造一個真正出色的用例,然后從那里開始拓展。我認為這在各個方面都是很好的建議。
但是,對于生成式 AI 而言,你很自然地會看到很多產品體驗最終會變得更通用。這是我們依然在反復思考的一個問題,我們也希望能夠做一些事情來支持其他類型的用例,來處理人們可能想用 Devin 去做的事情。
另一個問題是,Devin 應該在多大程度上成為一個完整的綜合項目體驗,還是更像一套組合工具?我們有 Devin Search、Devin Wiki,還有 Linear 工單范圍界定功能,這些工具是相互作用的。但隨著時間的推移,我們越來越將其視為一套工具。而且我認為,構建各種功能的智能體,即 Devin,是核心部分,這將永遠是我們工作的真正特別之處。
然而,現實世界的軟件共享需要一套復雜的工具,有很多不同的流程和諸多不同的用例是合理的。例如,你可以向 Devin Search 和 Devin 提出相同的問題,Devin 可能會馬上開始運作,但用戶有時更傾向于擁有控制權。
你可能正在設計一個編程任務,但還不希望 Devin 馬上開始這個任務。你只想問問 Devin Search,了解代碼庫的哪些部分可能相關,或者只提出看看相關代碼庫片段的請求,或者通過查看 wiki 了解現有的表示。所以,無論是在功能方面還是在用戶體驗方面,我們都發(fā)現這些功能隨著時間的推移變得自然而然且十分有意義。
未來智能體編程的體驗還會迭代 20 次
Lenny:在 AI 編碼領域,有多種不同的做法,你們全力打造 AI 工程師,但也有 IDE 公司和構建出色工程模型的公司?,F在連 OpenAI、Anthropic、Cursor 等都在構建 agent。你們如何定位自己,又如何看待在這個領域取勝的關鍵?
Scott Wu:我認為這些團隊都很強,它們由非常聰明和具有前瞻性思維的人組成,正在構建許多優(yōu)秀的產品。而且,我認為在未來幾年,隨著通用人工智能(AGI)逐漸實現,還有很多事情要做。
我非常喜歡的一句話是:2017 年,如果你問我們是否擁有 AGI,答案是否定的;而到了 2025 年,如果你問我們是否擁有通用人工智能,答案則是,你必須定義通用人工智能,而且這取決于你的研究領域。
這里觸及到的一個核心問題是,現在正在發(fā)生很多真正令人驚嘆的事情,很容易讓我們低估這場變革的巨大程度。
在過去 10 年 - 30 年里,有很多很棒的產品,它們讓產品構建生命周期中各種不同細分領域的各個環(huán)節(jié)都變得更容易了一些。
例如,有很棒的即時消息產品,日志記錄產品,計費產品,各種不同的工具。這些領域都將以數倍的速度發(fā)展,這將是一個數量級的轉變。
從我們的角度來看,我們一直專注在一個領域,那就是自主編程 agent。
這里有很多問題需要解決,比如核心能力方面仍然有很多工作要做,我們經常遇到這樣的情況:「Devin 為什么會做那個決定?任何人類工程師都不會那么做?!?/p>
在很多方面,比如產品界面,顯然有很多需要思考的地方,這不僅僅是我們正在努力實現的單一目標,而是會隨著每一次能力迭代而改變的東西,我估計未來智能體編碼的體驗還會迭代 20 次。
我們將在幾年內達到一個階段,那時你可能根本不需要看代碼,只需要查看并指定任務,然后說:「我們在這里加一個新的標簽頁,應該保存這些信息。啟動一個數據庫表,并在 X、Y 和 Z 列上建立索引?!鼓銓⒛軌驅崟r地與你的產品交互,并讓你的智能體為你打造這些功能。
從現在到那時,還會有很多代際更迭。但我認為,產品體驗本身每次都會改變,同時還有將其推廣到全世界的各種實際問題。所以,人們需要學習如何使用新技術。
同時,在部署以及處理現實世界軟件的各種復雜情況方面,還有很多工作要做?,F在仍然有很多 COBOL、Fortran 這類「古老」的語言。人們已經做了很多各種各樣的抽象和細節(jié)處理。
所以我們從一開始就一直專注于 coding agent。這是我們真正相信并為之設計的一件事,甚至延伸到了收入模式和基于使用量的設置,也融入了所有的產品體驗。
比如,你想在哪里與 Devin 交談?你希望能夠在 Slack 中與 Devin 交談,你希望從你的問題跟蹤器中啟動它,當然還有能力方面。
所以我不認為有一個簡單的答案,這是多種因素的結合。但這確實是我們過去一年半投入所有時間的領域,未來五到十年也將如此。
用戶粘性是關鍵「護城河」
Lenny:沿著這些思路,AI 領域一個普遍的難題是護城河和可防御性。當構建產品變得容易,而且很多東西都建立在自身發(fā)展如此迅速的模型之上時,你如何思考在這個領域建立護城河?
Scott Wu:我認為這通常更多關乎用戶粘性,而非護城河。通常人們所說的護城河是指某種能阻止競爭對手進入市場的東西。從宏觀層面來看,許多不同公司在 AI 譜系的不同層面,比如基礎模型實驗室或應用層等,我不認為存在任何能夠阻止其他人進入的硬性壁壘。
我認為真正存在的是粘性,我會將其定義為:一旦你用上一個真正喜歡的產品體驗,是否會興奮地持續(xù)使用它?
或者是否存在一種效應,即從現在開始,切換到一個新的產品并學習它也同樣容易?從這個角度來看,我認為編碼智能體有幾個尤其出色的方面。
首先,隨著時間的推移,存在很多固有的粘性和學習積累。把 Devin 比作人類工程師的話,第一天加入公司的工程師,與已經在公司工作了五年、自己寫了一半代碼、接觸過每個文件、構建過每個部分、且熟悉團隊其他成員的工程師,他們的產出是不可相比的。
Devin 也會真正學習并構建它對客戶的代碼庫、技術棧和流程的認知,并隨著時間的推移能夠做更多的事情。
另一方面,我認為非常令人興奮的是,我稱之為代碼的「多人協(xié)作」方面,確實有很多事情可做。這正是現實世界中很多事情的完成方式。
把 Devin 當成一個工程師,自己使用,這是一種用法。另外我們也經常看到,一些工程師與 Devin 一起工作并調教 Devin,人們會讓 Devin 幫助新工程師入職,并向他們傳授知識?;蛘呶視?Slack 中與 Devin 開始一個會話,我會說:「我們要做某某產品」;然后其他工程師會插話:「我們最初這么做的原因是 X 和 Y。Devin,當你做這個更改時,請確保仍然支持那個工作流程?!笵evin 會說:「好的」?;蛘?Devin 會創(chuàng)建一個 PR,然后其他人會審查那個 PR 或給出一些評論,Devin 也會進行相應的處理。
在軟件工程的各種場景里,Devin 為這樣一種體驗奠定了基礎:它能夠隨著時間的推移,為客戶整個工作提供的價值不斷增長。我們更多地思考的是:如何讓 Devin 在你使用得越多的時候,變得越來越有用?
Lenny:之前 Cursor 的 CEO Michael 也有類似觀點,他認為護城河或者說用戶黏性,就像 Google 做到的一樣:用戶切換成本低,關鍵在于做到最好。你是否認為,如果能在此基礎上創(chuàng)造出更強的粘性,讓用戶因為產品太好用、積累了知識并與你的工作流程深度集成而難以離開,那會更進一步?
Scott Wu:我認為軟件工程這個領域的一個好處是,無論好壞,都有一個非常清晰的價值衡量標準。至少在未來一段時間內,總會有一個清晰的下一個目標。
可能未來會有某個時刻,你可以對 Devin 說,幫我搭建一個完整的 YouTube,它真的能完成。而現在的 YouTube 背后,是數億小時的人類工程時間,他們構建了算法、基礎設施,以及每一個微小的細節(jié)。
而且,也許有一天 Devin 能以開箱即用的方式完成這個任務,雖然那將是很久以后的事情。
我認為開發(fā)者一個很酷的地方在于,他們真的愿意學習新的體驗,并投入努力,如果這意味著他們能夠獲得越來越高質量的體驗。
我們已經度過了 AI coding 的拐點
Lenny:在不泄露商業(yè)機密的前提下,是什么讓你們能把 Devin 做得這么好?是因為某個特定模型的突破嗎?有些人分享過,Claude sonnet 3.5 和 3.7 版本對他們的很多產品來說是一個巨大的突破。你們在架構或構建 Devin 方面,使其如此出色運作的關鍵是什么?
Scott Wu:我們很早就開始押注于智能體,我認為智能體比大多數人想象的要更早地變得可行和實用。隨著整個社區(qū)真正圍繞它團結起來,你可以在預訓練中看到它的影響,你可以在很多與這些模型相關的工作中看到它的影響。
從我們的角度來看,我不認為 Devin 的表現出現過任何單一的、階梯式的基礎模型轉變或其他任何導致天壤之別的變化。
但現在每周都會有新模型問世,這也對我們能做的事情產生了重大影響。在此基礎上,我們與基礎模型實驗室的研究團隊合作,在他們的基礎之上進行我們的工作。
所以,我想在這里給出一個大膽的觀點,我認為在基礎智能方面,基本上已經達到了我們的要求。我們不會自己預訓練模型,不會去提高模型的基礎智商,而是更多地教會它現實世界工程中的所有特質和細節(jié)。例如思考如何使用 Datadog,如何找出程序中的錯誤,如何處理每一種情況,如何創(chuàng)建 GitHub PR。
我們每天所做的工作中,都有非常多的細節(jié)和特殊性,這更像是教會模型去反映現實世界的復雜性,而不是讓它達到某種更高的、根本性的解決問題的水平。
Lenny:你曾經分享過一個關于以往顛覆性技術增長的觀點,那些技術非常依賴硬件,并且其增長存在限制因素,而 AI 則不同。
Scott Wu:出于多種原因,我認為 AI 將是我們一生中經歷的最大的技術變革。
但我想說的一點是,過去 50 年我們經歷的大多數重大科技革命,像個人電腦、互聯網和移動電話,它們都有一個重要的硬件組成部分,這在推廣普及中扮演了重要角色。
互聯網最初只是一些大學之間相互通信,但隨著時間的推移,整個世界都接入了互聯網,這花費了很多很多年。
移動電話也是如此,個人電腦也是如此。關于這一點特別有趣的是,我們已經看到了這種影響:在這些硬件中,有很多事情取決于實時性。
所以,那些為這些行業(yè)開發(fā)產品的人,都親眼見證了他們的市場隨著手機用戶和互聯網接入人數的增加而逐年穩(wěn)步成長,很多企業(yè)都是從行業(yè)初期就開始發(fā)展起來的。
像 Apple 和 Microsoft 幾乎是在同一時間創(chuàng)立的,很多偉大的互聯網企業(yè)或其他企業(yè)也是如此。它是一個隨著時間的推移觸及了整個世界,或者說觸及了整個世界很大一部分的事物,產生了非常巨大的影響,但它花費了數年時間才得以實現。
我認為 AI 已經顯現出的一大不同之處在于其技術的爆炸性增長潛力。
我認為我們已經穩(wěn)穩(wěn)地度過了 AI coding 的拐點,也就是說,作為一名工程師,如果你完全不使用 AI,你會被甩在后面。這是一種每個人都應該擁有和使用的技術,而且沒有任何硬件分銷的阻礙。這意味著這個領域正以指數級速度增長。
Lenny:Michael Pollan 有個有趣的觀點,陳詞濫調之所以是陳詞濫調,是因為它們太真實了。這就是為什么你會覺得,這個我聽過一百萬次了。我認為人們聽到這個會想。但實際上正在發(fā)生的事情是瘋狂的。這就是你在這里幫助我們度過這個轉變的原因。
Scott Wu:這是一個有趣的時代,這將需要真正的投資和真正的工作。但是,從我們的角度來看,作為工程師,這意味著與正在發(fā)生的一切保持同步非常重要。不僅是你學習和使用這些技術的能力,而且還關乎你教會 AI 關于你的代碼庫的知識,以便讓它能夠真正有效地與你一起構建,并做更多你想讓它做的事情。
把 Devin 當作你的「新同事」
Lenny:對于正在聽播客的公司員工來說,他們可能會想,我們公司應該使用 Devin。 你發(fā)現有哪些因素有助于幫助公司里的工程師獲得采納并能夠使用 Devin,無論是文化上還是操作上?
Scott Wu:我們經??吹降囊环N模式是,團隊中會有幾個人非常興奮,想要嘗試新事物,他們愿意投入時間和精力,并且非常興奮地想要把它搞起來。他們會完成所有的設置,他們會給 Devin 代碼庫的訪問權限,教 Devin 如何運行 lint 和 CI 以及所有這些細節(jié)。他們會從分配最初的任務開始,基本上幫助 Devin 建立一個立足點。
隨著時間的推移,最終人們會看到,Devin 正在寫所有這些 PR,正在做這些事情。
Lenny:「那個剛加入公司的 Devin 簡直是在瘋狂地產出 PR?!?/p>
Scott Wu:他們看到這些,自然會加入并獲得一個賬戶。當然,很酷的一點是,當他們加入時,Devin 已經對他們正在使用的代碼庫有了相當多的了解,并且正在與這些代碼庫協(xié)作。
所以,我們經常看到的一個非??岬氖虑槭?,那些早期采用者本身可以真正地為團隊中的其他人鋪平道路。
我想指出的主要一點是,這是一種非常不同的產品體驗。值得一提的是,我們仍然有很多可以做的事情,來讓它盡可能直觀、清晰地告訴人們如何使用 Devin,正確的步驟是什么,以及如何真正地從 Devin 中最大化價值。
你需要投入精力去理解,到底需什么才能讓 Devin 成功。我們發(fā)現自己隨著時間的推移,每一次更新后,我們都越來越多地使用 Devin。
Lenny:如果你能坐在每個第一次使用 Devin 的新用戶旁邊,在他耳邊悄悄說幾句建議,幫助他們更好地使用 Devin,你會說些什么?
Scott Wu:我認為最重要的一點是,真的把 Devin 當作你的新初級工程師來對待。我認為這是最重要的事情。
我認為人們進來,看到空白的頁面,會想到各種各樣他們想嘗試的東西。
通常我們看到的有效的操作是,你可以嘗試演示,你可以做一些事情。但很多時候是,我們弄清楚今天或這周我們想完成哪些任務,讓 Devin 開始處理這些任務。
我們從比較容易的開始,然后與 Devin 合作,了解 Devin 需要設置哪些東西才能測試自己的代碼并做得很好,然后隨著時間的推移逐步擴大規(guī)模。當你與你的工程師(Devin)一起工作時,你會更好地了解如何與他們溝通,或者哪些任務或項目適合讓他們參與進來,這確實是我們的核心理念。
Lenny:假設工程師每人有 5-10 個 Devin,他們就成了管理初級工程師的經理,這不一定是世界上最好的工作,因為它意味著大量的審查工作。至少你不必做績效評估和一對一談話。但這就像整天坐著檢查大量的 PR。
你成為了架構師,這有點像每個工程師最終都想成為的樣子。他們都會想「我只想搞架構,不想修 bug」你如何讓生活變得愉快、有趣、享受,基本上作為一個管理著未來可能有 500 個 Devin 的工程經理?
Scott Wu:我認為「砌磚工」與「建筑師」的對比更接近于體驗,而不是當經理。
管理當中遇到的很多困難,或者說人們回避它的原因,更多的是很多像上下文、所有權、責任之類的東西,然后還有各種情感方面的東西。
我認為與 Devin 合作更像是,擁有一個界面來交接任務和構建任務,找到合適的抽象層次,找到真正有效的工作流程。
我會做的類比是,當我們發(fā)明 Python 時,在很多方面,任務的描述和規(guī)劃,顯然是不同的范式。但我肯定認為,這遠非人們通常認為的那種「管理官僚主義」。
對于 Devin,很多時候更像是,找到你可以與之協(xié)作的正確抽象層次,找到運作良好的工作流程。你可以先讓 Devin 嘗試一下,如果效果很好,你就馬上合并。如果需要一些修改,你可以給出反饋。這更像是讓 Devin 成為你流程的一部分,而不是失去控制,我認為這是人們在管理方面最害怕的事情。
Lenny:你是否在考慮推出一個經理 Devin,來管理其他 Devin?
Scott Wu:有考慮過,Devin 可以通過 API 啟動其他 Devin,我們已經見過這種用例了。
如果你有一些大的任務想做,Devin 會分塊,你需要給它們相應的權限才能做到這一點。目前這還不是默認啟用的功能,但隨著時間的推移,這種情況會越來越多。
對于人類,用技術術語來說,上下文(context)和線程(thread)之間存在一種耦合。我的意思是,每個人只能在他們所做的工作上單線程操作,并且他們有自己的一套上下文。其他人可以同時做其他事情,但他們有自己的上下文。
但對于智能體來說,你可以讓一個智能體同時進行多條探索線,并且它們可以共享所有上下文。這還處于非常早期的階段,但未來我們會看到這一點。一旦我們達到那個階段,將會出現很多新的范式,等待我們去構建。
Lenny:你剛才提到的那個決定很有趣,是讓一個 Devin、且只有一個 Devin 做所有事情,它來分發(fā)任務;還是你有五個 Devin,每個都在做獨立的事情。這是一個非常有趣的決定。
Scott Wu:是的,當然。
創(chuàng)業(yè):總有三到五件事情,要做得比想象中更極致
Lenny:到目前為止,在構建 Devin 的過程中,你學到的最反直覺的事情是什么?那種與初創(chuàng)公司普遍認知相悖的。
Scott Wu:最近在我們構建 Devin 的過程中,我思考了很多。這其實不是我的第一家公司。對我們很多人來說,這都不是我們的第一家公司。我們團隊總共有 26 或 27 人,其中大概有 18 個人在此之前創(chuàng)辦過自己的公司。
我想到的一件事是,有一些在初創(chuàng)公司里你經常聽到的非常普遍的陳詞濫調,比如你必須快速行動,或者你必須雇傭優(yōu)秀的人才??偸怯心敲慈轿寮虑楸环磸吞峒埃鼈兪浅鮿?chuàng)公司的普遍認知。
我最初創(chuàng)業(yè)的時候,作為創(chuàng)始人,確實有這樣的想法。但是當你真正深入其中,投入了很多年之后,你會學到成千上萬其他你需要學習的東西。在這些不同的事情上,你都會遇到很多小的細節(jié),包括團隊建設、產品、戰(zhàn)略、工程決策、融資、銷售以及所有其他組成部分。
隨著時間的推移,我越來越覺得,要把公司做好,有時候僅僅是把那三到五件事情做得比你想象中還要極致。
每個人都說我們發(fā)展很快,但事實是,我們 2023 年 11 月辦了個黑客松,12 月又辦了一個,2024 年 1 月份正式成立公司,2 月份就把原型產品給初始用戶試用了,3 月份我們發(fā)布了產品,4 月份就有了第一批客戶。
我們在每一個地方都真正地加快步伐,這對我們來說真的產生了很大的影響。
是的,每個人總是說,你應該雇傭優(yōu)秀的人才,我認為背后的真理是,你應該不惜一切代價,去爭取那些你真正想引進的人才。
我最喜歡分享的一個故事是,我們有一位候選人來面試。他是麻省理工學院(MIT)的大三學生,非常年輕。我們給他安排了面試,他的表現比我們以往面試過的幾乎所有全職候選人都要好得多。
所以我們說:「你覺得休學一段時間,和我們一起工作,構建 Devin 怎么樣?我們認為你從第一天開始就能產生巨大的影響?!?/p>
他考慮了一段時間回來后說:「我愿意,我想這么做,但我的父母希望我能從學校畢業(yè)。我不確定有什么辦法能行得通。」于是我們談了更多,也了解了情況。
然后我們飛往北卡羅來納州,從機場直接去了他父母家,和他們以及他父母共進晚餐,我們聊了很多,試圖了解他們需要什么。他們說:「這聽起來是個很好的機會,但我們希望我們的兒子能夠畢業(yè)?!刮覀冏屑氂懻摿诉@個問題,并想出了一個方案:他可以全職為我們工作,但同時參加他必須上的課程,并完成他需要做的事情來拿到文憑。我們討論了這個問題,然后達成了一個大家都滿意的方案。我們直接回到機場,那是我第一次也是唯一一次去北卡羅來納州。
你雇傭優(yōu)秀的人是一回事,但真正永不放棄,并盡你所能為那些真正適合團隊的人創(chuàng)造條件,這才是關鍵。
他已經在我們團隊工作一年多了,是一位非常棒的工程師,沒有他,我們走不到今天。
類似地,我們還有另一個人,同樣是非常有才華的候選人,非常年輕,在很多其他公司都有很好的 offer,他將來也想創(chuàng)辦自己的公司。我們和他談論,很多顯而易見的事情,比如讓他見我們的投資者,或者讓他接觸客戶,或者看到很多其他方面,這樣當時候到了,他就有創(chuàng)辦自己公司所需的所有經驗。
但另一件重要的事情是,他已經在和很多很棒的公司談了,他不想破壞任何關系。所以我們和他一起,基本上手寫了他給其他所有公司的拒信回復,和他一起斟酌措辭,比如,「你應該如何表達,既表明你真的感謝他們付出的時間,又表明你顯然希望與他們保持密切聯系?!刮覀兊墓ぷ魇谴_保他足夠開心,以至于在不久的將來他不想離開。
你組建一個真正偉大的團隊的方式,是通過真正地為對他們來說正確的事情而奮斗。
Lenny:這些故事太不可思議了,它們讓「雇傭最優(yōu)秀的人才」變得如此真實。這就是雇傭最優(yōu)秀的人聽起來的樣子,這就是所需要的代價。
Scott Wu:我們非常努力地從頭開始重新構想事物,思考未來 5 到 10 年技術會走向何方?以及我們希望在未來扮演什么樣的角色?
Lenny:我在想,有一天人們會不會為了 Devin 而爭搶。
回到你說的三到五件事,這是非常棒的建議,你總是聽到要雇傭最好的人,快速行動,構建人們想要的東西。
Scott Wu:是的,構建人們想要的東西,盡可能地貼近你的客戶。
我認為另一件事是,始終思考事情未來的走向,而不是它們今天的樣子,尤其是在 AI 領域,事情發(fā)展如此之快,有這么多優(yōu)秀的人才。所以不僅僅是思考 10 年后事情會怎樣,而是思考下周會發(fā)生什么。事情發(fā)展非常迅速,很難預測。你真的必須對自己非常嚴格,思考那些事情,并在那個視角下評估你做出的所有決定。
Lenny:這里的重點是保持專注,感覺好像有 1000 件事情你應該做,但其實總是這 5 件事情。
在 AI 領域每個人都能成倍地放大自己的能力
Lenny:你還有什么想分享的嗎?還有什么想留給聽眾的?
Scott Wu:關于 AI 有很多不同的看法。我認為基本上涵蓋了所有可能的情緒。有很多恐懼,也有很多懷疑。我們自己也是非常持懷疑態(tài)度的人,總是想親自嘗試一下,才能真正看到并相信它。
對我來說,最主要的事情是,我對 AI 構建的產品非常樂觀,不僅僅是代碼和 Devin,而是整個領域以及所有正在完成的事情。每個人都能成倍地放大自己的能力。
這就是我們一直以來的思考方式,是我們思考我們正在構建的東西的方式。而且,我認為世界上還有很多事情要做。我不太擔心我們會用盡可做的事情。從這個角度來看,我們一直最興奮的事情是,我們所有人如何能做得更多。
Lenny:帶著這份樂觀,我們來到了非常激動人心的閃電問答環(huán)節(jié)。
第一個問題:你發(fā)現自己最常向他人推薦的兩三本書是什么?
Scott Wu:在非虛構類方面,對于創(chuàng)業(yè)者來說,我非常喜歡的一件事就是學習和理解硅谷的歷史。我們思考的所有這些東西,都是有人發(fā)明的。就像有人發(fā)明了種子輪的概念,有人發(fā)明了風險投資的概念,有人發(fā)明了 PMF 的概念。所有這些我們談論的不同原則。
為此,有一本書叫《The Power Law》(風險投資史),作者是 Sebastian Mallaby,我非常喜歡。它基本上就是對過去硅谷六七十年里建立起來的許多偉大企業(yè)和偉大產品的一次巡禮。
至于虛構類,我個人一直非常喜歡 F·斯科特·菲茨杰拉德的《了不起的蓋茨比》,這是我個人最喜歡的小說之一。
Lenny:你最近有沒有特別喜歡的電影或電視???
Scott Wu:我必須承認,我想不出最近看過的任何一部電影或電視劇。我期待著在 AGI 之后觀看很多很棒的作品。
Lenny:這必須放進預告片里。太棒了。我喜歡這個。這也顯示了你工作有多么努力,有多少事情正在發(fā)生,一切進展有多快。
你最近有沒有發(fā)現什么你真正喜歡的產品?可以是一個應用,可以是一個實物,可以是一把牙刷。
Scott Wu:我想說一個,我最近買了一個 Aura 相框。它就是一個展示照片的相框,你可以每天、每小時或者每 15 分鐘展示一張新照片,或者隨便你喜歡。我實際上非常喜歡它。我認為這是一種很好的方式,基本上就是一個能展示回憶照片的相框。
然后我想說的另一件作為通用物品的東西,它不是特別新,但我想說我認為 AirPods 實際上制造得非常好,設計得也很好。我現在意識到,我基本上在各種情況下都用它們。我在散步時接電話用 AirPods,我顯然在電腦前工作時也戴著 AirPods。它在很多不同情況下都運作得相當好。它們非常舒適,非常穩(wěn)定。
Lenny:是的,我要再次強調 Aura 相框。我也給我媽媽和岳母買了一個,它們對于和家人分享你孩子的照片真的非常棒。人們可能聽說過數碼相框,但 Aura 就是做得非常好,添加照片非常容易,而且它們看起來真的很漂亮。
Scott Wu:你可以想象,不久之后,我們會有 Aura 相框,只不過它把你所有的照片都變成吉卜力工作室的風格?;蛘咧皇窍胂笠恍┠阕鲞^的很酷的事情。
Lenny:酷。我相信它的拼寫是 A-U-R-A,如果大家想去看看的話。我們會鏈接它,非推廣。好的,還有兩個問題。
你有沒有最喜歡的人生格言,你經?;仡櫜⒃诠ぷ骰蛏钪杏X得有用?
Scott Wu:是的,我經常思考的一件事是,很多諺語實際上是相互矛盾的?比如,「物以類聚,人以群分」,然后你也有「異性相吸」。你覺得它們都是對的,而且它們通常都是對的。很多時候是關于理解為什么。
其中一個我覺得,尤其是在創(chuàng)業(yè)世界里,我?guī)缀跻恢痹谒伎嫉氖?,我認為專注和有驅動力非常重要,真正地最大化你的潛力。同時,不讓自己的個人情感與成功或失敗掛鉤也非常重要。
尤其對于初創(chuàng)公司來說,因為總有起起落落,老實說,即使是最成功的公司也是如此。這是一條崎嶇的道路,會發(fā)生很多事情,經歷很多。我思考了很多的一件事是,你真的想盡力而為,付出你的一切,并盡你所能去做。基本上,你想在場上傾盡所有。但同時,你也要能夠接受勝利和失敗。你希望能夠繼續(xù)前進,每次都進入下一個階段。
為了你自己的情緒狀態(tài)和精神狀態(tài),能夠做到這一點非常重要。我們犯過很多錯誤,我的第一家公司顯然很酷,但那里有很多棘手的地方。然后在 Cognition 的過程中,感覺好像已經把八年壓縮到了一年里,而且仍然以那個速度前進。但不知何故,它實際上也讓你更成功。
如果你不把它與你個人的價值聯系起來,你就更能付出你的全力,做那些能帶來成功的事情。
Lenny:這太有趣了。我最近剛錄制了一期播客,采訪了一位高管教練 Jerry Colonna,那是他的重要建議之一。這是一種非常佛系的方法,就是不執(zhí)著、不依附于結果。
Scott Wu:是的。
Lenny:好的,最后一個問題。Devin 這個名字背后有故事嗎?或者是否有其他名字曾是這個智能體的候選?
Scott Wu:Devin 這個名字很早就定下來了。我們從一開始就對編碼智能體感興趣。例如,我的聯合創(chuàng)始人是 Steven 和 Walden,我們當時有了這個想法。
我們在最初創(chuàng)業(yè)時,盡量擴大范圍,讓每個人都能跳出思維定勢,讓每個人先做一段時間自己的事情,然后我們再整合,吸取我們學到的所有東西。
Walden 制作了一個他的虛擬開發(fā)者版本,叫做 Dev Walden,然后 Steven 也做了一個他的版本,叫做 Dev Steven。我們把這些都整合到一起,它就是 Devin。
Devin 很早就確定了。我想說,我們確實有一個重大的決定,那就是 Devin 的形象應該是什么。正如大家所知,有那個六邊形的標志。實際上還有一只水獺,一只小水獺腿上放著一臺筆記本電腦,那也是 Devin。我們當時就用什么、不用什么爭論了一番。已經有一段時間了,但不知何故我們仍然同時保留著六邊形和水獺。
Lenny:你跳過了 Devin 的來源。
Scott Wu:Devin 它是一個開發(fā)者(dev),有點像當我們整合所有名字時,就很清楚了,這將是我們都喜歡與之合作的通用開發(fā)者(universal dev)。
Lenny:Scott,這次訪談太有趣了,我學到了很多。最后兩個問題,大家可以在哪里找到你或 Devin?還有什么你想告訴他們的嗎?聽眾如何能幫到你?
Scott Wu:我們的網址是 app.devin.ai。你也可以在 Twitter 或很多其他社交媒體上找到我們。我們非常希望聽到你對 Devin 產品的任何反饋。有很多東西需要弄清楚。
就像我說的,我們距離軟件工程的未來都還有 20 步之遙。所以聽到大家在試用產品時的想法,對我們來說意義重大。所以,如果有任何我們可以做得更好的地方,請隨時告訴我們。
Lenny:Scott,非常感謝你來到這里。
Scott Wu:非常感謝邀請我,我度過了一段愉快的時光。
本文為專欄作者授權創(chuàng)業(yè)邦發(fā)表,版權歸原作者所有。文章系作者個人觀點,不代表創(chuàng)業(yè)邦立場,轉載請聯系原作者。如有任何疑問,請聯系editor@cyzone.cn。