HeadlinesBriefing favicon HeadlinesBriefing.com

エントロピーの克服:AIコードへの信頼

Hacker News •
×

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

AI生成コードに関する私の懸念のほとんどは信頼に関するものです。このチケットを書いた人を信頼できますか?このPRを開いたエンジニアがチケットを理解し、コーディングエージェントを適切に導いて実装させたことを信頼できますか?コーディングエージェントの実装を信頼できますか?私たちのテストスイートが回帰を本番環境に到達する前に検出できることを信頼できますか?私たちのCI/CDが変更を適切にビルド、テスト、デプロイできることを信頼できますか?私たちのオブザーバビリティ設定がAI生成コードによって本番環境が壊れたときに警告してくれることを信頼できますか?AI SRE(サイト信頼性エンジニア)が問題を適切に診断し、緩和を支援してくれることを信頼できますか?Git Hubが最も必要なときにインシデントを起こさないことを信頼できますか?信頼は得るのが難しく、失うのは簡単です。だからこそ、エンジニアリングチーム内で信頼の文化を育むことが極めて重要だと考えます。エンジニアが正しいことをすると信頼しなければなりません。

説明責任の促進

以下のように明確に伝えることが有用だと感じます:「あなたが出荷したものに対してあなたは説明責任を負います。これが本番環境を壊し、あなたがPRを作成したなら、あなたはそれを修正するためにそこにいるべきです。」

エンジニアが自分たちが出荷するコードに対して説明責任を負うなら、彼らは好みの方法でコードを生成する権限を与えられるべきです。あなたがAI熱狂者でなくても、AIエージェントが非常に高速に大量のコードを生成することは認めざるを得ません。コードは依然として生成される必要があり、今では大量のコードを生成することが安価になったという期待があります。これに対処するため、エンジニアはコードベースの品質が低下しないよういくつかの対策を講じることを許可されるべきです。健全な組織では、エンジニア同士が互いに信頼し、妥当な品質のコードのみをプッシュするべきです。「妥当な」と言うのは、品質にこだわり、常に100%完璧なコードを出荷しようとすることは非現実的だからです。コーディングエージェントが登場する前でも、ほとんどのコードはすでにバグだらけの混乱状態でした!したがって、「十分良い」ソリューションが提供されることは理解できます。多くの場合、私たちは配信速度と品質をトレードオフし、多少の技術的負債を負います。

このコーディングの新時代において、エンジニアリングの説明責任を促進するために有用だと私が見出したいくつかのプラクティスを紹介します:

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

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

決定論的ツール

コード品質を確保するために決定論的ツールを大量に活用してください。型付き言語、リンター、デッドコード検出、セキュリティスキャン、CI/CDなど。これらのツールはすべてコーディングエージェント登場以前から存在し、質の低いコードとの戦いに役立ちます。(具体的な推奨事項を含むフォローアップ投稿をお楽しみに!)

小さなPRの強制

エンジニアがレビュー不可能なPRを拒否できるようにしてください。可能であれば、この基準を規定化し、レビュー不可能なPRが即座に拒否されるようにしてください。もちろん、例外の余地を残しておいてください。

テストを所有する

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

製品における審美眼

製品チームとタンデムで働き、一貫した製品ビジョンを持ってください。AIを使って思いついた機能を何でも実装してしまうのは非常に簡単です。ユーザーに真の価値をもたらす有用な機能のみを実装するようにしてください!

プロトタイプ

使い捨てコード。コードが今や非常に容易に生成できるため、異なるアプローチを試す良い機会です。コーディングエージェントに1つの解決策だけを生成させないでください。例えば、3つの根本的に異なるアプローチを試し、問題と既存システムに最も適したものを選んでください。

結果に焦点を当てる

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