AIファーストの指令：これがソフトウェアエンジニアリングの未来か？

組織の数が増えるにつれ、"AI-First" とラベル付けされることを競い合い、ソフトウェアエンジニアリングのワークフローを根本的に変える攻撃的な指令を実装するケースが増えています。極端な例では、エンジニアは手でコードを書かず、代わりに複雑な AI エージェントと独自フレームワークのネットワークに依存するよう指示されます。速度の約束は魅力的ですが、現場の実態はしばしば経営層のビジョンとエンジニアリングの現実との間に大きな乖離があることを示しています。

"AI-First" 指令の台頭

最近のソフトウェアエンジニア同士の議論で、ある開発者がトップ10の Fortune 500 企業での衝撃的な体験を共有しました。チームの開発アプローチは、AI でワークフローを補強するだけでなく、人間がコードを書く要素そのものを完全に置き換えるものです。この "AI-First" 戦略には以下が含まれます:

• 必須AI使用: Claude のような LLM の使用が必須で、100 以上のエージェントとスキルファイルからなる独自フレームワークと組み合わせる。
• エージェント主導のコードレビュー: 品質保証の人的要素が自動エージェントレビューに置き換えられている。
• 理解の浸食: このアプローチの重大な副作用として、エンジニアが十分に理解していないコードを出荷し、システムアーキテクチャを深く理解する時間を誰も取らない文化が生まれる。

この変化により、ドキュメントや Jira チケットに「小説の長さの無意味な文章」（"novel-length slop"）が増えるという指摘があります。これは、実質的な意味や正確さに欠けた大量のテキストを生成できる AI の副産物です。

エンジニアリングへの反発

経験豊富な開発者たちは警鐘を鳴らし、このアプローチがソフトウェア開発の核心原則に反すると主張しています。実務者の合意は、AI が実装を加速できても、持続可能なソフトウェアに必要な批判的思考、製品判断、アーキテクチャ監督を置き換えることはできないというものです。

30 年の経験を持つベテラン開発者は、現在のトレンドを「混沌としていて、無駄で、私がソフトウェア開発や基本的なコミュニケーションについて学んできたすべてに反する」と表現しました。

他のエンジニアは、経営層がこれら AI 主導チームの見かけ上の効率性を好む一方で、実際のエンジニアリング組織はその成果に対する信頼を欠いているというパターンに気付いています。場合によっては、ユーザーが全くいないツール（例: MCPs）が作られ、日々のインシデントに悩まされ、生産性の見せかけがシステム全体の不安定さを隠す結果となります。

オーケストレーション vs. 実装

不満は残るものの、ワークフローが変化していることは認識されています。ソフトウェアエンジニアの役割は、コードを書く者からシステムのオーケストレーターへと進化しています。

"私はますます、すべてをゼロから書く人というより、オーケストレーター/レビュアーとしての役割が大きくなっています。AI は実装を劇的に高速化しますが、制約や製品判断は依然として人間中心です。"

これは中間的な立場を示唆しています。AI が定型的なボイラープレートや実装の詳細を処理し、人間は高レベルの設計、制約、プロダクト・マーケット・フィットに注力するという形です。危険なのは、"オーケストレーター" が理解できないコードを出荷せざるを得なくなり、人間の理解という安全網が失われることです。

結論：不確実性の状態

業界は現在、変動期にあります。ある人は現在の AI 主導の混乱を一時的な "悲嘆" や妄想の段階と見なし、別の人は新たなベストプラクティスを発見する過程に過ぎないと考えています。

"AI-First" 指令が持続可能なモデルなのか、企業の空想なのかは別として、明らかなことは時計を5 年前に巻き戻すことはできないということです。次世代のソフトウェアエンジニアリングが直面する課題は、AI 生成の速度と人間の理解の厳密さとのバランスを見つけることです。