AIがソフトウェアコードの大半を担うようになれば、エンジニアの役割は「コードを書くこと」から「コード生成を支える仕組みを整えること」へと移る――。開発者生産性プラットフォーム「Aviator」の共同創業者兼CEO、アンキット・ジェイン氏はThe New Stackへの寄稿で、今後はプラットフォームエンジニアリングが企業の競争力を左右するとの見方を示した。

ジェイン氏によると、エンジニアの役割は従来のフロントエンド／バックエンドという区分よりも、製品エンジニアとプラットフォームエンジニアへと再編されていく可能性が高い。製品エンジニアは顧客向けのプロダクトを開発し、プラットフォームエンジニアはその開発を支えるツールや基盤を担う。AIによるコード生成が広がるほど、後者の重要性は一段と高まるという。

同氏は、これを「ハーネス・エンジニアリング」と呼ぶか「ループ・エンジニアリング」と呼ぶかは本質ではないと説明する。重要なのは、すべてのエンジニアが依存する共通の開発基盤を整備することだとしている。

一方で、AIが大量のコードを書くようになるにつれ、組織内の摩擦も増えていると指摘した。コード生成のスピードが上がるほど、各チームが個別にプロンプトを設計し、独自のガードレールを設け、エージェントの誤動作を追跡するダッシュボードまで別々に作り始める。共通基盤がないまま、同じ課題を組織内で重複して解いている状況だという。

ジェイン氏は、Thoughtworksのコンサルタントであるバニタ・クマール氏の事例にも触れた。顧客企業のチーム構成を整理する過程で、以前は「プラットフォームチーム」がデプロイ基盤を管理する1チームで十分だったのに対し、現在はAIエージェントを管理する別チームまで必要になっていることが確認されたとしている。

もっとも同氏は、こうした2つのチームの役割は最終的に統合へ向かうとみている。AIが生成するコードの量が増えるほど、その生成プロセスを統制し、検証し、拡張する役割はプラットフォームエンジニアリングに集約されるためだ。その上で「ソフトウェアを作るすべての企業は、最終的には開発ツール企業になる」と述べた。

ハーネス・エンジニアリングが担う領域は広い。第1に、どのモデルやフレームワークの利用を認めるかを決めることだ。これはセキュリティとコストに直結する。第2に、利用量とスケールの管理がある。利用者が10人規模なのか、数百人規模なのかで、直面する課題は大きく変わるという。

第3は権限管理だ。エージェントがエンジニアの代わりに作業するとしても、エンジニア本人と同等のアクセス権をそのまま与えるべきではないとした。第4に、その基盤自体の設計がある。セキュリティスキャナーやリンターが検出した問題を人手で処理するのではなく、エージェントに差し戻して修正させるフィードバックループを構築する必要があると説明した。

ジェイン氏は「AnthropicやOpenAIは、基盤となるエージェント、つまりエンジン部分を提供する。しかし、そのエンジンは個々のコードベースの実情を知らない」と指摘した。その上で、チームの慣行や許容可能なリスク水準、予算といった条件を踏まえてエージェントを作り込めるのは、プラットフォームチームだけだとした。

さらに「この作業を意図的に進めなければ、各チームが粗い仕組みを個別に作るだけになり、問題が起きたときに責任の所在も曖昧になる」と警鐘を鳴らした。

最後に同氏は、AIでどれだけ生産性を高められるかは、どのモデルを使うかや、導入方針をどれほど厳格にするか、あるいはその時々の流行をどれだけ早く追うかで決まるのではないと強調した。「道具を作る人」、すなわちプラットフォームエンジニアを周辺的な存在として扱うかどうかが、最終的な差を生むとしている。