効率性の錯覚：なぜAIの「ラストワンマイル」がすべてを台無しにするのか

AIコードにおける80/20の法則について読み、あなたは頷く。

AIは最初の80%のコードを数秒で書き上げる。それは進歩のように見え、スピード感を感じさせる。

しかし、これは罠だ。

残りの20%の作業に、時間の80%を費やすことになる。ここでプロジェクトは頓挫し、開発者は精神をすり減らす。

AIは確率に基づいて動く。次にくる可能性が最も高い単語やコードの行を予測するだけだ。論理を理解しているわけではない。あなたの特定のシステムアーキテクチャを理解しているわけでもない。AIが作り出すのは、完璧な条件下でしか機能しない「ハッピーパス（Happy path）」だ。

ハッピーパスを外れた瞬間、壁にぶち当たる。

私はこれを「検証債務（Verification Debt）」と呼んでいる。

技術的負債は場当たり的な修正から生まれるが、検証債務は理解不足から生まれる。

自分でコードを書くとき、あなたは頭の中にメンタルマップを構築する。なぜその一行が存在するのかを理解している。しかし、AIが書いた場合、渡されるのは自分が構築していない完成品だ。あなたは論理を所有していない。結果だけを所有しているに過ぎない。

コードを理解していなければ、デバッグはできない。AIがわずか一秒で作った間違いを修正するために、何時間も費やすことになる。

生成の速さが「完了した」という錯覚を生む。もう少しで終わる、と思ってしまう。しかし、そこへエッジケース（Edge cases）が襲いかかる。統合に失敗し、セキュリティの欠陥が露呈する。

最後の20%は、単なる「仕上げ」ではない。それは品質の核心だ。テスト、デバッグ、そしてエッジケースへの対応こそがその正体である。

どうすればこれを解決できるのか？

AIの出力を最終製品として扱うのをやめよう。それを「信頼できないデータ」として扱うのだ。

  • テストを先に書く。テストを作成する前にロジックを生成してはならない。AIが回答を出す前に、何をもって「失敗」とするかを定義しておくこと。
  • セグメントごとに検証する。エラーを見つけるために、システム全体の統合まで待ってはいけない。小さなブロックごとに、独立してテストを行うこと。
  • パッチを当てるのではなく、破棄する。AIが生成した関数がテストに失敗したら、一行ずつ修正しようとしないでほしい。それを削除し、別のプロンプトを試すべきだ。AIのミスにパッチを当てようとすると、さらなるエラーを生むことが多い。

80/20の法則は警告だ。AIはスピードを向上させるが、同時に検証するという責任も増大させる。

AIの間違いを直すことにすべての時間を費やしているなら、効率化はできていない。単に、ある種類の作業を別の種類の作業に置き換えただけだ。

ラストワンマイルこそが、コードが実際に動作することを証明する場所だ。完璧に見える嘘に騙されていなかったことを証明する場所なのだ。

Source: https://dev.to/amrree/the-illusion-of-efficiency-why-ais-last-mile-costs-everything-a7g

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