代理式程式設計：業界主管圓桌會議

大家好！

這週或過去兩天，您聽到了許多 Android Google 員工的分享。

因此，我們認為在會議結束前，聽聽 Android 開發人員社群等外部人士的意見，會是非常棒的做法。

我們將討論代理式程式設計，以及這項技術對現實世界的影響。

首先，我們來自我介紹。

我是 Android 開發人員關係團隊的 Ben。

大家在這次會議中已經聽過我的發言，現在請與談人自我介紹。

大家好，

我是 Vinay，負責 Databricks 的 AI 工具開發工作。

很高興來到這裡。

大家好，我是 Luis Artola。

我在 Google 地圖工作。

我帶領的團隊使用 AI 建構代理式體驗，並改善軟體開發週期。

大家好，我是 Annyce Davis。

我在福特工作。

我帶領一些工程團隊，負責開發訂閱和會員產品。

大家好，

我是 Ty Smith。

我在 Uber 負責支援開發人員。

這項技術在行動裝置上已行之有年。

過去幾年，我們一直致力於開發 AI 工具，迎接這個令人興奮的新時代。

大家好，

我是 Kaushik Gopal。

我是 Instacart 的首席工程師，剛好開始製作這個名為 Fragmented 的 Android 開發 Podcast。

正如 Ty 所說，我們最近稍微調整了策略，開始討論 AI 開發。

現在我們來做個小測驗

我們有 30 分鐘的時間。

時間應該會過得很快，所以我們直接進入正題，提出一些難度較高的問題。

Android 開發人員關係團隊一直以來都希望讓應用程式建構作業更快速、更輕鬆。

現在 AI 已經問世，正如我們所說：「這確實是

我們認為這能更快速、輕鬆地建構應用程式。」

不過，我想提出一個問題：我們是否真的能更快推出應用程式，還是只是產生了一堆無用的程式碼？

Vinay，我們走吧。

好的。

對，我們都在看著彼此。

太棒了！

因此，如果只看純數字，我們肯定會發現，在 PR 和程式碼行數方面，輸出速度大幅加快，因此，在儲存程式碼等問題上，我們也面臨了擴充挑戰，對吧？

因此，加速發展是必然的趨勢。

但對成效的影響則不明顯。我認為整個產業都在試圖找出合適的成效指標，以及如何瞭解成效對收益的影響。

但我確實看到它在運作。

我認為我們在過去六個月內推出的程式碼，比過去更長一段時間還要多。

因此，我認為我們在評估工作效率方面的策略也有所改變，對吧？

因為有很多種思考方式。

我們正在設法提高中位數，對吧？

因為當你觀察極端值和中位數時，會發現這兩類人之間有 5 到 10 倍的差距，而我們的重點是提高下限、提高中位數，讓這些人的工作效率與周遭的同儕一樣高。

我們可以看到多種角色。

有些人的進度則快得多。

有些人一天能完成上百個 PR，工作效率驚人。

但這就是他們運作的空間。

這可能是因為他們更常接觸新領域，或更熟悉工具。

我們也看到許多人更偏向棕地或平台工作，他們支援的工作類型可能沒那麼快，因為他們必須花更多時間進行人為判斷，確保不會出錯。

兩者結合後，速度明顯比以前快，但我認為真正有趣的話題是，即使我們推出更多功能，企業是否真的向使用者推出更多功能？

過去一年來，我們一直致力於瞭解是否能更快推出功能，而不只是更快推送程式碼。

早期跡象顯示我們確實有，但這與純粹的 PR 相比，看起來非常不同。

我認為，顯然大家都在推送更多程式碼，例如 PR 數量有所增加。

但我想即使是現在，許多人還是會思考「如何運用 AI 和現有工具，大幅提升現有流程的效率？」

對吧？

舉例來說，以前我們推送程式碼時，總覺得需要有人一路引導，直到正式環境。

但我想我們現在看到的是，沒錯，這確實有效。

我們正在推出更多功能。

但我們也遇到各種瓶頸，這些是以前不曾出現的問題。

因為我們過去從未遇到這些問題，但現在，我們正在加速多步驟週期中的某個部分，我認為這正是令人感興趣的地方，就像是「好吧。

我們現在能提供更多特效，但就像是從消防水管噴出的水一樣，數量多到難以控制。」

因此，我們面臨其他挑戰。

這點很有意思，因為仔細想想，雖然步驟很多，但從宏觀角度來看，可以分為三個階段，對吧？

首先是程式設計，這項工作明顯加速。

正式版完備性包括法律、隱私權等許多事項，以及讓您推出產品的事項，然後才是發布，對吧？

此外，運送方式也會因所在地區而異，對吧？

如果產品完全在伺服器端運作，推出產品可能代表更精簡的流程，但如果是推出消費者使用的產品，實驗階段只是過程中的一部分，對吧？

你還是需要進行許多實驗和評估，這就和你的說法有關，感覺就像是在大都會區的高速公路上，遇到瓶頸，然後開始加速，你會覺得「太棒了，

我跑得很快」，但現在你遇到了下一個瓶頸。

AI 讓摩擦點變得更明顯，其中有些與程式設計或技術無關。

而是與流程和人員有關，以及如何運用 AI 進行最佳化。

如何簡化端對端流程，是個非常有趣的挑戰。

我們對這個領域的看法是，個人或團隊在完整推出產品方面有多少自主權？

因此，如果我們從內部來看，你知道，有很多團隊可能正在建構內部工具，或者是不會交付給客戶的東西。

出貨速度快多了，對吧？

他們有權立即將這些內容提供給客戶。

如果外部產品仍須經過使用者實驗，或應用程式商店推出時間，或與設計和產品合作，所有這些其他瓶頸都會增加，而編寫程式碼的人員在快速移動方面的代理權要少得多。

因此，他們只是在系統中遇到其餘的瓶頸。

因此，我認為將這些內容分成兩個不同的領域，確實能突顯業務流程可以改進的地方。

沒錯，我同意。老實說，工程技術從來不是瓶頸。

我多年來一直這麼說。

工程部門做事非常嚴謹，而且總是從業務角度出發，思考「問題是什麼？」

你會得到 10 種不同的答案。

然後說：「好的，

現在，我們來看看如何運用產品解決這些問題。

現在，讓我們花點時間思考這個問題。

我們來談談設計吧。

把球踢過去。」

等到工程團隊接手時，我們大致上已經知道該怎麼做。

然後，我們就試著前往 Stack Overflow，複製並貼上一些內容，然後將其發布。

因此，我認為 AI 在法規遵循工作方面的加速效果最為顯著。

例如一直想翻新某個項目，或快速升級 Spring Boot 版本。

我們正在快速進行。

但實際功能推送方面，我認為沒有顯著改善。

所以，你們都提到瓶頸可能已經轉移，而且你們遇到的這些程序以前並不是瓶頸，但現在卻成了瓶頸。

不過，這些程序可能都是從過去的慘痛教訓中學到的，對吧？

所以，您是否感受到改變這些做法的壓力？我想最明顯的就是程式碼審查。

我們認為程式碼審查的未來發展為何？

我們目前採取的行動

我很想聽聽你的看法。

這又回到我剛才提到的重點。

我認為許多瓶頸是因為我們認為，如果你有魔杖，可以重新發明軟體工程，而且你現在有 AI，對吧，我們會使用很多相同的東西嗎？我們會做同樣的事情嗎？

舉例來說，程式碼審查需要人工審核，才能通過審查，例如進行最後的交叉檢查。

我認為這點也正在改變，例如，我們現在對程式碼審查的看法是，也許我們應該抱持開放態度，例如，如果你要重構名稱，或嘗試重構程式碼，而且你知道自己有很棒的測試，每個人顯然都有。

我們有 AI 可以寫，沒問題。

不，我的意思是，你是否能比那個代理做得更好？

我不知道，也許就不要花時間審查。

不過，如果你要發布錯誤，而執行長打電話給你，基本上是說：「嘿，這件事讓我們損失了 X 美元」，也許可以找出「嘿，這是關鍵領域」等領域和系統。

這不是重要區域」，然後嘗試重新構思。

我想我們現在不是這樣運作的，對吧？

現在則是「嘿，有 PR。

我是工程師。

我專注於這件事。

價格會上漲。

我會在半夜打擾 Vinay，請他幫忙進行程式碼審查，因為我只想盡快合併程式碼。」

相較之下，我們可能需要重新思考許多這類問題。

我完全同意，我認為程式碼審查是驗證問題。我的意思是，如果我對自己驗證某項內容的能力充滿信心，我還會對所有 PR 進行程式碼審查嗎？

應該不會吧？

因此，程式碼審查有兩個目的。

一個是確認我們做的是正確的事，另一個是教育，對吧？

例如周遭的人知道你在做什麼，以及他們是否同意你的決定。

因此，我們絕對可以放心加快這類工作的速度，並確保這些工作能順利進入程式碼，甚至發布。

雖然這可能不適用於所有情況，但我認為適用於絕大多數情況。

我認為我們已準備好做出這些改變，而我們整個社群也必須確保系統已做好準備，因為這一天即將到來。

這是無法避免的。

漏斗頂端非常寬，有各種平台可讓您建立更多 PR。

而您的速度取決於流程中最慢的步驟。

對許多團隊來說，這就是程式碼審查，而動作較快的團隊確實已瞭解並接受這個事實。

沒錯，老實說，我認為 70% 的 PR 看起來都不錯。

如果我們搜尋全世界所有的程式碼集，PR 評論就會是「看起來不錯」，LGTM，到處都是。

所以，部分原因在於，身為工程專業人員，有時我們會給自己過多的功勞。

我們認為自己已經達到這個目標。

「他們是否使用指令模式？」

而是會說：「好的，

嗯，看起來不錯。」

那麼，為什麼不能讓代理執行這項操作呢？

我認為這就是未來的趨勢，我們會看到「我覺得很好」的標準是什麼，例如哪些特徵、哪些行為會讓你產生這種感覺？

然後確保代理會尋找相同的內容。

或者，也可以嘗試從不同角度思考，對吧？

我認識一些人，他們最近在 Twitter 上說了這件事，對吧？

例如，現在驗證 PR 時，可以讓代理以不同方式呈現，對吧？

Hey, show me a before.

顯示改造後的樣子。

請提供你編寫的測試，而不是逐行檢查程式碼。

但這確實會挑戰…Luis，你剛才想說什麼嗎？

不，我認為這很值得思考，對吧？

這樣一來，您就能放心讓 CL 或 PR 通過，不需人工介入。

我想唱個反調，談到摩擦時，大家往往會認為摩擦是不好的，但其實摩擦有好有壞。

我認為評論仍屬於良性摩擦。

重點在於如何減輕開發人員的負擔，對吧？

有時，我們不只要思考如何讓當下的審查更完善或更有效率，

而是如何運用 AI 讓上游開發更精準，對吧？

因為如果只是根據你使用 AI 的方式，例如好的輸入會產生更好的輸出，但壞的輸入會產生真正的垃圾，對吧？

因此，我認為要達到理想的最終狀態，必須從一開始就全面運用 AI 改善流程，包括使用 AI 深入瞭解架構、制定更完善的規格，同時減少開發人員的工作量，進而提高產出的程式碼品質。

因此，開發人員在審查過程中遇到的阻礙較少。

我認為這項技術的最終狀態不會引起太多爭議，因為大多數人都會發現，所有程式碼最終都會在沒有人工審查的情況下上線。

我認為，與此同時，我們正處於一個不斷發展的局勢中，模型越來越好，我們不太擔心它們會犯技術錯誤，而更擔心它們會犯商業錯誤，或者進入其中的判斷或構思是問題所在。

因此，這也會納入信號，您需要在審查階段將其區分出來。

例如，我們應該在 PR 中逐行審查，還是審查他們試圖推送的意圖？

我們正在思考幾種不同的做法。

首先，我們如何提供更相關的資訊，讓使用者能開始排定優先順序？

另一個問題是，哪些領域較安全，可讓我們進行實驗，並在這些計畫中加快進度？

正如 Kaushik 所說，並非所有領域都需要相同程度的嚴謹性。

我們能辨識出這點，並開始加快某些項目的速度，降低風險，同時在更注重法規遵循或非常基礎的領域，保持較高的摩擦力，直到我們真正信任模型，以及輸入模型的資料

都是正確的決定。

例如在 Uber 應用程式中重構新的 Android 模組，或許可以。

所有 Android 開發人員都能免費搭乘，你可能需要檢查一下程式碼。

我得向執行長確認。

抱歉，Kaushik。

但我認為這個問題已經解決。

我們已經有類似功能旗標。

我們已經有藍綠部署。

我們已經有很多拼圖了。

但我們一直太忙，沒時間真正著手。

我們已有行為追蹤功能。

我們有各種資料，但分散在不同系統。

我們已經在追蹤事件。

我們有大量資料，但缺少將所有資料整合為一的全面追蹤。

一旦我們終於弄清楚這種工程背景服務在所有這些不同公司中的樣子，我們就不必再擔心了，因為即使 PR 只是合併，它也是安全的。

因為我們知道，好吧，我們已經在功能旗標後面了。

我們有藍綠部署。

我們已具備所有觀測能力。

這樣一來，你就能自信地說：「喔，把它放進管道中。」

如果發生不好的事，我們沿途有所有這些守衛和閘門。

我認為回應速度也非常重要，對吧？

舉 Android 為例，如果您在 Android 推出變更，且該變更需要透過 Play 商店發布，然後再推送給消費者，那麼您立即 hotfix 的能力就會受到限制。相較之下，如果您在內部部署，並具備內部觀測能力，且有代理程式立即處理，您就有更多機會能更快採取行動。

所以，我想問各位的問題是，這些應用程式也需要進行一些工作，但綠地應用程式比較容易，然後還有棕地應用程式，然後在某個時刻，您需要花時間進行許多檢查，以便擴大 AI 的使用。

我知道你們很多人都在開發大型應用程式，對吧？

我想知道您對這點有何看法？

是像「嘿，執行長，給我 3 個月的時間，讓我把這個應用程式準備好，可以運用 AI」，還是每天都加入一點？

是啊

反正他們從來不這麼做。

應該沒有。

大多數公司都無法享有這種優勢。

我認為我們只需要像過去處理技術債一樣，投入同樣的時間，例如將 20% 的時間用於這方面，就像將 5% 的時間用於改善提示一樣。

甚至能理解提示的作用，並提供更完善的背景資訊。

正如我們之前討論過的，我認為很多時候，工程師仍不瞭解其運作方式。

他們仍覺得這項技術很神奇、很神祕，因此不會設定和調整，以充分發揮其價值和效率。

因此，我認為領導者必須思考：「我們需要採取哪些行動來提升團隊能力，讓他們瞭解這項技術的運作方式，進而獲得更多效益？」

也是延續。

因為變化太快，如果我要求團隊花一週時間學習最新、最棒的技術，並付諸實踐，但他們沒有時間繼續學習或實驗，那麼明年我們再檢查時，他們就會遠遠落後於新功能。

因此，我們必須在飛行時建造飛機，也就是在過程中設定安全措施、學習和調整，團隊也需要掌握最新動態。

在大型組織中，有些團隊 (例如我們) 會嘗試提煉部分資訊，讓資訊更貼近生活、更容易理解。

但這是目前業界所有人都面臨的挑戰。

我想稍微調整一下。

你們許多人都在開發人員基礎架構等領域工作。

數千個 PR，你的測試基礎架構、伺服器，是不是都快崩潰了？

我也很想聽聽一些戰鬥故事。

Ty？

是。

他們勢如破竹。

我的 CI 每天晚上都哭著入睡。

目前，我們幾乎所有的開發人員基礎架構團隊，都在努力解決運算資源擴充和效率問題。

你知道的，紅色警戒正在發生。

他們發現交易量大幅增加。

我們正在對代理進行架構變更。

我們正努力盡快擴大遠端建構執行和 Bazel 快取，並研究如何讓所有主要分支隨時保持綠色狀態，或是否可以開始在某些區域使用代理程式進行前向修復，並觀察工程師傳入的資料量，嘗試進行自我修復 CI 或縮短意見回饋循環等。所有團隊都積極投入這些工作，努力跟上成長步伐，同時保持一定的效率。

但這極具挑戰性。

沒錯，我同意 Ty 剛才說的所有內容，但我認為這也迫使我們反思，並誠實地問自己，如果從現在開始要成長 10 倍，我們準備好了嗎？

對大多數人來說，答案可能是否定的。

因此，在思考未來時，我們會刻意嘗試將雄心壯志與基礎架構可支援的規模相匹配。

AI 帶來的其中一項影響，就是讓我們更有雄心壯志，因為我們已經看到有意義的進展，所以我們正在重新思考系統。

沒錯，我們會思考還有哪些系統會故障，或預期會故障，以及如何提前因應，避免措手不及。

實際上，我們是想避免意外。

沒錯，只要我們覺得自己能掌控一切，大家就會很開心。

只要遇到意外，對大家來說都是壞消息。

對吧？

因此，現在是反思、回顧、稽核和找出下一個可能發生問題的地方的好時機，因為問題一定會發生。

這是必然的。

我們只是想先做好準備。

Inflow 執行長曾說過一段很有意思的話。

她提到 Google 花了 20 年左右的時間，才達到現在數十億行程式碼的規模。隨著 AI 技術加速發展，許多公司在短短幾年內就能達到類似的規模。

我不認為所有公司都準備好採用 Google 等級的基礎架構進行開發。

說到這個，貴公司是否會設定某種支出上限？

例如，如何管理那些現在什麼都用最好模型，導致代幣消耗過快的開發人員？

例如，你是否發現任何策略，還是讓他們自由發揮比較好，因為實驗能帶來甜美的成果？

我認為去年是實驗的一年。

執行所有操作。

甚至今年上半年也只是合理使用。

自 9 月起，我們也設定了權杖限制。

因此，我們實際上對開發人員的權杖用量設有限制。

我們也提供檢測工具，讓他們瞭解工作階段是否良好、健康。

什麼是健康的工作階段？

每個工作階段是否都有這麼多回合？

什麼是回合？

因此，我們也試著透過工具教育開發人員。

我認為這只是第一步。

畢竟，你必須先知道問題所在，才能加以修正。

所以，至少讓他們知道這不是免費的。

以前，AI 似乎是免費的。

而且大家都在使用。

我希望它能「變更我的分支版本」，就像「沒問題，Annyce，我會幫你變更分支版本，只要 $5 美元」，對吧？

現在，我們來到這個階段：「好吧，我可以前往指令列，自己完成這項操作，對吧？」

因此，我認為我們將開始讓工程師瞭解實際成本。

更像是，我不會只啟動 ECS 執行個體，然後就放著不管。

AWS 剛推出時，我們可能會想：「我可以自己建立執行個體。」

我們讓公司花了很多錢。

我認為代幣現在也面臨同樣的情況。

我認為實際限制也帶來了非常有趣的機會，對吧？

因為回想一下，我們一開始使用 LLM 時，會把所有東西都丟給它們，對吧？

他們會檢查程式碼、找出問題，並為您施展魔法，對吧？

但這也帶來了代價。

而我們確實是，你知道，業界也意識到了這一點。

這實際上迫使開發人員和組織思考如何最佳化，對吧？

舉個具體例子：如果生成器會產生使用者介面元件，且這些元件必須符合特定結構、單元測試等，那麼既然能讓模型生成確定性工具，由工具為您建立元件，何必讓模型即時生成元件呢？

因此，您可以善用權杖和用量限制，實際提高效率。

沒錯，我們在 Instacart 確實有導入限制，至少在某些方面是這樣。

不過，我認為目標不一定是限制 AI 的使用量，而是要建立某種衛生習慣，或者像你說的，反思，對吧？

例如，何時該使用特定模型，而非其他模型。

你可能不需要 Fable 或 Astra 告訴你時間或變更 Git 分支版本。

對吧？

您可能需要花點時間編寫指令碼，但這項服務永久免費。

不會浪費任何權杖。

對吧？

因此，我認為如果能加入某種限制，不一定是為了限制使用，而是為了幫助你思考，而不只是把所有東西都丟給它。

對吧？

我很認同你的說法，去年就像是實驗的一年。

今年則像是「好，我們該如何有效運用這項技術？」

是啊

這裡的故事也讓我們深有共鳴。

尤其是從實驗階段，轉變為兼顧效率和責任的平衡狀態。

這要歸功於多項投資。

例如開發人員教育訓練和資訊公開。

就像 Annyce 提到的，例如活動時段費用和資訊。

例如投資安全預設值，避免不必要的互動，確保使用的技能有效率，尋找迴歸等。

並對支出費用負責。

所以，我們確實有詞元限制。

當開發人員達到這些限制時，只要按一下按鈕並輸入理由，主管就能核准。

因此，如果有人做出很棒的成果，我們希望他們能分享。

不過，如果他們可能在做一些更浪費或實驗性的事情，他們無法向經理證明為什麼，你知道，為什麼他們應該在這方面花錢，那麼這也有助於他們控制這一點。

這不僅能減少工作量，還能讓您思考並判斷，這是否為合適的模型選擇？

這個權重正確嗎？

顯然，在競爭壓力下，這些權杖的成本已開始下降。

但一般來說，讓工程師思考如何妥善運用我們提供的資金，我認為這是目前正確且健康的做法。

長期目標則是讓他們完全不必做這項決定。

對吧？

您希望模型能自動路由，讓使用者不必費心。

但目前來說，這是健康的狀態。

是啊

我們目前著重於開發模型路由器等功能，讓開發人員不必費心選擇，而是由系統自動將工作對應至合適的模型。

但也要有適當的觸發機制。

因此，我們從幾個方面考量詞元限制。

我們不希望封鎖開發人員。

但我們確實希望確保在某些時刻，我們可以暫停一下，確保資金花在正確的領域和正確的方式。

舉例來說，我們設有每日上限，純粹是為了讓開發人員自行解除封鎖。

他們只要前往入口網站，點選按鈕，然後說：「嘿，我

一切由我掌控。」

對吧？

這只是其中一個簡單的控制項，因為每個人都在執行迴圈，而且這些迴圈可能會執行一整晚，我們不希望這會增加成本。

因此，這非常合理。

另一方面，我們也希望確保開發人員能使用最優質的模型。

但針對這類模型，我們制定了前沿預算。

因此，我們設定了每月預算。

夠高了。

你未遭封鎖。

如需解除封鎖，請按照例外狀況程序操作。

傳送給主管。

你可以在這個時候說明自己正在做什麼。

平台團隊並非決策者，因為決策應由實際執行工作的人員制定。

在使用 Frontier 模型方面，我們同樣提供充分的彈性，但設有上限。

之所以能發揮作用，是因為這最終能為流程帶來可預測性。

對吧？

我們希望確保在編列權杖支出預算時 (這對所有人來說都是一項挑戰)，我們已將規劃內容納入考量，而這些槓桿可讓我們做到這一點。

你知道這些對話中，我最感興趣的是什麼嗎？

我想是因為我們都在公司工作。

因此，企業

因此，我們必須為每個權杖付費。

對吧？

但網路上有許多人採用訂閱制計費。

因此，對他們來說，這是一種截然不同的計算方式。

對吧？

不過，我想大家遲早都會面臨相同處境，必須開始思考每個詞元的成本。

到時候，我們可能就得承擔更多責任，就像現在的公司一樣。

或者，您在頂尖實驗室工作，預算無上限。

然後繼續營運，並創造許多令人興奮的 AI 原生工作方式，這些方式在 Twitter 上隨處可見。

我們所有公司都想效仿，但他們不想花費代幣…

我們有 Google 員工在這裡。

我很好奇。

它有什麼作用？

Google 提供的預算有多少？

Luis，你要回答嗎？

我認為自己不適合談論這方面的經濟學。

Google 是一家大型公司，旗下有許多不同的組織。

不過，我們剛好也到了尾聲，時間掌握得恰到好處。

這很方便。

Saved by the bell.

這就是 A+ 級的審核，各位。

公關人員…

總之，感謝我們的專家小組，也感謝大家參加 ADS。