アウトライン

対象

以下のように考えている方向けです。

Roo Cline を試しつつ、コスト上限が決まっている Cursor $20をメインにしたかった
中身は Claude 3.5 Sonnet なら同じはず

結論

Claude 3.5 Sonnet + Cursor Composer なら大丈夫。

やったこと

前回「[AI個人開発] Cursorで自動化レバレッジを最大化するためにしたこと10」の続編。

「自動実行のstateを管理する」ことで、かなり改善しているという話。

成果物

ほぼ、自動化。
ブランチ戦略も採用されて、ポケポケをスマホでやりながら、開発を眺めている状態になりました。

ブランチ

ブランチ名も、コメントも、マージも、コンフリクト解消も、全てやってくれるなんて。

統合したQA（受け入れ）

行わせたこと

古いコードで、モデルのバリデーションなども十分ではないコード群があります。
これらを整理したいのですが、動いている状態を壊したく無いので、手入れを躊躇していました。
（よくあるレガシーコードですね・・・）

そこで、Rails の app/ 配下へ手を入れることを一切禁止しつつ、テストの追加とカバレッジの拡大を命じました。

前回記事に記載した通り、まずは要件や課題の定義からスタートしていくのですが、プロジェクトでやりたいこと（既存のコード群のほにゃらら辺りにテストコードを追加したい。など。）からブレークダウンしてもらいつつ、以下のように指示を出すだけで生成してくれます。

まずは仕様を整理してもらう。

モデルは models/*/*.rb に存在するため、仕様を読み解いて。

などです。それらをまとめたあと、プロジェクトを作成して、さらにプロジェクトから

@a************.md @b************.md Projectを実現するために、@b************.md の全てのステップに従い、iessue作成完了まで全てCursor自身が実行して。

といった流れでIssue化していき、さらにタスクをブレークダウンして・・という感じです。いつもの仕事の進め方ですね。

いや、ほんとに自分よりも上手なので、もう戻れません。

問題勃発

少し前に Cursor が claude を使えていないっぽい状態になりました。
そこから突然、自動実行してくれなくなりました。

You can now proceed with creating the GitHub issue using this markdown file. If you need further assistance with this or any other step, feel free to let me know!

いや、、あなたがやってよ。

と突っ込みますがダメですね。

その時は諦めて、この週末に取り組むことにしました。

結局は Calude-3.5-Sonnet

まず、Calude-3.5-Sonnet以外を試していたのをやめて、Modelを絞り込みます。
Slowですが、自動実行の便利さには変えられません。

とたんに、全てがうまくいき始めました！

おそらく

単純に Calude 3.5 Sonnet がよいという話が１つ
さらに、md への記載、指示、実行が、Model一致している方が良さそう
- 作ったモデルと解釈するモデルの違いを考慮していないため、指示を短くしたりしてる点も影響していそう

モデルを選べる良さはあると思いますし、オーケストレーションしていくなかで必須のことだと思います。
ただ、現時点ではモデル差をClineやCursorが吸収してくれるようになるまで待つのが良さそうかな・・・と思います。

前回からの進展

2つありました。

タスク管理は必要
ブランチ戦略は細かく練る必要がある

タスク管理は必要

タスク管理は、次元数を増やす方向が良さそうです。
一旦やってみていましたが、ほぼ確定です。段違いです。

ただ、PRやマージを細く行なってもらうためには、プロダクト全体を管理するGitHubのProjectやRepositoryのブランチ戦略と同じルールでは、大きすぎる気がします。
AI専用のルールが必要だと感じます。

いま私はGitHubとローカルを繋ぎ合わせて行なっています。Issueに混ぜられないものを仕方なくローカルに置いているわけですが、本来はリモートにも持たせたいところです。
（いずれAI専用のタスク管理機能が、GitHubなどに追加されても良い気がします。localだけだと並列処理ができない。）

ブランチ戦略は細かく練る必要がある

AIが作業した結果をブランチに切っていくなかで、以下の課題が生じました。

コードベースに大きな変更を加えるものは、PR止まりにして自分がマージしたい
AIが自分で完結できる小さなコミット群や、アプリケーションに影響を与えないタスクはマージして欲しい

この差をつけるためには、ブランチ戦略を細かくする必要があります。
何も対処しないと、1つのブランチで持っている改修規模が大きくなったり、細かすぎて依存関係が分からなくなったりします。

そこで、私の場合は

AIに渡すmainブランチ（AIがmainと同等に扱うブランチ）は develop で固定
- main マージは自分でやるが、developが正しければ問題にならない
- 自分が手を入れたい時にちょっと困るので、先々は aidevelop ブランチを作るかも
AIの作業分割にブランチを合わせる
- Issue単位、task 単位など、粒度に合わせた戦略にする
- feature, fix などの prefix は目的名であり、タスク粒度では無い

この2つを取り入れいました。

結果的に、進捗と作業場所の2つを管理することとなり、次元数が2つ増えました。
今後は、仕様のまとめを取り入れるなど、いくつか次元数を増やす取り組みもしていこうと思います。

まとめ

前回行った「[AI個人開発] Cursorで自動化レバレッジを最大化するためにしたこと10」は、引き続き有効性を維持しています。

なかでも、タスク管理とブランチを分ける方法を工夫することによって、格段に自動化レベルが高まりました。
さらにコーディングが得意と言われる Claude-3.5-Sonnet であれば、ほぼ自由になれます。これは $20 Cursor Composer でも実現できるのでお得です。