Connect with us

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

ソートリーダー

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

mm
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万行のコードを出荷したことを共有した。3人のエンジニアが、手動で1行もコードを書かずに。生産的な製品で、数百人の内部ユーザーが使用している。

それは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への移行は数クォーターで起こるかもしれない。ただし、組織がパターンをより早く認識することを前提としている。

進むべき道

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

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

新しい10倍

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

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

彼らは10倍のコードを書かない。コードを書くシステムを構築する。

私は、この役割が私がここで説明した通りに結晶化するかどうかは不確実である。ただし、オーケストレーションレイヤー(最終的には何と呼ばれるかはわからない)を理解した組織が、実際に生産性の向上を実現する組織になるとは確信している。

Andrew FilevはZencoderの創設者/CEOです。彼はWrike(20,000以上の顧客、25億ドルで売却)を創設することでコラボレーション型のワークマネジメントを変革し、ForbesやThe NY Timesに紹介され、彼のAIやイノベーションへの情熱は今も仕事の未来を形作り続けています。