The Making of Devin by Cognition AI: Scott Wu

我是 Cognition AI 的 Scott ，今天我要和大家分享一下 Devin 的早期開發過程。我們目前仍處於非常初期的階段，同時我也會談談整個領域的現況以及未來的發展。我想先從一個示範開始會比較好。聽說你們有些人已經看過一些影片了，不過我今天特地為 World's Fair 準備了一個客製化的演示。

讓我來快速展示一下。今天早上，我匆忙地對 Devin 說：「嘿， Devin ，我想要你建立一個適合手機瀏覽的網站來玩名字遊戲。」我自己在記住名字和臉孔方面很有障礙，不知道你們是否也有這種困擾。我只是簡單地說，這裡有一個 TSV 檔案，裡面包含了許多名字和照片。這些都是本週 World's Fair 的所有講者資料。我要求它設計一個遊戲，顯示兩張不同的隨機照片，然後顯示其中一個人的名字，讓我猜哪張照片對應這個名字。我還給了一些關於遊戲運作方式的指示。

Devin 是一個完全自主的軟體工程師。這意味著 Devin 可以使用所有人類軟體工程師在開發類似專案時會用到的工具。 Devin 首先會制定一個計畫，你可以在這裡看到一個基本的規劃。有趣的是，這個計畫會隨著時間不斷調整。當獲得新的資訊或回饋時， Devin 會相應地更新計畫。

之後， Devin 就像人類工程師一樣開始執行這個專案。你可以看到， Devin 為名字遊戲網站建立了一個新目錄，啟動了一個新的 React 應用程式。它使用所有相同的基本元素，致力於建構網站並撰寫程式碼。 Devin 會讀取 TSV 檔案來了解資料內容，然後就開始全面性地工作並逐步完成任務。

幾分鐘後， Devin 部署了第一個版本。讓我快速打開來看看。這就是它的樣子。雖然接近完成，但還不太理想，對吧？它仍然直接顯示名字，我想可能是我沒有把要求說得夠清楚。不過你可以點擊名字，然後得到正確答案。

於是我用簡單的英文給了它更多回饋。我說：「嘿，你能不能在我點擊答案之前隱藏兩個名字？還有，你可能需要重新設計『再玩一次』按鈕的樣式，它在頁面上看起來有點不協調。」我不斷地給予更多回饋。我還問它：「你能不能添加一個連勝計數器？記錄我連續答對的次數，如果答錯就重置為零。」還有一些其他的小要求。

最後 Devin 部署的網站就是你現在看到的這個。舉例來說，這是 Justine 的照片。它會記錄我的連勝次數，你可以看到……

這個遊戲的難度正在逐步提高。舉例來說，如果我故意答錯一題，你會看到連勝次數重置為零，然後遊戲繼續進行。我實際玩了這個遊戲，學會了每個人的名字，這對我來說非常有幫助。你們也可以試試看，遊戲就在這裡。它包含了本週 World's Fair 所有約 170 位講者的資料。

這是一個很酷的例子，但我想強調的是，如果軟體工程變得如此簡單，能夠用簡單的英語表達需求就獲得結果，世界將會有多麼不同。雖然這看似只是一個玩具般的應用，但可能還是有其用處。事實上，我們在開發 Devin 的過程中一直在使用 Devin 。順帶一提，這個網站當然不是我親手製作的，我只是告訴 Devin 「幫我做一個帶 QR 碼的網站」，然後 Devin 就完成了。

讓我給你們展示一個我們在實際生產環境中使用 Devin 的例子。你可以看到這裡有一個完整的搜尋欄，還有所有的會議資訊，你可以跨會議進行搜尋。這些都是 Devin 在其程式庫中製作的。這裡你可以看到我們團隊成員 Bryce 要求 Devin 在 Devin 會議列表中建立一個搜尋欄組件。

這裡有一些特別為生產環境程式碼庫設計的功能。 Devin 從一個 snapshot 開始工作，我們載入了一個克隆的機器實體。它有一個工作手冊，所以它了解我們程式庫的許多細節。而且它能在我們的 Git 環境中自如工作，你會看到它提交 PR 並與所有相關工具互動。

讓我快速解說一下過程。 Devin 回應說「沒問題」，然後提交了第一個 pull request 。 Bryce 繼續給予指示。再強調一下，你只需用簡單的英語提供回饋。 Bryce 說：「這是個不錯的開始。現在你能加個放大鏡圖示，讓它看起來更符合慣例嗎？可以使用 phosphor 庫，具體怎麼做由你決定。」 Devin 回答說會照做。 Bryce 又說：「順便說一下，不用測試了，我相信你。」 Devin 還提到它正在處理登入過程的一些問題。你看，這就像是在跟另一個工程師合作一樣。 Bryce 回應說：「好的，兄弟。」

最後， Devin 完成了所有工作並提交了 PR 。這個 PR 實際上被合併了，就是你現在看到的搜尋欄。同樣地， Devin 的許多 API 整合功能也是它自己開發的。我們公司內部的許多儀表板和 Devin 內部的指標追蹤系統，實際上也都是由 Devin 建立的。看著 Devin 與公司一起成長，共同建設公司，這種體驗一直都很有趣，真的很酷。

我想和大家分享一下我們至今的發展歷程，以及 AI 領域的最新動態。我們公司成立於去年 11 月，到現在已有 7 個月的時間。有趣的是，我們是在舊金山灣區伯林格姆市的一個駭客屋開始創業的。當時我們這群人其實已經一起生活了一段時間，每個人都有自己在 AI 領域的經歷。我們都知道想要一起打造些什麼，而且很清楚要在程式設計領域有所作為，開發一個程式設計代理。

之後，我們在灣區和紐約之間來回奔波，每到一處就住進一個駭客屋。這種生活持續了將近 7 個月。我想我們現在終於要在灣區安頓下來了。每次搬家，我們都會租一個稍大的 Airbnb，因為團隊規模也在逐漸擴大。

那麼，為什麼我們要開發 Devin 呢？這是一個我特別感興趣的問題。我們都知道，語言模型已經發展得相當成熟了。我通常把這些文字補全產品稱為第一波生成式 AI。這很容易理解，因為語言模型的介面本質上就是文字補全：你給它一個開頭，它就幫你完成剩下的部分。想想看 ChatGPT、各種問答產品、行銷文案生成器、客戶服務回覆系統，甚至像 GitHub Copilot 和 Cursor 這樣的程式設計輔助工具。這些都是非常優秀的產品，也是語言模型的自然應用場景。你提供一個前文，要求模型完成後續內容，它就為你完成這個任務，這確實是個很有用的工具。

但我認為我們正在進入一個新的階段，不僅僅是補全文字，而是引入一定程度的自主決策能力。在我們的領域，這通常被稱為「代理」（agent）。這種技術帶來了許多新的可能性，當然也對一致性提出了更高的要求。這個領域特別有趣，因為它不僅涉及核心技術能力的提升，讓 Devin 能夠解決各種問題，還帶來了有趣的產品設計挑戰，因為代理的使用者體驗是一個全新的領域。

那麼，為什麼我們特別選擇了程式設計領域呢？有幾個原因。首先，我們都是程式設計愛好者，都是工程師，所以教 AI 寫程式是我們能想到的最酷的事情之一。但除此之外，我們認為程式設計代理特別有潛力，原因如下：首先，顯然成為一個軟體工程師遠不止於會寫程式碼那麼簡單。實際上，大部分工作內容是...

在軟體工程中，你的任務往往是調查一個 bug。這個過程包括檢視程式碼庫中的各個檔案、執行不同的指令、查閱文件，甚至親自運行前端來重現 bug。你觀察、編輯、再次測試。這些工作正是軟體工程的核心，遠比單純在檔案中輸入程式碼複雜得多。這種工作流程自然而然地引導我們走向代理式的操作方式。

與此密切相關的是通過程式碼回饋進行迭代的能力。想像一下，如果你面對一個龐大的生產環境程式碼庫，裡面有成千上萬個檔案、數十萬行程式碼，而你被要求修復一個特定的 bug。這對大多數人來說都是一項艱鉅的任務，對 AI 來說也不例外。在實際工作中，我們會添加 print 語句、查看日誌、檢查監控數據，在不同檔案間來回切換以診斷問題。每一步你都在做決策，然後執行程式碼來驗證結果。這種迭代過程讓你能夠更有效地解決問題，而這種方式也非常適合 AI 代理。

值得注意的是，代理的能力正在飛速提升。僅僅兩年前，像我們現在展示的這個名字遊戲 demo 都幾乎是不可想像的。考慮到這個領域的快速發展，包括數據、訓練方法等各個方面，我們可以期待兩年後會有更驚人的突破。

然而，除了技術能力的提升，我們還面臨著深層次的使用者體驗（UX）設計挑戰。當我們開發代理時，我們這些從業者都還在摸索階段。我們最初的想法往往是參照現有的軟體使用方式或人與人之間的交流模式。比如，Devin 的許多功能設計就像是在觀察你自己的實習生工作一樣，你可以看到他們的螢幕，了解他們執行的指令等。

但實際上，AI 代理與傳統軟體或人際交流有很大的不同。在並行工作、資訊收集、上下文管理等方面，代理有其獨特的特性和需求。這為產品設計帶來了全新的挑戰。為了讓大家更好地理解這一點，我們可以列舉一些...

我們在產品中整合了諸多功能，其中最基本的包括 Devin 能夠使用指令列、編輯程式碼和瀏覽網路。然而，除此之外還有許多進階功能，例如能夠分支（fork）和回復工作階段、與 Slack 和 GitHub 進行整合、處理操作手冊（playbooks）、儲存機器 snapshot、管理機密資訊，以及使用適當的工具進行驗證等。這些都是產品迭代過程中不可或缺的一部分，而這個過程本身就已經是一個極其複雜的挑戰。坦白說，我認為隨著時間推移，我們還會看到更多的迭代和創新。

我想特別介紹一個我們最近剛推出的新功能，那就是使用 Devin 的虛擬機器的能力。這項功能在當前的軟體生態中可能找不到太多類似的對應，但它允許使用者在 Devin 的機器上進行 VS Code 即時共享。假設你想與 Devin 協作，你可以直接告訴它：「嘿，這幾行程式碼需要修改，我已經為你做了編輯。」然後你就可以直接與 Devin 討論並完成這項工作。這個領域還有很大的發展空間，有許多可以優化和改進的地方。

另一個值得一提的是 Devin 如何徹底改變了我們的工作流程。你們看到的 Devin 建立搜尋欄的例子只是冰山一角，實際上我們現在以更非同步的方式處理任務。Devin 的一個重要特點是，如果一個工程師今天需要處理四個不同的任務，他可以將第一個任務分配給 Devin 1，第二個給 Devin 2，依此類推。這樣，你就有四個 Devin 同時並行工作，這幾乎就像是將每個工程師轉變成了一個工程經理。

我會將這些 Devin 比喻成非常熱情的實習生。他們很勤奮，但顯然並非無所不知。他們可能會在細節上犯錯，會問很多問題，但你可以與他們每一個合作，不斷地進行迭代和改進。

這裡有一個有趣的實際例子，就發生在今天早些時候。我們在討論某個特定功能的開發，在這個案例中，是一個相對簡單的更改顏色的任務。我只需在 Slack 的對話中說：「嘿，@Devin，你能改變這個東西嗎？」然後 Devin 就會製作一個 Pull Request，之後我只需點擊合併即可。

這種工作方式帶來的便利性是驚人的。即使我們在健身房或車裡，現在也可以實際編寫程式碼，因為你可以告訴 Devin 你想要它做什麼。雖然你沒有帶著完整的電腦設備，無法親自輸入所有指令，但能夠向 Devin 描述你的需求，然後在稍後審查程式碼，這種方式實際上效果很好。

那麼，接下來會發生什麼？這無疑是一個極其重要的問題。

顯然，目前的技術仍處於非常早期階段。但我們不禁要問，幾年後這些技術會發展到什麼程度？軟體工程又會有什麼變化？這個問題一直存在許多不確定性。隨著我們越來越多地使用 Devin ，我們發現一個顯而易見卻重要的事實：Devin 並不是決定要做什麼或建立什麼的決策者。軟體工程的核心部分仍然存在。

我會這樣描述：每個軟體工程師實際上同時在進行兩項工作。第一項是用程式碼解決問題。你面對一個問題，需要詳細分析要建立什麼樣的解決方案、使用什麼架構、考慮所有可能的流程、細節和邊緣情況，並設計出精確的解決方案。第二項工作是，一旦有了方案，你就要處理偵錯、實現不同的功能、撰寫單元測試等實際落實的工作。

目前，平均的軟體工程師可能只花 10% 到 20% 的時間在思考部分，而 80% 到 90% 的時間則用於實現。而 Devin 的作用正是讓你有更多時間專注於思考部分。雖然 Devin 還處於早期階段，但我認為隨著它的進步，我們會看到更多這樣的情況：Devin 幫你處理實現的部分，讓你不必去弄清如何設置 Kubernetes 、偵錯失效的 API 、處理版本變更或資料遷移等耗時的任務。相反，你可以將所有時間用於思考如何解決眼前的問題，更像是技術架構師和產品經理的結合。

因此，我認為我們所稱的「軟體工程」這份工作將會改變。但實際上，我們可能會需要比以往更多的軟體工程師。這種趨勢是有先例的：從前，程式設計意味著使用打孔卡，後來是組合語言，再後來是 C 語言。隨著技術演進，雖然大多數人不再使用打孔卡，但程式設計師的數量反而增加了。

容易被低估的是，需要撰寫的程式碼數量正在激增。這很有趣，因為顯然我們在座的都熱愛軟體。我認為軟體在過去 40 到 50 年裡一直是推動世界進步的首要力量。儘管如此，我認為我們對軟體的需求仍在持續增長。

實際上，未來需要開發的軟體數量可能比我們目前的產出多出十倍以上。因此，我認為未來將會發生的是：軟體工程的力量將會開放給更多人使用，而每個軟體工程師的效率都可能提高五到十倍。但與此同時，我們實際上會進行更多的軟體工程工作。很好，這就是我要分享的全部內容。現在，我們很樂意開放提問時間，如果大家有任何問題的話。是的，就是前面這位。

很好的問題。我們一直在逐步擴大使用權限。每週我們都在讓更多人加入使用。我們也在持續擴大與企業客戶的合作規模。我們有很長的等候名單需要處理，所以我們正盡可能快地進行。但我們希望能盡快讓你們獲得使用權限。

是的，那邊最後面穿紅色衣服的。

問題是：我想知道 Devin 在後端有多少權限來執行程式碼？你們如何下載它並將其放入狀態生成器中？

是的，沒錯。以我們的程式碼庫為例， Devin 已經擁有它所需的所有設置。它有一台基本上已經實體化的機器，可以執行開發環境、伺服器和前端。所以如果你要求它偵錯某個特定的問題，它會自己調出來重現問題，然後進行偵錯並再次嘗試。就是這樣。

還有其他問題嗎？這裡有人要提問嗎？

好的，有人問道，隨著這些較簡單的任務被解決，那些顯然需要學習如何編寫程式碼的初級工程師或實習生會面臨什麼情況？

我認為實際上會發生的是，需求會隨著供給持續增長。培訓過程可能會有一些改變。但是，那些核心基礎知識仍然至關重要。當我們說某人是一個非常優秀的工程師時，通常不是指他們打字很快（儘管他們可能確實如此），而是指他們對問題有非常好的理解，了解所有不同的架構，從不遺漏任何邊緣情況等等。這些基礎知識永遠都會很重要。我認為，實習生或初級工程師將有機會更早地接觸和運用這些基礎知識。

有人問到，實現未來套件願景的最大挑戰是什麼？

你知道，挑戰有很多。基本上涉及所有方面，包括速度、一致性、使用權限、整合、正確的產品使用者體驗等。我認為所有這些方面都呈現出一種普遍的上升趨勢，這一點非常令人振奮。因此，我們顯然會盡最大努力。

然而，每次新的硬體發布都令人驚嘆，每個新的基礎模型問世都讓人驚豔，每項新的人工智慧代理研究都令人讚歎。我認為，這種情況下，我們將會看到在技術堆疊的不同層面出現各種優化，使得人工智慧代理的運作流程不斷改進。雖然這不會只是一個小小的改變，但我相信進展會相當迅速。好了，我們的時間到此為止。非常感謝大家的聆聽和參與。