ブログなので雑にバラバラと書く
- 手がとにかく早い
- まあ機械なのでそれはそう
- 意味のあるフィードバックをClaude Code自身が得られるような工夫が必要
- 「生成」AIなので生成することは向いているけど、チェックすることには向いていない。あたりまえだけどテスト書いてなかったりしたら人間の何倍も早くぶっ壊していくと思う
- テストもとにかくサボる
- テスト書けって言っても書かない。必ず実行しろっていってもサボる
- カバレッジ目標とかを明示的に与えたほうがいいのかもしれない（試してみる）
- 外部API叩いてるところとか、そういうものはClaudeCodeが直接FBを確認しにくい。こういうときは当てずっぽうでやらせるのではなくて「人間が手伝うから、なにかを確認してほしくなったら確認手順を人間に教えて」と言ってFBループに人間が介在するとうまくいく。うまくいきはするんだけど、人間が介在するのでスピードがガタ落ちする
- ここはけっこう「労働からの阻害」を感じるポイント。「なにをやるか」を自分が決められる個人開発なら「自分が決めてAIにやらせる」が成立して、「個人でできることの範囲が広がりうれしい」という感じがするんだけど、労働の文脈で「やることはチームや "えらいひと" が決める」となっている場合、AIが苦手な「人力でフィードバックを収集するパーツ」としての労働だけが残る、ということになりかねない。あんまりわくわくする未来ではない。
- ちょっと複雑なバグを直すのはかなり苦手
- このへん、LLMの「統計的正論パンチ繰り出しマシーン」の感じがよく出ている。「よくあるバグ」はすぐ直せるけど、ちょっとふくざつで折り入ったバグだと「当てずっぽう」ループが始まる。
- 「当てずっぽう」ループにハマりこむとtokenをモリモリ消費するくせに成果がでない最悪の大飯食らいが爆誕する
- こういうときは人間がちゃんとコードを読んだりするのも大事
- さっきの、FBをClaudeCode自身が確認できるように、というのと同じ話で、ログをバンバン仕込ませてやると進捗したりする。
- そのへんを考えると、最初のうちにログレベルをちゃんと変えられる仕組みを構築したうえで、デバッグログをばんばん仕込みなさいって指示しておいたほうがいいかもって思った
- けっこうおべっかを使ってくるので、既存コードを分析してもらうときとかはあえて批判的にみてもらうといい
- これChatGPTとかGeminiとかもかなりおべっかを使ってくるよね〜。
- 真にうけていい気分になってると、破滅したコードベースが生成されていく。定期的に「このプロジェクトを批判的に深く考えて分析して」などでdeep thinkで批判的に分析させるといい。
- そうすると「たしかにそこ修正しといたほうがいいな」ということが見つかるので、コード品質を高く保ちやすい
- 批判的分析を加えることとそれに対して修正プランを作る部分ではかなり筋がいいので、ここはうまくやると自動化できる気がしている
- 書かれたコードで内部的になにが起こっているのかへの理解は必須
- この理解がないと、「当てずっぽう」になりはじめたときに詰む
