非線形な生産性

はじめに

このページでは、AI を使用して生産性を向上させるために Engineering が進めている 取り組みについて説明します。

なぜ「非線形」な生産性なのか

コードの生成は簡単になりつつあります。難しいのは、そのコードを本番環境で利用できる形で お客様の手元に届けることです。A/B テスト、ロールアウト計画、ロールバック 計画、そして変更が存在するようになった後に付随するその他すべてが必要です。現在ボトルネックになっているのは、 作成ではなく、これらのステップです。今日の GitLab では、 コードのレビューにかかる時間もそこに含まれます。

関連する前提として、構文の重要性は時間とともに低下します。エージェントは、 保守性、可読性、モジュール性の観点では最適化されていないように見えるコードを 書くかもしれませんが、そのコードを読み、保守し、変更するのもエージェントです。 現在の私たちのレビューには、まさにそのような特性に 労力を費やしているものもあります。

このプロジェクトは、Bill Staples が コードが豊富にあるときで 述べている議論に対する、エンジニアリングプラクティス面での取り組みです。 コード生成が豊富になる一方で、優れたソフトウェアはそうではないため、制約は コードの生成からコードを信頼することへ移ります。同記事では、このプロジェクトが最適化する経済単位を 承認された変更あたりのコストと呼んでいます。これには、 生成、環境のセットアップ、コンテキスト、検証、レビュー、修正、 ガバナンスが含まれます。生成の項だけを縮小しても、キューを短縮するのではなく 移動させるだけです。

生産性を非線形にスケールさせるには、制約を デリバリーパスの各ステップにおける人間の処理能力から切り離す必要があります。

長期的な取り組み

レビューを左にシフトする

他の人（人間とエージェントのどちらも）が受け入れられるコードを作成することは、すでに 作成者とそのエージェントの責任です。 この取り組みでは、最初からより高品質なコードを生成するためのツールを構築し、 作成者がそのプロセスを実行しやすくします。マージリクエストの最初のイテレーションが すでに良いものであれば、レビュー担当者がやり取りに費やす時間が減り、 作成者が変更を取り込むまでの経過時間も短くなります。

その基盤となるのが GitLab Duo の /review です。これにより、マージリクエストを 作成する前に、変更をローカルでレビューして修正できます。初期の イテレーションは完璧ではありません。継続的に改善することを意図しています。

パイプラインのボトルネックを減らす

より良いコードを迅速に生成できるようになったら、そのコードを本番環境にも 迅速に届ける必要があります。目標は、パイプラインの各ステップでエージェントを使用し、 作業を自動化して障害を修正することです。たとえば、次のようなものです。

1. 自動的に処理できる、不安定なマージパイプライン。
2. 何かを待ったまま動きのないマージリクエスト。最初の承認者が対応できない場合に、 エージェントがレビュー、修正、または別の承認者の検索といった アクションを実行できます。

これは、コードが豊富にあるときで説明されているものと同じ変化です。パイプラインは、 開発の最後にあるゲートではなくなり、生成、ビルド、テスト、検証、レビュー、修正、 繰り返しという開発ループ自体を、コード、コンテキスト、制御の近くで実行する システムになります。

アーキテクチャのモジュール化

人間をループから外すには、他のお客様に影響を与えず、定義されたお客様の集合へ 変更を数分で安全にロールアウトできるアーキテクチャが必要です。これはフィーチャーフラグだけでも、 セル化だけでもなく、両方より広いものです。ツールへの投資とアーキテクチャの 変更が必要であり、一朝一夕には実現しません。

人間をループから外すことは、アーキテクチャと同じくらいガバナンスの問題でもあります。 コードが豊富にあるときでは、これを、自律性は与えられるのではなく統制されるものだと 説明しています。エージェントは創造性を発揮でき、システムが創造性を止める場所を決めます。 決定論的なゲート、隔離、検証、ポリシー、エビデンスがあれば、 自律性を安全に拡大できます。

想定されるトレードオフ

ごく短期的には、この方向性により、コードのレビュー時間が減るどころか 増える可能性があります。これは、エージェント、モデル、基盤が、人間の介入なしで 動作できるようになるまで改善していく間の短期的な痛みとして受け入れます。

関連情報

• コードが豊富にあるとき - コード生成からコードを信頼することへ制約が移る理由、エージェント型開発の 3 つのモード、エージェントを取り巻く環境として企業に必要な永続的なコンテキスト、 検証、ガバナンスのレイヤーについて、Bill Staples が説明しています。

測定

私たちは次のメトリクスを測定します。

1. MR が Ready とマークされてから Merged になるまでの時間
2. MR が Ready とマークされてから Assigned になるまでの時間
3. MR が Assigned になってから Reviewed になるまでの時間
4. MR のイテレーション数
5. MR のサイズ

これらのうち、最も重要なのは（1）、Ready から Merged までの時間です。

これらのメトリクスは、次の項目別に分類します。

1. 変更の種類（ドキュメント、コード、設定）
2. MR を提出したチームメンバーの Engineering Organization

測定から除外するものは次のとおりです。

1. コミュニティからのコントリビュート
2. Draft 状態の MR
3. MR が Ready とマークされる前に Draft 状態で費やした時間

ページのソースコードを見る - ページの編集 - please contribute.