AIはコードを書く。しかし「完了」を定義することはできない。
AIスライドデッキジェネレーターを構築しました。トピックを入力するだけでプレゼンテーションが作成されます。
AIのデモは即座に動作しました。アウトラインを作成し、スライドを作り、ファイルをエクスポートしました。私の画面上では、完成したように見えました。
しかし、完成していませんでした。
AIは、「1人のユーザーが1回だけデッキを作成できること」を証明したに過ぎません。実際のプロダクトは異なります。同時に100人のユーザーを処理できなければなりません。正しく課金できなければなりません。ステップが失敗したときに復旧できなければなりません。そして、実際にPowerPointで開けるファイルをエクスポートできなければなりません。
AIはこれらを追加しませんでした。なぜなら、私が指示しなかったからです。
AIを使って開発する場合、難しいのは機能の説明ではありません。難しいのは、「完了」が何を意味するのかを定義することです。
基盤にはVelobase Harnessを使用しました。これにより、認証、決済、クレジット、データベースの管理を任せることができました。そのおかげで、AIをPPT生成そのものに集中させることができました。
そこで「完成しているように見える」ことと「実際に完成している」ことの乖離が生まれました。私は主に4つのギャップを見つけました。
並行性(Concurrency):AIは、1回の実行が成功すれば機能が完成したと考えます。実際のシステムでは、タスクをキューに分割する必要があります。ワーカーをスケールさせられるよう、各スライドを個別のジョブとして生成しなければなりません。
課金(Billing):AIはクレジットを1回差し引いて終わりにしてしまいます。実際のプロダクトにはステートマシンが必要です。クレジットを確保し、実際の使用量に基づいて決済を行い、失敗時には返金を行う必要があります。
セルフレビュー(Self-review):バックエンドがバックグラウンドで黙ってタスクをリトライしていると、ユーザーには単に読み込み中のアイコンが表示されるだけになります。ステータスを表示しなければなりません。システムが動作していることをユーザーが理解できるよう、「確認中」や「描き直し中」といった表示が必要です。
エクスポート(Export):スライドはブラウザ上では素晴らしく見えても、PPTXファイルでは崩れてしまうことがあります。要件は単にファイルを作ることではありません。ファイルがウェブ上のプレビューと一致していることが要件なのです。
私は指示を変えました。AIに機能リストを与えるのをやめ、受け入れ条件(acceptance criteria)を与えるようにしました。
AIに対する新しいルール:
- デモではなく、本番環境で利用可能なSaaSを構築せよ。
- 100人の同時ユーザーをサポートせよ。
- 構成案の作成とスライド作成には、独立したキューを使用せよ。
- すべてのモデル呼び出しを課金システムに紐付けよ。
- クレジット残高に基づいてタスクを一時停止・再開せよ。
- 各スライドの後にレイアウトチェックを実行せよ。
- PPTXのエクスポートがビジュアルプレビューと一致することを確認せよ。
- 成功時だけでなく、並行性や失敗時のテストも記述せよ。
AIはコードを書くのは速いです。しかし、何をもって「リリース可能なコード」とするかを知りません。AIはローカルでのデモを、完全なシステムであるかのように扱ってしまうのです。
人間の役割は、エンジニアリングの境界条件、失敗ケース、そしてビジネスルールを提供することです。
HarnessがSaaSの基盤を提供し、AIがロジックを補完します。あなたはただ、最も的確なインプットを与えるだけでいいのです。
もしAIで構築した製品をリリースしたことがあるなら、「動く」状態から「顧客に提供できる」状態へと移行する際、最も大きな隔たり(ギャップ)は何でしたか?
出典: https://dev.to/velobasex/ai-can-write-the-code-it-cant-tell-you-when-the-product-is-done-4oh6