Claude Code 最近こう使ってる

いかに指示なしで最後までいけるかを目指す。 しかし現実世界ではそうは簡単にいかない。 そのためにLinterやテスト整備が必要になってくる。 だからLinterが必要になるケースを対話しながら残しておく。

基本的に「あるべきすがた」を宣言して、それに近づくように高速にリトライしていくような形するのがいいのはそう。Linterがあれば自走できる期間が伸びるので楽になる。

既存のアーキテクチャに則って拡張していく場合、実装したい機能のあるべき姿を抽象的に定義しすぎると、機能単位ではなく、レイヤー単位でものごとを書いてしまうことが多かった。

例えば、修正が複数の機能を含む場合、例えばモノレポ構成で

• schema
• api server
• frontend

のような構成を取っている場合、AIは

• 複数機能に必要なschema修正を全部実行し
• 上記の api を全部実装
• フロントエンドを全部実装する

のような手順でやろうとする。 ので、E2Eでの確認までが長い。

プロンプト・Linter・テストによるルールの制御が整ってない段階なので、できるだけ機能単位で細かくステップを分けさせるように指示している。

例えば

• 機能Aの schema修正、apiサーバー実装、フロントエンド実装
• 機能Bの 同上...

plan mode を使うのも良いが、結果は基本的に テキストファイル（markdown） に出力して、機能実装順序、実装計画をテキストファイルに吐き出すようにして管理するのが良さそう。

また、対話する中でAIに「違うよ、こうだよ」という指示を出した場合は、コンテキストを定期的にテキストに振り返ってナレッジとして残すようにすると良い。

最後の「振り返り」が非常に重要で、振り返りの結果から別途 Linter を生成するのが良さそう。まだできてない。（実装中に Linter も同時に生成しちゃってる人が多いのかもしれない？）

小さい機能ステップで開発していると手戻りもしやすいし、裏リリースのような形でのリリースもしやすい。

しばらくはこの形で進めてみる予定。

このきじはえーあいつかってかいてません。