Cursor Composer メインでも、Claude 3.5 SonnetならAI開発自動化が進む

# アウトライン

## 対象
以下のように考えている方向けです。
- Roo Cline を試しつつ、コスト上限が決まっている Cursor $20をメインにしたかった
- 中身は Claude 3.5 Sonnet なら同じはず

## 結論
- Claude 3.5 Sonnet + Cursor Composer なら大丈夫。

## やったこと
前回「[[AI個人開発] Cursorで自動化レバレッジを最大化するためにしたこと10](https://qiita.com/tettuan/items/3d27c01ed7cc414db8f2)」の続編。

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

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

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

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141741/4f453b08-c2b2-eff0-d327-8942f5e65f6b.png" width="200">

## 統合したQA（受け入れ）
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141741/cf938fe2-e930-b906-b16d-efaa94936322.png" width="50%">

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

そこで、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ですが、自動実行の便利さには変えられません。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/141741/86b23021-8fa5-b60b-a286-c202b7415fb5.png" width=300>

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

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

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


# 前回からの進展
2つありました。

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

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

ただ、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](https://qiita.com/tettuan/items/3d27c01ed7cc414db8f2)」は、引き続き有効性を維持しています。

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