1行もコードを書かずにAIだけで作れた先に思う事
次に何を作ろうか
自動化できてしまうと、何を作ろうか？と考えてしまう。
とりあえず、既存RailsアプリケーションをGoでAPI化しようと思い、レポジトリを作って移植を始めた。
AI開発で得られた20の気づきは、100%ピュアAI開発の成果物から学んだ20のこと に記載した。
開発物はOSSで公開しているので、実際のコーディングの足跡も残っている。
仕様の追加、バージョンアップも問題なくこなせている。
$20 のCursor月額プランだけで、けっこうイケる感触を持った。
まだManusやDevinのように放置はできないが、いずれエディタの裏側で、非同期な開発環境が接続されるだろう。
1週間経って振り返っても、以下のポイントを外さなければ、いくらでも再現できると思える。
- 設計の分割：AIの混乱を防ぐために
- 仕様書の分割：AIが理解しやすい単位で
- Chat指示の汎用化と保存：スキマ時間の有効活用
- Debug Loggerの単体化：解釈の統一と状態把握
- テストの階層的分割と順列化：テスト駆動開発の基盤
- CIスクリプトによる段階的チェック：エラー発生時の即時停止
- 前処理エラーの別テスト化：テストの責務を明確に
- Cursorへの集中：Agentを絞るメリット
- Rulesの分割：コンテキストに応じた指示の細分化
- ユースケースの明示と使用例の追加：AIの迷いをなくす
- New chat発動のタイミング：コンテキストのリセット
- local_ci.shのループ化：テスト駆動開発の自動化
- コミット指示：品質ゲートとしてのGit管理
- 仕様の曖昧さを洗い出す：AIに分析させる
- 仕様書を読み込むタイミングを増やす：情報の参照性を高める
- 仕様との乖離を見逃さない：AIの「拡大解釈」をチェック
- ベストプラクティスを明言する：AIの迷いを減らす
- ベストプラクティスと仕様の矛盾を想定する：解決ルールの明文化
- lint, fmtの後回し：実装安定後のコード整形
- 自動変更の禁止を決める：仕様書の保護
さて、何を作ろうか。
ソロプロダクト開発の新しい可能性
「AI自動開発は、YouTuber型とNetflixオリジナル型に分かれそう」を思い出す。個人か、大規模化か。
まずは個人で考えよう。
スケーラビリティの手応え
AI開発の最大の手応えは、開発スケーラビリティだ。これは言うまでもない。
従来の開発では、コード量が増えるほど開発者の負荷も増加する。
AI開発では、仕様書が明確であればあるほど、AIの実装スピードが向上する。
組み合わせが爆発するケースでも問題はない。仕様変更が多岐に渡ることを想定した依存関係解消は、先人たちの知恵で洗練されている。
リスク：
仕様の矛盾を起こさないことが重要だ。
したがって、仕様の詳細をバッチリ描ける領域でやった方がよい。
それはつまり、ユーザーニーズを理解している場所だ。
改修の柔軟性
機能追加や改修も、AI開発なら驚くほどスムーズだ。
仕様書を更新し、テストケースを追加するだけで、AIが適切な実装変更を加えてくれる。
混乱を避けるために慎重でなければならないが、変更すると決めれば問題はない。
つまり、小さく始め大きくしていける。
小さな形でも価値を発揮できるサービスが良い。
テスト駆動開発の価値
テスト駆動開発（TDD）の重要性を初めて実感した。こんなにテストを重視して開発したことはなかった。
AI開発では、テストコードが「仕様書の実装」という位置づけになる。テストケースが明確であればあるほど、AIの実装精度が向上する。
そしてデバッグは、コードに対して行うものではなく、テストコードに対して行うものになる。
リスク：
しかし、テストにミスると被害が生じるかもしれない。
起こしてはいけない事態を想定できることも、重要だ。
あるいは、起きた時に個人で受け止められるものにすることだ。
品質保証の新しい形
セキュリティや品質保証も、テストの品質とカバレッジによって担保できる。
AIは、テストケースに基づいて実装を行うため、テストの網羅性がそのまま品質の指標となる。
そしてテストコードはリリース成果物ではないので、検品し放題だ。
（大規模アプリケーションでパイプライン遅延を起こさない工夫は必要かもしれないが）
リスク：
一方、サービスを運用に乗せると、サービス品質の維持を考える必要がある。
運用環境は、VercelやHerokuなどのプラットフォームを使うことになるだろう。スケール時のコストは計算しておく方がよい。
持続性を考え、優位性のある場所で
マネタイズやサービス提供価値も重要だが、まずは参入者に対する優位性のある場所で、誰よりもうまくやれる必要がある。
考えすぎてもいけないが、ソロ開発の問題は、個人のモチベーションに100%左右されることだ。
利用する人も、メンテナンスされないサービスに依存したくない。
価値が認められ、より規模が大きくなったときは、サービスの意思を誰かに引き継ぐことはできるだろう。それまでの間を考える必要がある。
エージェントを作るか？いや、、
汎用的なAIエージェントを作るモチベーションはない。
もっと自分が欲しい、身近に使いたい欲求を感じられるものをやろう。
これまでは開発負荷、運用負荷を考え、実現できなかったものたち。
お金払って使う人がいるが、多くの人がいるわけではない場所。
自動化ではないもの
AIが自動化を推し進めていき、自動化産業が増えていくと、
その先にはエンタメや人のつながりも重要になるように思う。
効率性の追求ではない、非効率でムダそうな分野も候補になる。
お金を払うもの
小さくても良いので、開発を維持し、成長を続けられるものにしたい。
コスト増加の負担を吸収する、DBの保存領域やトランザクション処理に耐えられる程度の金額は回収したい。
実利的かどうかは問わず、広告モデルに依存しないもの。
1つは明確に浮かんでいるが、合計5つほど手がけてみたいので、作りながら考えてみようと思う。
この記事は、原案を元にCursor/Claude-3.7-sonnetで書いています。
Discussion