開発者がVimやEmacs、あるいは統合開発環境のようなツールに愛着を持つのは、単にそれらに慣れているからではない。これらのツールが、コードを考え、書き、レビューする方法の一部になるからだ。長期間にわたって経験を積むと、コマンドや手順は暗黙知や筋肉記憶へと変わり、そのツールは手の自然な延長のように感じられる。この関係は、エージェント型プログラミングツールに対するためらいの一因を説明する。エージェント型ツールは完全なアプリケーションを短時間で生成できる一方、精度、透明性、予測可能性に欠ける。
この記事は、ツールと信頼、そしてそれを取り巻くプロセスを結び付けている。信頼できるツールとは、単にタスクを実行するものではなく、その限界や挙動を開発者が把握し、結果を予測できるようにするものだ。一方、AIエージェントツールは能力が絶えず変化し、曖昧になり得る自然言語の指示に依存する。記事が参照する最新の開発者調査のデータによると、AIの利用率は76%から84%に上昇した一方、AIへの信頼は40%から29%に低下した。
ツールは開発プロセスの一部である
ターミナルやテキストエディター、統合開発環境での作業を学ぶことは、単に別個のプログラムを学ぶことではない。コードを書き、理解し、改善するための完全なプロセスを構築することを意味する。そのため、ターミナルから統合開発環境へ移行するには、作業方法を再構築する必要がある場合があり、そこからエージェント型プログラミングツールへ移行することは、さらに大きな転換となる。
開発者生産性のエバンジェリストであるTricia Geeは、開発者が使い慣れた開発環境を利用した方が速い場合があると説明している。指が何をすべきかを覚えているからだ。経験豊富なVimやEmacsのユーザーにも同じことが当てはまる。時間が経つにつれて、開発者がツールを信頼し、コードの生成や改善に利用する助けとなる、無意識の熟練が形成される。
統合開発環境、コンテナツール、静的解析ツールなどの従来型ツールは、その限界や役割について明確なイメージをユーザーに与える。一方、AIはソフトウェア開発ライフサイクルのツールチェーンの複数の部分に入り込むため、AIへの信頼の低下はプロセス全体に影響を及ぼす。コードの記述は速くなっても、そのコードを検証し、本番環境で高コストな障害を引き起こさないことを確認するために、より長い時間がかかる可能性がある。
ツールは壊れたプロセスを修復しない
エージェント型プログラミングツールは開発プロセスの性質を変えた。その結果、静的チェック、単体テスト、継続的インテグレーション、継続的デプロイメントなど、以前のプロセスを中心に発展してきたツールは、現在の形では適合しにくくなる可能性がある。しかし、この記事はツールと、それが体現するプロセスを区別している。優れた継続的インテグレーションおよびデプロイメントのツールが、より速いリリースを保証するわけではない。強力な統合開発環境が、より優れたコードの記述を保証するわけでもない。課題追跡システムも、工数見積もりの正確さを保証しない。
プロセスの一部は、組織の文化、構成員の行動、そしてその基準の中で形成される。そのため、新しいツールは、どれほど大きな可能性を示していても、既存の文化やプロセスと調和しなかったり、開発者が利用する理由を理解していなかったりすれば、失敗する可能性がある。この記事は、エージェント型プログラミングツールが開発者の問題解決を速めるため、急速に普及した一方で、要件の定義、問題の定義、そして解決の意味に関する古くからの欠陥も同時に明らかにしたと指摘している。
コードの生成は以前と比べてほぼ無料になったが、レビューも同じように無料になったわけではない。開発者は、エージェントが短時間で生成した巨大なマージリクエストの変更に直面する可能性があり、これによってレビュアーの負担が増えるか、形式的なレビューが採用されることになる。レビューの範囲を広げるため、言語モデルを判定者として利用する方法が開発されているが、AIが書いたコードをAIがレビューする能力への信頼を築くには、さらなる作業が必要になる。
コードの実行にもコストがある。これには、インフラストラクチャのコスト、コンピューティング、メモリ、トラフィックなどのクラウドリソース、依存サービスやホスト型API、さらに停止、セキュリティ侵害、機会費用などの障害コストが含まれる。こうした要素を考慮せずにコードを生成するツールが、必ずしも有用とは限らない。信頼できるソフトウェアを生み出していたプロセスを弱体化させる可能性もある。
責任とプロセスを通じて信頼を築く
従来の開発サイクルでは、信頼は相互に結び付いた役割の間で分担されていた。プロダクトマネージャーが要件を定義し、アーキテクトがソリューションを設計し、エンジニアがソフトウェアを構築して変更をレビューし、品質保証チームが障害点をテストし、その後、DevOpsおよびSREの専門家がリリース後の性能とリソースを監視した。この分担により、個人やツールが境界を越えてシステムに害を及ぼす可能性を減らすことができた。
この記事は、AIに支援された開発サイクルにも同様の原則が必要だとしている。それは、人々と協働すること、責任と説明責任を明確にすること、プロセスを共有し段階的に改善すること、そして誤りの機会を減らすことだ。AIが関与した箇所を明示しつつ、人間が責任を負う当事者であり続けるべきである。
エージェントが変更を作成したからといって、責任がエージェントに移るわけではない。変更をリポジトリにプッシュする人はコードに対して責任を負い、マージリクエストを承認する人はその承認に対して責任を負う。この記事が示す論理によれば、変更によって本番環境が壊れた場合、開発環境やツールに責任を押し付けることはできない。責任は、その変更が通過することを許した人々とプロセスにある。
この転換は、協働に関する別の課題ももたらす。エージェントによって、1人の開発者がプロダクト要件からDevOpsの運用まで広範なタスクを実行できるようになる可能性がある。その結果、特定のコードベースを専門とするデザイナーやエンジニアと連絡を取らない、孤立した島へと変わる可能性が高まる。この記事は、ツールが作業を迅速に実行できるように見える場合でも、この道筋が巨大なマージリクエストにつながる可能性があると警告している。
基本的な結論は、新しいツールが役に立たないということではない。ツールの改善だけでは、壊れた開発サイクルを修復するには不十分だということだ。組織には、開発者が理解し受け入れられるプロセス、エージェントの役割に関する明確な境界、実質的な責任を伴う人間によるレビュー、そして開発が閉じた個人活動になるのを防ぐ協働が必要である。そのとき、ツールと文化は協力して、AIに依存する開発環境における新たな信頼を築くことができる。