AIコードにおける80/20の法則

AIは10分間で私の機能の80%を書き上げた。コードは綺麗に見えた。ロジックも筋が通っていた。初回から動作した。最高の気分だった。

しかし、AIは最初の80%には有用だが、最後の20%には役に立たない。

AIはハッピーパス（正常系）を最適化する。すべてがうまくいく世界を想定して構築するのだ。しかし、実際のソフトウェアは、物事がうまくいかない世界で動くものである。

最近、Sol Email Workerを構築した。AIは20分でコアロジック、スレッディング、ルーティングを生成した。それは簡単な部分だった。

最後の20%には、私自身の専門知識が必要だった：

• 重複排除：重複メッセージの処理。 • 送信者スキップロジック：自身のメッセージの処理を避ける。 • エラーリカバリ：予期しないAPIレスポンスの管理。 • ログ出力：午前2時でもデバッグを可能にする。

AIは私が指示した通りに動いた。私がエッジケースについて指示しなかったのは、まだそれらを深く考えていなかったからだ。

我々には測定上の問題がある。コード行数やクローズされたチケットを追跡しているが、これらの指標は「速い80%」を評価するものだ。エラーハンドリングやnullチェックに費やされた時間を追跡する者は誰もいない。

その20%はダッシュボード上では見えないが、そここそが真の仕事が行われる場所だ。私は現在、「プロンプトからリリース（prompt-to-ship）までの時間」を追跡している。これは最初のプロンプトから、安定したプロダクション機能としてリリースされるまでの時間だ。この数値は、常にAIの生成時間の少なくとも4倍になる。

現在の私のワークフローは以下の通りだ：

• すべてのタスクに対し、AIの生成時間の4倍の時間を予算として組み込む。
• アンハッピーパス（異常系）についてプロンプトを出す。ネットワークが失敗したり、APIがnullを返したりすることを想定するようにAIに指示する。
• 初稿はゴールではなく、出発点として扱う。

30秒の生成の後にエラーハンドリングに費やした3時間は、無駄ではなかった。それこそが本来の仕事だったのだ。AIは、仕事を「構造を書くこと」から「コードを実用的なものにすること」へとシフトさせた。

コードを実用的なものにする作業は時間がかかる。それには、特定のコンテキスト、ユーザー、そしてコードベースの履歴が必要だ。それこそが「専門知識」の意味である。

AIは既知の領域で機能する。エッジケースは、常に未知の領域なのだ。

次にAIのデモを見て感銘を受けたときは、デモが終わった後に何が起きたのかを問いかけてみてほしい。

Source: https://dev.to/amrree/the-8020-rule-of-ai-code-id

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