この記事は、エージェント型エンジニアリングがどうあるべきかについての主張ではなく、組織規模での振り返りである。Zalando の Executive Principal Engineer である Bartosz Ocytko が書いたもので、同社が 250 を超えるエンジニアリングチームにわたる 2 年半の取り組みと表現するものを振り返り、うまくいったとするアプローチを示している。その前提となる捉え方は、業界全体がエージェント型エンジニアリングへの取り組み方をまだ模索している最中であり、大規模言語モデルがもたらす価値と影響は、同社の事業部門ごとに異なる形で、異なるペースで現れつつある、というものである。

同じテーマを扱うベンダーの資料とこの記録を分けているのは、主張の大半が Zalando 自身の測定と自身の運用上の選択に関するものだという点である。LLM プロキシがいくつの Pod で動いているか、承認ボットがプルリクエストのどれだけの割合を自動承認しているか、名前の挙がった 4 つのコードベースにコーディングエージェントが入ったときにコードの複雑さに何が起きたか、といったことである。記事は、これが発展途上の実践のスナップショットであることを明言しており、同様の問題に取り組んでいる他の非ベンダーのエンジニアリングチームに連絡を呼びかけて締めくくられている。

記事が述べる組織としての基本方針は、意図的に一本化しないことである。200 を超えるチームがエコシステムを探索しているなかで、1 つのツールに標準化するのは時期尚早にすぎるというのが同社の立場であり、代わりにチーム間の透明性と交流を目標としている、と記事は述べる。

要点

  • Zalando の ML プラットフォームチームは 2024 年 1 月に LiteLLM ベースの API プロキシをデプロイし、エンジニアが複数のプロバイダーのモデルに API 経由でアクセスできるようにした。これにより、プラットフォームチームは導入状況を測定できる単一の地点を得た。
  • 同社は単一のコーディングツールを中央から義務づけたことは一度もない。ユーザーは利用可能なモデルや、IDE と CLI のどちらを好むかに基づいて選択しており、記事は変化の速い環境においてはベンダー非依存であることが鍵だと位置づけている。
  • ツールの機能はおおむね似通っており、記事の言うところでは乗り換えコストはかなり低いにもかかわらず、ユーザーは使い続けてきたコーディングエージェントに愛着を持つようになる。著者はこのためらいを、技術的なものではなく心理的なものとして示している。
  • Zalando は、2 年間にわたって自社のプルリクエストのデータに AI コーディングの影響を見てきたと報告している。変更行数 100〜500 行の PR が一貫して増加しており、さらに 2025 年第 2 四半期の Sonnet 4 のリリース以降は、500〜1,000 行と 1,000〜2,000 行の区分も増加している。
  • 4 つの Java と Go のコードベースについてコミット単位のコード品質指標を対応づけた結果、同社は、各コードベースにコーディングエージェントが入った時点で循環的複雑度の総和に変曲点を特定できると述べている。最初からエージェントを全面的に使っていたコードベースでは、複雑さが非常に速く積み上がり、その後は落ち着いていく。これは同社が自社のリポジトリについて行った独自の分析である。
  • コミットメッセージそのものにもコーディングエージェントの痕跡が残っており、典型的には 5,000 文字前後になる。あるケースでは、コミットメッセージにユニットテストの実行ログがまるごと含まれていた。
  • リスクベースの PR 承認ボットは、各 PR を作成時にロールアウトリスクが低、中、高のいずれかに分類する。記事によれば PR の 33% が低リスクとして自動承認されており、これによって PR のリードタイムが全 PR と比べて 20〜40% 短縮されたという。そのルールセットは同社自身の本番インシデントの分析から構築されたもので、同社の技術スタックに強く特化したものだとされている。
  • 記事は、承認ボットがエンジニアの振る舞いを変えたという逸話的な証拠を報告している。以前は後方互換性のある変更がよりリスクの高い変更と混ぜられていたが、後方互換性のある変更を低リスクとしてすばやく出荷できるよう、PR が分割されるようになった。
  • Zalando は、プラグインにまとめられた Agent Skills の中央集約的なコレクションを維持しており、分野や言語をまたいだ共通のタスクに対応している。記事によれば、新しいプラットフォームツールやインフラストラクチャのプラクティスの導入をチームに案内するマイグレーション用のスキルが、広く人気のある種類だという。
  • コーディングエージェントのセッションデータは非常に学びが多いとされている。トークンを消費する本質的でないトラフィック(プラン名の生成、ターミナルウィンドウのタイトル、アイドル状態のセッションの要約)を見つけるためにも、ユーザーが自分自身のプロンプトのパターンについて学ぶためにも役立つ。
  • ガバナンスは新しい仕組みではなく既存の仕組みを通じて扱われている。同社の Tech Radar に AI のセクションが追加され、AI モデルの使用はデプロイされた Docker イメージのスキャンによって自動検出され、その後オーナーにドキュメントの提出や法務レビューが求められる。
  • トレーニングについて、記事は、スキルを身につけるためのセッションで参加者はコーディングエージェントを近道として使いたいという強い誘惑に駆られ、そうすると通常は学習が妨げられると述べる。そのため、トレーナーは手作業でのコーディングが求められる場面をはっきりと伝えるよう勧められている。

背景

記事は自らを、ベンダーや、モノレポを多用する組織による記録と対置している。業界全体で報告されている AI の成功や PR のスループットの向上の多くは、レバレッジが大きいモノレポから来ているのに対し、Zalando はマイクロサービスにおおむね個別のリポジトリを使っていると記事は指摘する。これが、各リポジトリの AI への準備状況を評価するスキャナーを計画している理由として述べられている。

記事の留保事項は、主に自らの証拠の限界に関するものである。複雑さの分析は、変曲点を確認するために Co-authored-by のマーカーを含むコミットに依拠しており、著者は、すべての作成者がコーディングエージェントの使用を開示しているわけではないため、オープンソースのコードベースではこの点の一貫性が低いと注記している。リスクベースの承認ボットが振る舞いに与えた影響については、証拠が逸話的なものであることを記事ははっきりと述べている。スコープが適切に定まったマイクロサービスで複雑さが頭打ちになることは構築時間が劇的に短縮されたことを意味する、という予測は希望として述べられており、著者はそれが正しいかどうかは時間が示すだろうと書いている。

結びのテーマは、AI は既存の実践を一方向に変えるのではなく、良い実践も悪い実践も増幅するというものである。調子に乗ってしまったチームは、チームが調整するまでの間、レビュアーの意欲をそぎ、デリバリーを遅らせる大きな PR を抱えることになる。一方、プラットフォームの能力への投資、たとえばライブデータにつながった Web モノレポの PR ごとのデプロイは、エンジニア以外の人がプロンプトで変更を指示し、エンジニアに引き渡す前に結果をレビューできるようにすることで報われる。