AirbnbではAIがコードの60％を書くが、本質は引き継ぎの再設計だ

AirbnbのCTOであるAhmad Al-Dahleは、AIが現在社内コードの60％を作り、提供した機能と改善が前年同期比で約80％増え、engineer1人あたりのpull request処理量が約1.6倍になったと説明した。数字はLatent Spaceのインタビューで本人が示したもので、社内変化の規模は伝えるが、software品質の独立した証明ではない。

Codeが文書の一部を置き換え、prototypeが引き継ぎを短くした

Al-Dahleによると、Airbnbはproduct、design、engineeringの仕事の順序を変えた。要件書、Figma、実装、testという長い受け渡しより早くprototypeへ進む。codeそのものが、複数チームで考える中心的な成果物になる。

変化は運用にも及ぶ。customer supportは最初の対ユーザーAI導入で、agentが現在およそ半分のticketを人手なしで解決するという。第2四半期の会社資料では約45％だった。安全に関わる案件は意図的に自動処理から外している。

Everestが一つのteamの経験を次のprojectへ運ぶ

社内context graphのEverestは、LLM、embeddings、AI retrievalで組織とcodebaseの知識を結ぶ。食料品配送の開発には8カ月から9カ月かかったが、似たairport pickup連携は約6週間だったとAirbnbは説明する。後者のteamはEverestに残された知見を利用できた。

この点はAI製codeの比率より重要だ。企業がcontextを残し、use caseごとにevalsを行い、cost、性能、latencyでmodelを選んだときに価値が生まれる。Airbnbは少なくとも10個のcustom modelをproductionで使い、search、coding、supportで異なる選択をしている。

生成codeの比率だけではproduction defectを数えられない

60％、80％、1.6倍という数字は、変革を率いるCTOが示した。インタビューには測定方法や共通のcontrol groupが公開されていない。pull requestの増加は、生産性向上だけでなく、変更の小型化や修正の増加でも起きる。incident、rollback、review時間がなければ品質は判断できない。

Al-Dahle自身も、junior engineerが判断力を育てる経験を失う危険を挙げる。Airbnbは、AIが生成したpull requestでも担当engineerが内容を説明できることを求めている。

On-call agentがcontextを責任へ変えられるか試す

Airbnbは、monitoring eventで起動するcontainer内の非同期agentを使い始めている。agentはincidentをtriageし、pull requestを提案し、誤検知alertを閉じられる。ここでEverestと用途別evalsは、より重大な仕事に向き合う。

次に見るべき指標は、AI変更によるincident、human review時間、却下されたpull request、問題種別ごとのsupport成果だ。処理量の増加は、後ろに修正待ちの列を作らない場合にだけ意味を持つ。

Lilithの判定

AirbnbはAIをprototypeとproductionの間に座らせた。60％は入口の数字にすぎず、中で問われるのはengineerが各pull requestを説明でき、夜間のon-call agentが読める足跡を残すかどうかだ。