ソートリーダー

新しい10倍エンジニアは10倍のコードを書かない。システムを構築する。

mm
Unite.AI を Google の優先ソースに追加
A cinematic, wide-angle shot of a technical professional sitting at a futuristic curved workstation in a dark data center, orchestrating a complex digital workflow displayed on glowing holographic glass panels.

10倍エンジニアは、数十年間、シリコンバレーの神話でした。ヘッドフォンをして、超人的なスピードで優雅なコードを大量に生産する孤独な天才。彼らが存在するかどうかについて議論し、どのようにして彼らを雇うかについて議論し、誰かが自分が10倍エンジニアであると主張するのを黙って嫌悪してきました。

しかし、AI第一の未来に向かっている途中で、面白いことが起こりました。10倍エンジニアは現実になったのです。ただし、想像していたのとは全く異なる見た目をしています。

OpenAIは最近、3人のチームがCodexを使用して1,500のプルリクエストと約100万行のコードを出荷したことを共有しました。手動で1行も書かずに。3人のエンジニア、0行の手書きコード。数百人の内部ユーザーが使用するプロダクション製品です。

それは10倍ではありません。それは100倍に近いです。そうしたことが可能になったスキルは、より速くタイピングしたり、より多くのアルゴリズムを知ったりすることではありませんでした。AIエージェントの生産性を高めるシステムを構築することだったのです。ワークフロー、ガードレール、検証ループ、エージェントがプラグインし、人間がレビューするインターフェイスです。

私は、これがエンジニアリング組織における新しい重要な機能の出現であると思います。これをAIオーケストレーションエンジニアリングと呼びます。

3つの分野がスタンドアップに参加する

AIオーケストレーションエンジニアが実際に何をするかを注意深く見ると、3つの馴染みのある分野が1つに融合していることがわかります。

最も明らかな成分はDevOpsです。DevOpsはデプロイメントパイプラインを集中化しました。1つのチームがすべてのエンジニアがコードを出荷するときに使用するCI/CDワークフローを構成しました。AIオーケストレーションエンジニアリングも同様のことを行いますが、エージェントワークフローについてです。タスクがエージェントに割り当てられ、出力が検証され、再試行とフォールバックがどのように機能するかを定義します。これは、エージェントが実行される共有インフラストラクチャです。

次に、DevOpsと重なるアーキテクチャがあります。アーキテクトは、どのインターフェイスがロックされているか、どのパターンが適用されるか、どの境界を越えることができないかを決定します。エージェント優先の世界では、これはより重要です。エージェントは、人間が読みやすいだけでなく、エージェントが理解できるように、クリーンでドキュメント化されたコードベースと明確な契約が必要です。AIオーケストレーションエンジニアは、これらの制約を定義します。人間の読みやすさのためだけでなく、エージェントの理解のためにです。汚れたリポジトリは、単に技術的負債ではありません。エージェントがそれに触れるすべてのエージェントの生産性の天井です。

最も理解されていない部分は、AI固有のレイヤーです。プロンプトエンジニアリング、コンテキスト管理、モデル選択、エージェント構成です。今日、ほとんどのエンジニアはこれらのタスクを散在的に、タスクごとに実行します。各人は独自のプロンプティングスタイル、独自のエージェント設定、独自のワークアラウンドを決定します。AIオーケストレーションエンジニアは、これらのタスクを集中化します。共有のプレイブック、再利用可能な構成、組織の知識を構築します。どのモデルやユースケースで何が機能し、何が機能しないのかについての知識を共有します。

個別に、これらの3つの機能は、ほとんどのエンジニアリング組織で既に存在しています。議論は、これらの機能を1つの集中型役割に組み合わせることで、質的には異なるものが生み出されるというものです。

ショーランナー・メタファー

映画監督は、カメラを操作したり、シーンで演技したり、映像を編集したりしません。しかし、毎フレームは彼の決定を反映しています。

監督は、ショットの構成、テンポ、トーンを選択します。監督は、どのときに近づき、どのときに引き離すかを決定します。監督は、環境(照明、セットデザイン、ブロッキング)を設定します。そうすることで、すべてのスタッフが一貫したビジョンの中でベストを尽くすことができます。スタッフは個別に才能があるかもしれませんが、監督の調整がないと、出荷できない混乱に陥ります。

AIオーケストレーションエンジニアリングも同様の方法で機能します。エージェントは有能です。モデルは強力です。しかし、それらを調整するシステムを設計する誰かがいないと、不一致な出力、浪費されたコンピューティングリソース、エージェントが相反する作業を行うこと、エンジニアがAIによって生成されたコードを修正するのに、自分で書くよりも多くの時間を費やすことになります。

監督は、映画をその部分の合計以上のものにします。AIオーケストレーションエンジニアも、エージェントの群れに対して同様のことを行います。

ほとんどの組織が十分に投資していない理由

業界全体で見られるのは、企業がAIツールに多く投資し、周囲のシステムに十分に投資していないことです。

エンジニアはCopilot、Claude、Codexなどのツールにアクセスします。個別に実験します。何人かはパワーユーザーになります。ほとんどの人は「ファンシーオートコンプリート」段階で頭打ちになります。研究で報告されている20%の生産性向上は、ツールレベルの採用によるものです。システムレベルの思考が欠けているためです。

突破口を見つけた組織、2倍以上のスループットを報告している組織には、共通点があります。オーケストレーションワークを集中化しました。誰か(または何人か)がエージェントワークフロー、リポジトリの準備、検証インフラストラクチャ、エージェントがアクセスできる共有コンテキストを所有します。

役割の実際の様子

AIオーケストレーションエンジニアの日常業務には、以下のようなものがあります。

  • エージェントワークフローの設計:機能リクエストが仕様になり、計画になり、並列エージェントタスクになり、レビューされ、コードになり、統合されるようにします。
  • 検証インフラストラクチャの構築:エージェントが出荷される前に、自動テスト、リンティングルール、セキュリティスキャン、評価フレームワークを構築します。
  • エージェントの消費のためのリポジトリのヘルスメンテナンス:ドキュメント、インターフェイス、依存関係管理、コードベースの簡素化を、人間の読みやすさだけでなく、エージェントの理解のために最適化します。
  • プロンプトとコンテキスト戦略の集中化:システムプロンプト、取得パイプライン、モデルルーティングの決定、チーム全体が使用する構成テンプレートです。
  • エージェントのパフォーマンスの監視と改善:エージェント群全体の成功率、障害モード、タスクあたりのコスト、統合までの時間を追跡し、データに基づいてシステムを調整します。

この人は、プラットフォームエンジニアリング、ソフトウェアアーキテクチャ、AIの専門知識の交差点にいます。機能を書きません。機能の配信を迅速に、信頼性が高く、スケーラブルにするシステムを構築します。

歴史的パターン

クラウドコンピューティングの初期の頃、デプロイは各エンジニアの副次的な任務でした。各チームには独自のスクリプト、独自のサーバー構成、独自のコードをプロダクションに持ち込む方法がありました。DevOpsはこの作業を集中化するために登場しました。プラットフォームエンジニアリングは、これを共有のセルフサービスインフラストラクチャに組み込むために進化しました。

AIも同様のパターンに従っています。現在、エージェントの使用は各エンジニアの副次的な任務です。各人は独自のプロンプティングスタイル、独自のツールの好み、独自のAIが役立つときと役立たないときのメンタルモデルを持っています。集中化し、インフラストラクチャとして扱う組織は、DevOpsの実践が十分に整備された組織がそうだったように、先行します。ただし、違いはスピードです。DevOpsへの移行には10年かかりました。AIへの移行は数か月で起こるかもしれません。ただし、組織がパターンを認識するのが通常よりも早いと予測しています。

DevOpsと同じように、AIオーケストレーションエンジニアリングも、エージェントの使用を集中化し、エージェントのワークフローを最適化することによって、エンジニアリング組織に大きな利益をもたらすでしょう。

進むべき道

エンジニアリングリーダーの場合、以下のことを提案します。ただし、チームがすでにどの程度進んでいるかによっては、異なる場合があります。

  1. この作業を非公式にすでに行っている人を特定します。毎回、エージェントのワークフローについてアドバイスを求められる人、プロンプティングやツールの設定についてアドバイスを求められる人がいます。その人はあなたのproto-AIオーケストレーションエンジニアです。
  2. これを明示的にします。機能に名前を付け、使命を与え、リソースを割り当てます。これを「本当の」仕事に付随する副次的なプロジェクトにしないでください。
  3. リポジトリの準備から始めます。高度なエージェントワークフローに投資する前に、コードベースがエージェントがナビゲートできるものであることを確認します。クリーンなインターフェイス、良いドキュメント、包括的なテスト、簡素化されたアーキテクチャです。
  4. 機能するものを集中化します。誰かがエージェントの出力を大幅に改善するプロンプト戦略やワークフローパターンを発見したとき、キャプチャします。チーム全体のデフォルトにします。1人の頭の中にロックされた部族的知識にしないでください。
  5. システムレベルで測定します。個々のツールの使用状況のみを追跡しないでください。エージェントがエンドツーエンドで完了するタスクの数、レビューと再作業の率、ボトルネックがどこにあるかを追跡します。

新しい10倍

10倍エンジニアの神話は、いつも個人の英雄的な行為についてでした。1人の人、純粋な才能とカフェインによって誰よりも優れています。

AI時代の10倍エンジニアの現実は、システム思考についてです。システムのインフラストラクチャ、ワークフロー、制約を構築することで、他のすべてのエンジニア(およびエージェント)をより生産的にする人です。

彼らは10倍のコードを書きません。コードを書くシステムを構築します。

私は、この役割が私がここで説明したのと同じように結実するかどうかはわかりません。しかし、オーケストレーションレイヤー(何と呼ぶかは関係ありません)を理解する組織が、他の人々が話している生産性の向上を実際に実現するだろうと確信しています。

アンドリュー・ファリェフは、Zencoderの創設者兼CEOです。彼は、Wrike(20,000以上の顧客、22.5億ドルで売却)を創設することで、コラボレーションによるワークマネジメントを変革しました。フォーブスとニューヨークタイムズに紹介され、彼のAIとイノベーションへの情熱は、仕事の未来を形作り続けています。