開発者がツールに愛着を持つ理由：ツールは信頼をエンコードするから

約6年前、私たちはIDEに関する記事を掲載しました。その要点は、IDEがあまりにも強力で高機能になっているため、誰かがVimやEmacsを原始人のように使っているのは驚くべきことだ、というものでした。挑発的な記事でしたが、多くの開発者をかなり動揺させました。コメントは両方の立場から寄せられ、開発者の働き方を理解していないと記事をこき下ろす人々や、一日中Emacsの良いニュースを説く開発者たちからのものでした。しかし、それ以上に、これらのツールがなぜ実際に役立つのかについての素晴らしい議論がありました。 初心者にとって、VimやEmacsは直感的でないターミナルプログラムのように見え、使用（そして終了）するために秘密のキーストロークを記憶する必要があるかもしれません。しかし、経験豊富なユーザーにとっては、思考と同じくらい自然に感じられることがあります。あるコメントは、David ThomasとAndrew Huntによる「The Pragmatic Programmer」を指摘しており、開発者――彼らが（あるいはかつて）職人であるならば――は「鋭いツール」を必要とし、それは手の延長のように感じられると説明しています。VimやEmacsは、その無限のカスタマイズ性により、あなたの正確な手とワークフローに合うように成形することができます。ツールへの習熟と信頼を築き、それらを自分に合わせてハッキングするために時間を費やすことは、深い配当をもたらします。 このエージェンティブエンジニアリングの時代において、新しいツールは自然言語で話しかけるターミナルです。コーディングエージェントは、よく作られたコードを書く開発者の精度と具体性を欠いていますが、アプリケーション全体を fraction の時間で出力できます。今日でも響き渡る疑問は、その出力が信頼できるかどうかです。私たちの最後の開発者調査では、開発者がAIを使用すればするほど、AIへの信頼が低下することがわかりました。使用率は76%から84%に上昇しましたが、信頼度は40%から29%に低下しました。 ツール自体は新しく、その能力は絶えず変化しています。もしあなたのキッチンナイフが常に形、重さ、刃先を変え続けるなら、毎回再学習しなければなりません。それは信頼を築くのが難しいツールです。しかし、それはまた、そのツールをどのように使用するか、その周囲のプロセス、そしてツールがプロセスをどのように強化するかという欠陥も示しています。あなたのお気に入りのナイフ、IDE、絵筆、あるいは何であれ、それを信頼するのは、それと築き上げた信頼、そしてその周囲のプロセスによるものです。 この記事では、ツールがどのように信頼できるプロセスを構築するか、ツールの変更が壊れたプロセスをどのように浮き彫りにするが修正できないか、そしてツールと文化がどのように協力して新たな信頼を構築できるかを見ていきます。 ツールはプロセスの一部です 開発者ツールは、ソフトウェア開発全体とともに、そして個々の開発者とともに動作し進化します。もしあなたがターミナルで作業し学習を始めたなら、IDEやグラフィックインターフェースが存在しなかった時代に、コードを作成する方法の理解には、それらのターミナルとターミナルテキストエディタが含まれます。IDEを追加することは、新しいツールを学ぶだけでなく、コードを書くプロセスを再構築することを必要とします。 ターミナルからIDEへの移行が困難なプロセスシフト（あるいは、一部の人々が言うように、不要なもの）であるならば、どちらかからエージェンティブコーディングツールへの移行はさらに困難です。「AIプログラミングのいくつかを積極的に受け入れることに対する私の躊躇の一つは、IDEの方が速いからです。なぜなら、IDEがどのように機能するかを知っているからです」と、開発者生産性アドボケイトのTricia Geeは述べています。「VimやEmacsを非常にうまく使いこなす人々と一緒に働いたときも、同じことを見ました。IntelliJ IDEAのリファクタリングツールを使うこともできます。彼らは、はい、しかしそれは学習曲線が必要です。私は whatever tool it is を使うのに長い時間を費やしました。私の指はやり方を知っています。どんなツールであれ、ツールを非常によく理解することは、多くの無意識の能力になります。」 その筋力記憶、コードレベルでソフトウェアがどのように動作するかについての暗黙知を構築することは、開発者がコードを生成・改善するためにツールを信頼することを可能にします。一方、AIエージェントはより速く、より不透明で、予測可能性が低いです。コードの代わりに曖昧な言語を使用してソフトウェアを作成します。「コードはソリューションの正確な表現です」とC++の作成者であるBjarne Stoustrupは述べています。「英語は、曖昧でなければならないことを表現するには不十分な言語です。」信頼できるツールは予測可能で、信頼性があります。EmacsやVimで繰り返しイテレーションする必要はありません。 IDE、コンテナ化ツール、静的アナライザーのようなほとんどの開発者ツールでは、境界がどこにあるかを知っています。それらはその役割を持ち、それを超えません。しかし、AIはSDLCツールチェーンのあらゆる部分にその道を見つけています。これは、開発者がAIに対して持つ信頼の低下がプロセス全体に適用されることを意味します。コードの生成は速くなるかもしれませんが、それを検証し、高価な本番障害を引き起こさないと開発者が信頼できるレベルにするには、しばしば時間がかかります。 ツールはプロセスをエンコードするが、修正はしない エージェンティブコーディングツールは、ソフトウェア開発プロセスの性質を変えます。以前のプロセスを中心に登場したツール――リンター、自動単体テスト、CI/CDなど――は、この変化したプロセスでは現在の形では機能しないかもしれません。 それらのツールはプロセスをエンコードしましたが、それ自体がプロセスではありませんでした。優れたCI/CDツールがあっても、より速く出荷できるわけではありませんでした。優れたIDEがあっても、より良いコードを書けるわけではありませんでした。ストーリーポイントを持つ課題追跡システムがあっても、作業をうまく見積もれるわけではありませんでした。プロセスのいくつかは、文化として、ソフトウェアを構築する人々の行動や規範として存在していました。新しいツールはしばしば組織文化の変更を意味します。 この話は、大規模なエンジニアリング組織で働く人なら誰でも聞き覚えがあるでしょう。新しいツールは、その約束が何であれ、既存の文化やプロセスに適合しない場合に失敗することがあります。成功するツールは、開発者が受け入れ、理解できる方法で文化とプロセスをシフトさせることを必要とします。皆さんは構築と問題解決が大好きなので、それをより良く助けないツールは無視されます。 エージェンティブコーディングは、開発者がより速く問題を解決できるようにしたため、急速に普及しました。しかし、コードの作成がほぼ些細なことになったとき、既存のプロセスの多くの欠陥を露呈しました。不明瞭で変化する要件の問題は常にありましたが、今や問題を解決するには、「問題」と「解決」の両方を厳密に定義する必要があります。 コードは（ほぼ）無料かもしれませんが、検証は無料ではありません。新しいボトルネックはコードレビューになりました。古いジョークは、PRをすぐに承認してほしいなら、100行変更しろ、というものでした。コーディングエージェントは一瞬で数百行のコードを変更し、人間がレビュー（またはゴム印を押す）ために巨大な差分を送信します。LLM-as-a-judge はここでスケーラブルなソリューションとして進化していますが、AIがAIが書いたコードをレビューできると信頼するためのエンジニアリング方法は、作業が必要です。 同じ観点から、コードを実行することも無料ではありません。クラウドネイティブ時代には、アプリケーションが消費するコンピューティング、メモリ、トラフィック量の要因となるインフラストラクチャのコストがあります。ホストされている依存関係とAPIのコストがあります。そして、予算を立てるのが最も難しい、障害のコスト――ダウンタイム、セキュリティ侵害、機会費用――があります。これらのコストを考慮しない（またはできない）ソフトウェアを生成するツールは、それだけの価値がないかもしれません。そして、信頼性が高く、信頼できるソフトウェアを生成していたプロセスに負担をかけます。 多くの人々にとって、エージェンティブコーディングのおかげでSDLCは壊れているように見え始めています。当然、これらの人々は、AI SRE、自動コードレビュー、メモリおよびコンテキストマネージャー、コントロールプレーンとハーネスの改善など、新しいツールでその亀裂を修復しようとしています。これらはすべて、AI対応のソフトウェア組織におけるツールセットへの堅実な追加です。しかし、特に文化とプロセスが変わらない場合、ツールだけでは物事は解決しません。より良いツール（人々が使わないかもしれない）を持つ壊れたプロセスは、依然として壊れています。 より良いプロセスで信頼を築く 古いSDLCでは、プロダクトマネージャーはリサーチ、顧客との会話、競合理解に基づいて機能要件を作成していました。アーキテクトは、長年の経験と既存の技術スタックの理解に基づいてソフトウェアを仕様化していました。エンジニアはそれを構築し、コードロジックと既存のコードベースの知識に基づいてコミットをレビューしていました。QAは、レビューし、その経験に基づいてソフトウェアを壊そうとしていました。