アンドリュー・ファリェフは、Zencoderの創設者兼CEOです。彼は、Wrike（20,000以上の顧客、22.5億ドルで売却）を創設することで、コラボレーションによるワークマネジメントを変革しました。フォーブスとニューヨークタイムズに紹介され、彼のAIとイノベーションへの情熱は、仕事の未来を形作り続けています。
約1年前、ソフトウェア業界では、ジュニアエンジニアの将来についての議論が起こった。議論の内容は、AIがすでに多くのジュニアレベルのコーディングタスクを処理できるようになったため、ジュニアエンジニアを採用して育成する必要があるのかどうかというものだった。この質問は、多くの賢い人々が真剣に考えるものだった。当時、私の回答は、他の職業でも同様の問題がすでに解決されているというものだった。医学校を卒業したとしても、すぐに単独で開胸手術を行うことはできない。医師は、長年にわたって経験を積み、実践を重ね、指導を受けることで、最終的に単独で手術を行うことができるようになる。同様のパターンは、経営陣にも見られる。大学を卒業したとしても、すぐにフォーチュン500企業の経営者になることはできない。経営者は、徐々に経験を積み、より大きなビジネスユニットを管理し、最終的に指導的立場になる。私は、エンジニアリングも同様の方向に向かっていると考えている。しかし、最近の3つの無関係な経験から、問題に対する私の考え方が変わった。3つの例友人がチェコ語の試験の準備をしていた。友人とその仲間は、人間のチューターを雇い、実際の金額を投資した。友人は試験に合格したが、他の多くの人は合格できなかった。友人が話すには、最大の違いは、友人の主なチューターが実際にはChatGPTだったことである。友人は、11時になっても勉強することができた。友人は同じ動詞の練習を40回繰り返すことができ、誰かの気を散らすことを心配することなく、チェコの税務官とやり取りするような特定の状況をロールプレイすることができた。人間のチューターは優秀だったが、利用の可用性、繰り返し、パーソナライゼーションをChatGPTに匹敵することができなかった。私は、息子と物理学の勉強で同様のことを見ている。息子はすでに物理学をよく理解しているので、Claudeに答えを教えてもらうのではなく、挑戦するために使っている。息子は、Claudeにより難しい問題を生成してもらったり、仮定を押したり、間違ったアプローチの理由を説明してもらったり、インタラクティブにクイズを受けたりしている。私が考えることができる最も近い類似点は、賢い子供が物理学を専攻している兄または姉と出会う経験である。ただし、このバージョンは常に利用可能で、決して我慢がなく、決して「後で聞いてね」と言うことはない。甥はまだ高校生だが、小さな趣味プロジェクトを作成しており、将来的には商業化したいと思っている。甥のコードをセットアップし、自動化するためのエージェントを設定した。毎晩5時に、エージェントは甥のコードベースをスキャンし、改善点を提案する。毎週、別のワークフローが実行され、新しいアイデアが浮かぶ。甥はそれを愛していた。ある時、甥は「コーディングがこれほど簡単なら、アイデアが尽きてしまう」と冗談で言った。私は「アイデアは常に希少な資源だった」と言った。ただし、違いは、実行がもはやアイデアを制限しないことにある。実装が劇的に安くなったからだ。より迅速なフィードバックループこれらの例は、チェコ語、物理学、コードレビューについてではない。個人化されたフィードバックが継続的に利用可能になることを示している。歴史的に、ジュニアエンジニアは繰り返しと、経験豊富な人々への近さを通じて学んだ。コードを書き、レビューを待ち、シニアエンジニアがバンド幅を確保したときにフィードバックを受け取り、年月を経て蓄積されたミスの判断を築いた。AIはフィードバックループ自体を変える。適切に設定されたAIアシスタントを備えたジュニアエンジニアは、シニアエンジニアの利用可能性に依存していたものを多く受け取る。即時のコードレビュー、将来の問題を説明するデザイン選択、コードベース内の類似パターンへの参照、最も明らかな実装に手を伸ばしたときの押し戻し。最も重要なのは、フィードバックが問題の中にいる間に到着することであり、2日後にコンテキストが消えた後に到着するのではない。それは重要である。ジュニアからシニアへの移行は、主に判断によって推進される。判断は、主にパターン認識を通じて構築される。誰かが繰り返し、トレードオフ、エッジケースを通じて進む速度が速いほど、その判断が発達する速度も速くなる。バンド幅のボトルネックは、シニアエンジニアにあった。現在は、学習者にいる。セーフティネットの改善ここでは、別の重要な変化が発生する。強力なAIレビューシステムを使用するジュニアエンジニアは、意図しないミスでプロダクションシステムを損なう可能性が大幅に低くなる。多くのクラシックミスはすぐにフラグが付きます。ハードコーディングされた資格情報、飲み込まれた例外、安全でないクエリ、セキュリティの問題、明らかなアーキテクチャの問題、スコープの狭い依存関係。悪いプルリクエストは、ラップトップを離れる前にキャッチされることが多い。それはジュニアの仕事の底を変える。歴史的に、シニアエンジニアの多くの時間が、組織を予防可能なミスから保護することに費やされていた。AIレビューレイヤーは、その負担の一部を吸収し、ジュニアが以前よりも独立して動作できるようにする。それは、指導や監督の必要性を排除するものではない。指導が最も価値のある場所を変える。ギャップの拡大この将来の最適なバージョンは、個々のエンジニアがシステムを使用する方法に大きく依存する。AIをショートカットとして考えている人は、多くのコードを生成するかもしれないが、ほとんど何も学ばない。10年前、同じ人はStack Overflowから解決策をコピーしていた。メカニズムは変わったが、根本的な行動は変わらなかった。AIは知的怠慢を解決することはできなかった。より興味深い結果は、エンジニアが受け取るフィードバックと積極的に関わる場合に発生する。誰かがレビューを注意深く読み、時々反論し、フォローアップの質問をし、代替案をテストし、時にはモデル自体が間違っていたことを発見する場合、判断を以前の世代よりも速く構築する。認知努力は消えなかった。ループの早い段階にシフトし、繰り返しやすくなった。それは、関与しているエンジニアとそうでないエンジニアの間のギャップを拡大させる可能性が高い。ほとんどの重要な生産性の変化は、そのように機能する。読み書き能力は、読み書きできる人とできない人との間のギャップを拡大させた。インターネットは、好奇心のある人と受動的な人との間のギャップを拡大させた。AIは、同じパターンを継続する可能性が高い。製品判断の重要性より興味深い質問は、ジュニアエンジニアが実装自体がより簡単になるにつれて、どのような貢献をするかということである。答えは、すでに強力なシニアエンジニアが貢献しているものと似ている。創造性、製品の直感、味、優先順位、判断、そして何が最初に存在するべきかを特定する能力。エンジニアリングの役割は、実装の摩擦が続々と崩壊するにつれて、製品志向の思考にますます近づいている。パイプワークは、システムが実際に正しい問題を解決しているかどうかを理解することよりも重要ではない。システム設計はまだ重要である。名前を付けることはまだ重要である。製品判断はまだ重要である。ユーザーを理解することはまだ重要である。ある意味では、これらのスキルは、組織がアイデアを以前よりも迅速にテストできるようになったため、より重要になる。AIから始めて育ったエンジニアは、15年前に訓練された誰かとは大きく異なる考え方をする可能性が高い。彼らは、イテレーションが安価であると仮定する。彼らは、1つのアプローチについて議論するのではなく、迅速に複数のアプローチをプロトタイプ化する。彼らは、実装のコストが低いことを期待し、ユーザーと実装の間のフィードバックループがより緊密になる。それは、アイデアと実行のサイクルが以前よりもはるかに短い、別の種類のエンジニアを作り出す。組織は、採用、評価、指導、昇進について再考する必要がある。しかし、ソフトウェアはすでに、Webの到来、モバイルの到来、クラウドインフラストラクチャがオンプレミスシステムに取って代わったときのように、同様の移行を何度も経験している。各移行は、エンジニアリングが何を意味するかを変えたが、エンジニア自体の必要性を排除しなかった。運用上の影響ジュニアエンジニアにとってのアドバイスは、特に華麗ではない。実際のプロジェクトを選び、AIを影のレビューアーとして使用しながら作業する。フィードバックを注意深く読み、時々反論し、フォローアップの質問をし、ミスをキャッチするパターンを追跡する。それが、判断を発達させる最も速い方法の1つである。忙しいシニアエンジニアが最終的に時間を確保して指導できるのを待つよりも速い。マネージャーにとってのボトルネックも変わる。ジュニアの成長は、シニアエンジニアがコーチングのためにどれだけの時間を割くことができるかに大きく依存していた。現在、より大きなレバレッジポイントは、AIの使用を取り巻く強力な学習環境を設計することである。レビューの期待、エスカレーションルール、プロンプトパターン、ガードレール、プロジェクトの選択。これらのシステムをうまく構造化した組織は、以前の世代よりも速く才能を育てる可能性が高い。リーダーシップチームにとっては、ジュニアエンジニアを主に実行可能な容量として見るのをやめることが賢明である。多くの組織では、彼らは実験、エネルギー、創造的なイテレーションの最も安価な源となる可能性がある。異なる世代のエンジニア友人は、チェコ語を学ぶためにポケットの中にパーソナライズされたチューターを携帯していた。息子は、私がアクセスできなかったレベルのインタラクティブなフィードバックで物理学を学んでいる。甥は、寝ている間に毎晩コードレビューと市場調査を受け取っている。次の世代のエンジニアは、継続的なコーチング、即時のレビューループ、努力とフィードバックのサイクルが劇的に速くなった状態で業界に入ることになる。それはジュニアエンジニアを排除するものではない。彼らがどのように発達し、どのようなスキルが道中で最も重要となるかを変える。多くの人が育った役割のバージョンは、おそらく消えている。ただし、代わりに、以前の世代がなり得なかったより速く学び、より良くコーチされ、より実験的で、より製品志向のエンジニアが現れるかもしれない。
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オーケストレーションエンジニアリングも、エージェントの使用を集中化し、エージェントのワークフローを最適化することによって、エンジニアリング組織に大きな利益をもたらすでしょう。進むべき道エンジニアリングリーダーの場合、以下のことを提案します。ただし、チームがすでにどの程度進んでいるかによっては、異なる場合があります。 この作業を非公式にすでに行っている人を特定します。毎回、エージェントのワークフローについてアドバイスを求められる人、プロンプティングやツールの設定についてアドバイスを求められる人がいます。その人はあなたのproto-AIオーケストレーションエンジニアです。 これを明示的にします。機能に名前を付け、使命を与え、リソースを割り当てます。これを「本当の」仕事に付随する副次的なプロジェクトにしないでください。 リポジトリの準備から始めます。高度なエージェントワークフローに投資する前に、コードベースがエージェントがナビゲートできるものであることを確認します。クリーンなインターフェイス、良いドキュメント、包括的なテスト、簡素化されたアーキテクチャです。 機能するものを集中化します。誰かがエージェントの出力を大幅に改善するプロンプト戦略やワークフローパターンを発見したとき、キャプチャします。チーム全体のデフォルトにします。1人の頭の中にロックされた部族的知識にしないでください。 システムレベルで測定します。個々のツールの使用状況のみを追跡しないでください。エージェントがエンドツーエンドで完了するタスクの数、レビューと再作業の率、ボトルネックがどこにあるかを追跡します。 新しい10倍10倍エンジニアの神話は、いつも個人の英雄的な行為についてでした。1人の人、純粋な才能とカフェインによって誰よりも優れています。AI時代の10倍エンジニアの現実は、システム思考についてです。システムのインフラストラクチャ、ワークフロー、制約を構築することで、他のすべてのエンジニア（およびエージェント）をより生産的にする人です。彼らは10倍のコードを書きません。コードを書くシステムを構築します。私は、この役割が私がここで説明したのと同じように結実するかどうかはわかりません。しかし、オーケストレーションレイヤー（何と呼ぶかは関係ありません）を理解する組織が、他の人々が話している生産性の向上を実際に実現するだろうと確信しています。
最近、AI疲労について書きました。そこでは、エンジニアが経験しているものは慢性的な状態ではなく、トレーニングによる筋肉痛であると主張しました。突き進み、適応し、強くなることが大切です。それはすべて良くて、正しいですが、その話にはさらに続きがあります。それが急速に明らかになってきています。エンジニアチームが現在直面しているリスクは、燃え尽き症候群ではありません。それは、停滞です。新しい分裂ほとんどのシニアエンジニアは現在AIを使用しています。Copilot、Claude、Cursor、Codexなど、どれでもいいです。その部分はすでに決まっています。エンジニアリング組織を率いている場合は、広範な採用率を見て、気分が良いかもしれません。しかし、そうではありません。採用率は無意味です。重要なのは、その下で起こっている分裂です。チームは静かに2つのグループに分かれています。生産性のブーストを受けたエンジニアと、毎週新しいワークフロー、新しいエージェント構成、新しい問題解決方法を模索するエンジニアがいます。どちらのグループもダッシュボードには「AIユーザー」として表示されます。しかし、1つのグループは進歩的なトレーニングプログラムに参加しています。もう1つのグループは最初の重量で満足したまま止まっています。6か月前、这2つのグループの間のギャップはほとんど見えませんでした。現在、誰でも見ることができます。さらに6か月で、それは構造的なものになります。プレートーとはどのようなものかプレートーに陥ったエンジニアは、伝統的な意味では何も間違ったことをしていません。彼らは有能です。彼らは製品を出荷し、エージェントを使用して単純なタスクを実行し、後始末をします。彼らは20〜30%の生産性向上を得たと考え、満足しています。問題は、隣のエンジニアがそこで止まらなかったことです。那エンジニアは現在、マルチエージェントワークフローを実行し、検証ループを改善し、機能をAI実行可能なチャンクに分解し、コードレビューを行い、以前の2〜3倍の速度で製品を出荷しています。彼らはより才能があるからではありません。彼らは他の人が休んでいる間にトレーニングを続けたからです。これはAIの熱意や、早期採用者であるかどうかについてではありません。早期採用段階は終了しました。これは、継続的な適応と、一時的な調整の違いについてです。而且、これらのアプローチの間の差は無視できないものになっています。競争圧力は現実的であり、加速していますチームに独自のタイムラインで適応する余裕がある場合、プレートーの問題はパフォーマンス管理の問題です。面倒ですが、管理可能です。しかし、ソフトウェア業界全体の状況を見ると、そんな余裕はないでしょう。ソフトウェア業界は、人間のデジタル作業を支援するために作られました。サポートエージェントの受信ケースの表示、顧客への対応の追跡、ワークフローの管理などです。現在、AIエージェントはこれらのワークフローを置き換え、基盤となるSaaSプラットフォームを混乱させています。また、AIが日々より優れてくると、顧客は質問を始めています。「これを購入する必要がありますか? それとも自分で作ることができますか?」AIは、「購入」と「作成」の間に存在するバリアを縮小し始めています。収入を保護していた粘着性は、四半期ごとに弱まっています。あなたのプレートーに陥ったエンジニアは、現在存在しない競争環境に合わせたペースで動作しています。私を再構成させた引用私はこれを複数の製品マネージャーから聞きました。彼らは機能を実装するために手伝ってくれたエンジニアです。さまざまな企業、さまざまな状況で、次のことを聞きました。「エージェントと一緒にこれを反復することは、エンジニアと一緒に反復するよりも簡単でした」最初に聞いたときは、誇張と思いました。3回目に聞いたとき、先行指標であることを理解しました。私の見解では、この新しい世界で成功するエンジニアは、AIの能力を「倍増者」にする必要があります。そのためには、2つの分野で強くなければなりません。両方とも、内発的動機と知的好奇心によって自己開発できます。 彼らはステークホルダー（PM、エンジニアマネージャーなど）と同じ波長で動作します。彼らは何が良いかを理解しているので、説明する必要はありません。なぜなら、エージェントはいつでも利用可能で、24時間365日動作し、疲れませんからです。 彼らはAIの設定を不断に改善します。何かを彼らに渡すと、十分なスピードで完了することを知っているので、市場のテンポに追いつくことができます。 これはリーダーシップの問題であり、個々の問題ではありませんこれを個々のエンジニアの責任として扱うのは、面倒です。「追いつけなければ置いていかれる」ですが、エンジニアリング組織を率いている場合は、そのフレーミングでは責任を回避しています。あなたのプレートーに陥ったエンジニアは、空間がない場所でプレートーに陥りました。彼らは最初の調整で妥協し、誰も彼らをさらに先に押すことがなかったので、慣性が残りました。一方、進歩を続けるエンジニアの多くは、自己動機付けです。彼らは何が起こるかによらず進歩します。しかし、エンジニアリング組織を完全に自己動機付けの先駆者で構成することはできません。リーダーにとっての質問は、「中間層をどう動かすか」です。これは、変化管理の問題です。私の好きなフレームワークの1つは、Heath兄弟の本「Switch」から来ています。簡単に言うと、人々に明確な方向性を与え、重要性を感じさせ、環境を変える必要があります。エンジニアリングチームに適用すると、次のようになります。明るいスポットを見つけ、可視化します。 AIワークフローで最も進歩したエンジニアを特定し、チームにデモを実施させます。トレーニングセッションではありません。実際の作業のライブウォークスルーです。チームの中央が自分のワークフローとトップアダプターのワークフロー之间の差を見たとき、生産的な不快感が生まれます。それは、命令では生み出せないものです。 変化を縮小します。 「AIを採用する」ことは、抽象的すぎて行動に移せません。このスプリントでは、エンドツーエンドのエージェントテストを完了し、次のスプリントでは組織全体に展開します。具体的で管理可能なステップが、雄大な変革プログラムよりも優れています。小さな勝利も重要です。 デフォルトを再構成します。 検証プロセスをAIスキルにコード化し、チーム全体とすべてのエージェントに展開します。ワークフローを定義し、そのサポートツールを使用します。新しい作業方法を最も抵抗のない道にします。そうすれば、人々はそこに向かうために戦う必要はありません。 窓は閉じていますここが緊急性を生み出す部分です。現在、適応ギャップはパフォーマンスの差です。プレートーに陥ったエンジニアは、適応したエンジニアよりも遅いですが、まだ生産的です。彼らはまだ貢献しています。彼らを支援できます。しかし、その窓は閉じています。AIの能力が加速し、競争圧力が複合するにつれ、エンジニアリング作業の最低限のペースが上昇しています。今日の「十分な」エンジニアは、次の四半期には十分ではない可能性があります。彼らが悪くなったわけではありません。床が上がっただけです。チーム全体を適応曲線の上に移動する組織は、複合的な構造的な優位性を持ちます。そうでない組織は、競争のペースがなくなったためにスタッフを配置することになります。話をするエンジニアリングリーダーは、誰でもこれを理解しています。ただし、ほとんどの人はチームの運用方法を変更していません。理解と行動の間のギャップは、別の種類のプレートーです。快適なペースはありませんAI疲労の記事では、筋肉痛はトレーニングが機能している証拠であると主張しました。まだ真実です。しかし、続く真実は難しいです。重量は上がり続けます。通常のジムでは、快適な重量を選び、永遠に維持できます。誰もがあなたのバーにプレートを追加することはありません。現在のソフトウェア景況では、新しいモデルリリース、新しいエージェント機能、新しいワークフローが誰かによって発見され共有されるたびに、バーは移動します。静止していても、最終的に重量が押しつぶします。現在、ソフトウェア業界には快適なスペースがありません。個々のエンジニア、チーム、会社にはありません。安全な位置は、継続的な動きだけです。エンジニアリングリーダーにとって、重要なのは、チーム全体が動いているか、または動いていた人だけが動いているかです。
現在、注目を集めている物語がひとつあります。AIは私たちを疲労させているというものです。エンジニアたちは以前よりも多くのコードを書いていますが、以前よりも悪い状態です。「AI疲労」という用語が使われており、多くの意見が集まっています。あるソフトウェアエンジニアは、Business Insiderに、先月が彼の最も生産的な月であり、同時に最も疲れた月だったと書いています。Vibeコーディングの本を書いたSteve Yeggeは、The Pragmatic Engineerに、昼寝をして、AIを使用した作業を3時間に制限していると話しています。スタートアップの創業者たちは午後2時に壁に当たるようです。この月で最も共有された投稿のひとつは、AIが最も使用する人々に「吸血鬼効果」をもたらすと警告しています。しかし、誰もが気づいていないことがひとつあります。疲労を最も報告している人々は、懐疑主義者ではありません。彼らは真の信者です。Yeggeの採用スケールのレベル1にいるエンジニアたちは、AIを全く使用していません。オートコンプリートは使いますが、ほとんどの作業は従来の方法で行います。彼らは少し不安を感じるかもしれませんが、疲労しているわけではありません。レベル5、6、7にいるエンジニアたちは、AIを全面的に採用しています。複数のエージェントを実行し、複雑なワークフローを管理し、以前想像できなかったスピードでコードを書いています。彼らは帰宅してからも疲労しています。このパターンは私たちに何かを教えてくれるはずです。私は、それが教えてくれるものは「AI疲労」が完全に誤った診断であるということだと思います。あなたには疲労の問題がない。トレーニングの問題がある。デッドリフトを初めて行ったときを思い出してください。特に重い重量ではありませんでした。ただ、動きそのものでした。翌朝に起きると、全身が解体されて再び組み立てられたような感じでした。足は痛かった。背中は痛かった。存在しないと思っていた筋肉が最も不快な方法で自己表現しました。もし誰かがその日のあなたの生産性を測定したなら、見た目はひどかったでしょう。座るだけで痛みを感じるほどでした。合理的に結論付けることができたでしょう。デッドリフトは持続不可能である。人間の体はそれに向いてない。コストは利益を上回っている。しかし、もちろん、6ヶ月後には2倍の重量を持ち上げて、終わった後に全然大丈夫です。体は新しい経路を構築しました。適応しました。以前、全ての意識を集中させて行っていた動きが、自動的に行えるようになりました。痛みはあなたが壊れていることを意味しません。新しいものを構築していることを意味します。これは、AIを使用した作業が起こっていることと同じです。誰も話していない認知負荷従来の方法でコードを書くとき、脳はすでに慣れたプログラムを実行しています。同じことを何千回も行ってきたので、キーストローク、パターン、デバッグのリズムがすべて自動化されています。毎日の通勤のように、技術的には複雑ですが、夕食について考えることもできるほど慣れています。AIを使用した作業は、根本的に異なる認知タスクです。コードを書くことはもうありません。指示し、評価し、決定し、複数のエージェント間でコンテキストを切り替え、自分で書かなかった出力を確認し、AIが実装する選択をリアルタイムで検証しながら、建築意図を頭に保持しています。それは、同じ仕事を速く行うことではありません。それはまったく異なる仕事です。まだ脳が効率的な経路を構築していません。すべての決定はまだ意識的です。すべてのレビューには積極的な努力が必要です。品質を監視し、並行するワークフロー全体のコンテキストを維持し、AIの出力を常に検証する判断を下します。したがって、この作業の3時間は、従来のコーディングの8時間よりもあなたを疲労させることができます。これは、最初の週のジムに行くときの認知的な同等です。採用カーブは実際には疲労カーブですYeggeのAI採用の8レベルフレームワークは、疲労カーブとほぼ完全に一致していますが、私は彼がそのつもりで書いたわけではありません。レベル1と2では、AIをほとんど使用していません。オートコンプリートは使いますが、認知負荷はほとんどありません。疲労もありません。レベル3から6では、深いところに入っています。エージェントに更多の自律性を与え、行ごとのレビューではなく、より全体的なレビューを行い、複数のエージェントを実行し、18ヶ月前に存在しなかったワークフローを常にナビゲートしています。これが疲労の原因です。これが重いデッドリフトです。レベル7と8では、面白いことが起こり始めます。オーケストレーションシステムを構築しました。AIはより自律的に動作します。信頼できるものとチェックするものを学習しました。Matt Shumerは、AIに何を構築するかを伝え、4時間後には完成した作業に戻ることができます。適応が始まっています。疲労は均等に分布していません。中間でピークに達し、現在多くの初期採用者が座り込んでいる場所です。疲労が普遍的に感じられるのは、AIについて最も話している人々が、学習曲線の最も難しい部分にいるからです。「運転疲労」についての記事は誰も書いていません運転を学ぶことを思い出してください。高速道路に合流したとき、運転はあなたの人生を握ったかのようにハンドルを握りました。30分間の運転の後、完全に疲れ果てていました。脳は最大容量で動作していました。ミラーをチェックし、速度を管理し、他の運転手を予測し、道路標識を処理し、すべて同時に、すべて意識的に行っていました。今では、ポッドキャストを半分聞きながらサンドイッチを食べながら1時間運転できます。タスクは変わりません。あなたが変わりました。脳は運転のための効率的な神経経路を構築しました。以前、全意識を集中させて行っていたタスクを、バックグラウンドプロセスに圧縮しました。誰も「運転疲労」という記事を書きませんでした。誰も車が「吸血鬼効果」を運転手に行使することを示唆しませんでした。私たちは、直感的に、疲労が一時的なものであることを理解しました。新しいことを学ぶためのコストです。現在の議論で欠けているのはその部分です。「AI疲労」は、技術の恒久的な特徴として扱われていますが、実際には移行コストです。トレーニング中の痛みです。慢性の病気ではありません。これがなぜ快適さよりも重要かこの区別は単に語彙的なものではありません。問題をどのように診断するかによって、対処方法が決まります。「AI疲労」が技術の恒久的な特徴である場合、Yeggeの3時間の制限は永久に上限となります。企業は、エンジニアが1日を通して生産的に働くことができないことを計画する必要があります。「吸血鬼効果」は入場料であり、我々はそれに慣れる必要があります。しかし、それがトレーニング中の痛みである場合、戦略は完全に異なります。負荷を管理します。徐々に構築します。痛みがあるからとジムを辞めることはありません。今日の疲労レベルが明日の疲労レベルであると仮定しないことも重要です。この段階を乗り越えるエンジニアたちは、AIを指示し、レビューし、並行ワークフロー全体の建築意図を維持するための認知経路を構築するでしょう。3時間の壁は5時間、7時間に移動します。彼らはより努力しているのではなく、作業が同じ努力を必要としないようになるからです。一方、レベル2に留まるエンジニアたちは、快適で、馴染みがあり、疲労していないでしょう。しかし、彼らは他の人に比べてかなり悪い立場に置かれるでしょう。トレンドに追いつけなかったからではありません。トレーニングを開始しなかったからです。本当のリスク：痛みとけがを混同すること1点を明確にしたいと思います。トレーニング中の痛みと実際のけがの違いがあります。これも適用されます。あなたが「バイブコーディング」を行っていて、14時間働き、4時間睡眠し、アドレナリンで走っているのなら、それはトレーニングではありません。それは過度のトレーニングです。ジムでは、過度のトレーニングは何も構築しません。壊します。Yeggeの3時間の観察は、永久の天井としてではなく、現在の回復ニーズの信号として価値があります。トレーニングの初期段階では、セッション間の休憩時間が必要です。適応するにつれて、より多くのボリュームを処理できるようになります。焼き尽きる人々は、3時間の集中したAIを使用した作業を行っている人々ではありません。フィードバックループがあまりに魅力的で、止めることができない人々です。これは、私が前に書いたスロットマシンのダイナミクスと同じです。答えはジムを避けることではありません。賢くトレーニングすることです。集中したセッション、実際の回復、漸進的な進歩です。誰もが予測していない予測ここで、私が思うのは、次の12〜18ヶ月間に何が起こるかです。「AI疲労」の物語は今年のうちにピークに達するでしょう。さらに多くの記事、さらに多くの心配、たぶんいくつかの有名なエンジニアがAIツールから「休暇」を取るでしょう。これは意味のある反動のように感じられるでしょう。しかし、それは静かに消えます。人々がAIを使用を止めたのではなく、初期の採用者が適応を終えたからです。3時間の壁は、1年半以上AIを使用している人々にとっては遠い記憶に感じられるでしょう。彼らは、以前forループを書いたように、AIのワークフローを指示するでしょう。考えなくても。痛みを乗り越えた人々とそうでない人々の間のギャップは巨大になるでしょう。AIスキルが稀であるからではありません。適応自体、指示、評価、オーケストレーションの用語で考える能力が、1つのグループにとっては第二の性質となり、もう1つのグループにとっては完全に異質なものとなるからです。トレーニング中の痛みに対する最悪の対応は、常に同じです。ジムを止めることです。リーダーにとっての意味現在、エンジニアリングチームを率いている場合、実際に何を見ているかを理解しましょう。最も生産的なエンジニアは、同時に最も疲れているエンジニアです。これは矛盾ではありません。適応が進行中である最も明確な信号です。AIの採用を減らすことで対応しないでください。疲労が実在しないと主張することで対応しないでください。良いコーチのように対応しましょう。トレーニングの負荷を管理しましょう。AIを使用した集中した作業のセッションを、真正な回復の時間と交互に行います。新しい認知スキルを構築している間、効果的に短時間で作業できるように人々に許可を与えます。出力は依然として以前の倍になります。これを正しく行う会社は、年末までに適応したチームを持つことになります。疲労を無視したり、疲労に応じてAIから撤退したりする会社は、最悪の結果の両方を得ることになります。疲労しているエンジニアがいて、カーブの最も難しい部分に到達できませんでした。私たちは新しい技術の副作用を経験していません。新しい働き方のトレーニングの初期週にいます。痛みは、それが機能している証拠です。痛みに身を任せ、管理し、脳が自然に適応することを信じましょう。自然界の他のすべての適応システムと同じように。適応します。
それは美しい夏の日でした。私の家族は私が海に行くことを待っていました。２時間前に「５分で行く」と言っていましたが、まだ行っていません。「もうすぐ行く」とつぶやきました。コードはほぼ正しかった（２時間前から）。そのとき、私は気づきました：私はデバッグしていない。私はギャンブルをしていた。あなたのIDEの中のスロットマシンもし、あなたが「vibe coding」を経験したことがあるなら、その感覚を知っているはずです。あの引き付けられる力。那声が「あと１つのプロンプト、ベイビー」と言っている声。AIの制限が実際に助けになって、あなたがよく眠ることができるようになる。これは偶然ではありません。Vibe codingには、スロットマシン、ビデオゲーム、ドゥームスクロールのアディクティブな心理構造があります。メカニズムを説明しましょう：変動報酬スケジュール： 時々、AIは最初の試行で成功します。時々、１５回のプロンプトが必要です。時々、予想外のものを与えてくれます。あなたは何が起こるか分かりません。その予測不可能性は、心理学者が変動比率強化スケジュールと呼ぶもので、アディクティブな報酬パターンの中で最も強力なものです。スロットマシンやルートボックスの背後にある原理と同じです。ニアミス効果： コードは ほぼ正しい。実行はできますが、バグがあります。論理は正しいですが、構文は間違っています。これらのニアミスは、スロットマシンでほぼ勝つときと同じ神経パスウェイをトリガーします。脳は「ほぼそこまで」と「もう１つの試行で絶対に機能する」と解釈します。なぜプロフェッショナルエンジニアは（部分的には）免疫を持っているのかここに面白いことがあります：プロフェッショナルソフトウェアエンジニアは、実際には menos アディクティブなvibe codingに抵抗しています。最初は、逆のように見えます。コードを最も理解している人々が、コードを書くAIに最も興奮するべきではないでしょうか。しかし、実際に何が起こっているか考えてみましょう。プロフェッショナルエンジニアにとって、変動報酬は「AIが私が書くコードと同じレベルのコードを書くか、失敗するか」というものです。那は特に興奮するものではありません。彼らは自分でコードを書くことができます。AIは生産性ツールであり、魔法ではありません。しかし、 コードを書くことができない 人にとっては、全く異なります。毎回、AIが機能すると、それは奇跡です。ゼロの能力から突然、ソフトウェアを作成する能力に。That’s not optimization—that’s 変換。That’s the rush I felt when I first started my engineering career, when...
エンジニアリング組織が拡大するにつれて、開発を遅くするプロセスの層が蓄積されます。ある程度のサイズ以上の組織を成長させたエンジニアリングリーダーであれば、誰でもこのパターンを知っていることでしょう：まず基本的なScrumから始まり、クロステームの依存関係が調整会議を必要とし、最終的にSAFeのようなフレームワークを使用してすべてを管理することを検討することになります。私は一度、3次元の組織マトリックス（別の製品組織を除く）を持つエンジニアリング組織を運営していました。結果は、VPが遅くなる速度に苛立んでいたこと、エンジニアが「プロセスオーバーヘッド」が遅れの原因であると非難していたこと、そしてイノベーションが官僚主義の重さの下に停滞していたことです。そこにいたことがある人であれば、イノベーションに対するプロセスタクスは実在し、高価です。AIは今、逃げ道を提供しています。ただコードを書く速度を上げるという明らかな第一の効果だけではなく、エンジニアリング組織が運営される方法を根本的に変える可能性のある第二の効果を通じてです。生産性を超えて：組織への影響多くの注目がAIの個々のコード作成タスクを加速する能力に焦点を当てている一方で、より変革的な潜在力は、組織の複雑さの必要性を減らす方法にあります。個々の能力を強化することで、AIはプロセスが最初に解決しようとした多くの調整問題を体系的に排除しています。「フルスタックエンジニア」の理想を考えてみましょう。歴史的に、拡大した組織では、これはしばしば現実よりも願望でした。パラレルな組織構造がScrumチームを作成することが多かったのです。今日、AIはこの方程式を劇的に変えました。エンジニアは、AIがリアルタイムで知識のギャップを埋めてくれるので、不明な部分のコードベースまたはテクノロジースタックで効果的に作業できます。結果は、チームが手渡しを必要とする回数が減り、組織を苦しめる調整オーバーヘッドが軽減されることです。この機能の拡張は、アーキテクチャにも適用されます。正式なアーキテクチャレビューミーティングを待つのではなく、エンジニアはAIを初期の「スパーリングパートナー」として使用して、アイデアを開発して洗練することができます。エンジニアは、AIと対話して仮定を挑戦し、潜在的な問題を特定し、提案を強化することができます。人間のレビューアーに到達する前に、AIアシストの提案を非同期で共有することができます。多くの場合、これらのAIアシストの提案は、正式なミーティングが必要ないように、カレンダーディレイと調整の頭痛を排除することができます。アーキテクチャは依然として適切なスクラチニを受け取りますが、カレンダーの遅れや調整の頭痛なしでです。品質保証もプロセスを簡素化する別の機会を提供します。従来の開発サイクルには、開発とQAの間で複数の手渡しが含まれ、バグが新しいサイクルを引き起こします。AIは、開発者が包括的なテスト（ユニットテスト、統合テスト、エンドツーエンドテストを含む）を日常のワークフローに統合することで、このサイクルを圧縮しています。問題を早期に、より信頼性高く検出することで、AIは従来の開発を遅くする往復を減らします。チームは、往復を減らして、高い品質の基準を維持できます。おそらく最も重要なのは、これらの個々の機能強化が組織の簡素化を可能にしていることです。複数のグループ間で複雑な調整に依存していたチームは、より自律的に動作できるようになりました。複数の専門チームが必要だったプロジェクトは、より小さく、より自給自足のグループによって処理できるようになりました。多くの大規模組織が採用している、複雑なスケーリングフレームワークは、チームがAIによって機能を拡張できる場合、必要ではなくなります。15分のルール：アジャイルプロセスの再考これらの変革は、従来のScrumプロセスをストリームライン化する機会を生み出します。AI強化チームのために、個人の生産性の「2分のルール」を考慮してください：「15分以内にAIエージェントを正しくプロンプトして何かを実装することができる場合は、バックログ/計画プロセスの全体を通じてタスクを実行するのではなく、すぐに実行してください。」このアプローチは、効率を大幅に高めます。AIが作業をしている間、エンジニアは他の優先事項に集中できます。AIソリューションが不足している場合は、バックログのための適切なユーザーストーリーを作成できます。適切な統合を使用すると、小さな改善は継続的に行われ、より大きな取り組みは依然として適切な計画の恩恵を受けることができます。私たちが見ているパターンは、よりスリムなソフトウェア開発モデルの出現を示唆しています。人間中心のアジャイルの原則を維持しながら、年月を経て蓄積したプロセスオーバーヘッドの多くを排除します。AI強化エンジニアリングの時代のリーダーシップエンジニアリングリーダーにとって、この変革には、組織設計の根本的な再考が必要です。チームが成長するにつれて、プロセス、専門化、調整メカニズムを追加するという反射は、もう適切なアプローチではないかもしれません。代わりに、リーダーは以下の点を検討する必要があります： 個々のエンジニアの有効スキル範囲を拡張するAI機能への大量投資 必要なチームサイズと専門化に関する仮定に挑戦する AIの調整削減効果を活用した簡素化されたプロセスモデルを実験する 従来の開発メトリックに加えて、「プロセスタイム」の削減を測定して最適化する 繁栄する組織は、AIを単なる生産性ツールではなく、根本的によりシンプルな組織構造を可能にするものとして認識する組織です。階層を平坦化し、手渡しを減らし、調整オーバーヘッドを排除することで、AIは、スタートアップのイノベーションスピードと大規模エンジニアリング組織の問題解決能力を組み合わせる可能性を提供します。ソフトウェア開発における20年間のプロセス複雑化の後、AIはついにアジャイルマニフェストの原初の精神に戻ることを可能にするかもしれません：プロセスやツールよりも個々と相互作用を重視する。エンジニアリングの未来は、ただ速くなるのではなく、劇的にシンプルになるのです。
