検証コストこそが、AIコーディングにおける真のコストである

コーディング用のAIモデルを選ぶ際、以前は一つの質問を自分に投げかけていました。

「このタスクにはどのモデルが十分に強力か？」

その質問も間違いではありません。しかし、もはやそれが私の第一の質問ではありません。

より適切な質問は、「出力をどれだけ素早く検証できるか？」です。

この考え方によって、低コストモデルの使い方が変わります。低コストモデルを「大型モデルの弱体版」と捉えるのではなく、「検証パスが短いタスクのための作業員」として捉えてください。

結果をすぐに確認できるタスクは、レビューのコストが低くなります。

• READMEの整理 • 使用例 • コードコメント • チェンジログの記述 • 小規模なフォーマット用スクリプト • Issueテンプレート

モデルがREADMEの段落を誤って書いたとしても、すぐに気づけます。悪い部分を削除するだけです。そのエラーは煩わしいものですが、コストはほとんどかかりません。これこそが、安価なモデルの最適な活用法です。

次のカテゴリーは、テスト可能な作業です。

期待される動作を定義し、テストスイートを実行できるのであれば、初稿には安価なモデルを使用してください。ただし、モデルに対して明確な境界を与える必要があります。

「このヘルパー関数にテストを追加して」と言ってはいけません。

「空の入力、null入力、重複値、無効な設定、デフォルト設定、および通常の入力に対するテストを追加してください。実行時のコードは変更しないでください」と言うべきです。

これにより、モデルを「検証の枠組み」の中で作業させることができます。

自動テストは欠いているものの、明確な手動チェックが可能なタスクもあります。

• CLI出力のフォーマット • 設定例 • マイグレーションのドライランに関するメモ • 小規模なデータ変換スクリプト

これらについては、モデルに以下の内容を含めるよう指示してください：

• コードの実行方法
• 使用する入力
• 期待される出力
• チェックすべきエッジケース

モデルが自身の作業をどのように検証すべきか説明できないのであれば、そのコードを信頼してはいけません。

小規模なリファクタリングは危険です。差分（diff）は短くクリーンに見えるかもしれませんが、隠れたパス、デフォルト値、あるいは権限チェックにおいて挙動が変わってしまう可能性があります。

以下のような箇所に触れるタスクでは、リスクレベルを引き上げてください：

• フォールバック
• デフォルト値
• ルーティング
• 権限
• 請求
• レート制限
• マイグレーション
• 後方互換性

これらのエラーは、標準的なコードレビューでは見つけにくいものです。深いコンテキスト（文脈）の理解が必要になります。

検証コストに基づいて作業を振り分けましょう：

• 検証コスト：低 — 安価なモデルを使用してドラフトを作成する。
• 検証コスト：中 — 安価なモデルを使用し、その後人間が編集する。
• 検証コスト：高 — 強力なモデルを使用し、テストと人間によるレビューを行う。

タスクの規模は関係ありません。検証が困難であれば、たとえ小さなタスクであってもコストは高くなります。

AIコーディングにおいてコストがかかるのは、生成ではありません。「信頼」です。

Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354

Optional learning community: https://t.me/GyaanSetuAi