信頼の育成

エントロピーの克服：信頼を育む

「エントロピーの克服」の一部

AI生成コードに関して私が抱える問題のほとんどは、信頼に関連しています。このチケットを書いた人を信頼できるか？ PRを開いたエンジニアがチケットを理解し、コーディングエージェントに正しく実装するように導いたと信頼できるか？ コーディングエージェントの実装を信頼できるか？ テストスイートが本番環境に障害が発生する前にそれを捉えてくれると信頼できるか？ CI/CDが変更を正しくビルド、テスト、デプロイしてくれると信頼できるか？ AI生成コードが本番環境で問題を起こしたときに、オブザーバビリティ設定が私たちに警告してくれると信頼できるか？ AI SRE（サイト信頼性エンジニア）が問題を正しく診断し、緩和を助けてくれると信頼できるか？ GitHubが最も必要としている時にインシデントを起こさないと信頼できるか？

信頼は獲得するのが難しく、失うのは簡単です。そのため、エンジニアリングチーム内で信頼の文化を育むことが極めて重要だと考えています。エンジニアが正しいことをすると信じる必要があります。

説明責任の奨励

次のようなことを明確に伝えることが役立つと気づきました。「あなたがリリースしたものに対して責任があります。もしこれが本番環境で問題を起こし、あなたがPRを作成したのであれば、それを修正するためにそこにいるべきです。」

エンジニアがリリースしたコードに対して責任を負うのであれば、彼らは好みの方法でコードを生成する権限を与えられるべきです。AIに傾倒していなくても、AIエージェントが非常に速く大量のコードを生成することは認めざるを得ません。コードは依然として生成される必要があり、今や大量のコードを安価に生成できるという期待があります。これに対処するために、コードベースの品質が低下しないようにするための対策を講じることがエンジニアに許可されなければなりません。

健全な組織では、エンジニアはお互いに合理的な品質のコードのみをプッシュすると信頼し合うべきです。私が「合理的」と言うのは、品質にこだわり、常に100%完璧なコードを出荷しようとすることは現実的ではないからです。コーディングエージェントが登場する前から、ほとんどのコードはすでにバグだらけの代物でした！そのため、「十分良い」ソリューションが提供されることは理解できます。多くの場合、私たちは納期の速度と品質をトレードオフし、ある程度の技術的負債を抱えます。

この新しいコーディング時代におけるエンジニアリングの説明責任を促進するために役立つと私が発見したプラクティスをいくつか紹介します。

コーディングガイドライン

明確なテクノロジ戦略を持ちましょう。コードベースにとって何が重要かを決定するために時間をかけ、明確なガイドラインに投資してください。人間とコーディングエージェントの両方のためです。人間がガイドラインを読まなくても、彼らのコーディングエージェントはそれを読み、（ほとんどの場合）それに従います。

決定論的なツーリング

コード品質を保証するために、決定論的なツーリングを多用しましょう。型付き言語、リンター、デッドコード検出、セキュリティスキャン、CI/CDなどです。これらのツールはすべてコーディングエージェントが登場する前から存在し、ずさんなコードとの戦いに役立ちます。（具体的な推奨事項については、フォローアップ投稿にご期待ください！）

小さなPRの強制

レビュー不可能なPRを拒否する権限をエンジニアに与えましょう。可能であれば、レビュー不可能なPRは即座に拒否されるように基準をコード化してください。もちろん、例外の余地を残すようにしてください。

テストの所有

テストケースは手動で記述しましょう。これはビジネスアナリストの仕事に似ています。機能を深く考え、適切なテストシナリオを定義します。チーム内でこれを議論します。コーディングエージェントはテストを実装できますが、テストは人間によって定義されるべきです。

プロダクトへのこだわり

一貫したプロダクトビジョンを持つために、プロダクトと連携しましょう。AIを使って思いついた機能を実装することに夢中になりすぎるのは簡単です。ユーザーに実際に価値をもたらす有用な機能のみを実装するようにしてください！

プロトタイプ

使い捨てコード。コードは現在非常に簡単に生成できるため、さまざまなアプローチを試す良い機会です。コーディングエージェントに1つのソリューションを生成させるだけではいけません。例えば、根本的に異なる3つのアプローチを試して、問題と既存のシステムに最も適したものを選択してください。

成果に焦点を当てる

結果に対して現実的になりましょう。時にはコードが結果ではありません。結果はレポートであったり、何か他のことを達成するのに役立つツールであったりします。このような場合、結果が有用である限り、コードの品質はそれほど重要ではありません。