Clineファーストインプレッション
kClineを試してみたのでそのファーストインプレッションメモ。
とりあえずJetbrains IDE使いなので、VS Codeの操作に慣れないのアレ。コラボレーションはもうちょっと慣れる必要がある感じで、今回はひたすら指示して何かやってもらう感じ。
kClineで作ったPRはこのあたり。
対象はPHP5.6〜8.3をサポートしたtestcontainers実装。
AI的にはPHPという情報量が多いが、EOLを迎えた現在のベストプラクティスではないコードを書く必要がある難しさがある。
また、testcontainers/dockerという一般的な概念を扱いつつ、一定の知識がないと適切なテストなどは書けないぐらいのドメイン知識が求められるものになる。
kルールを最小限にしつつ、直近のコンテキストは短期記憶としてメモリに保持、長期記憶はナレッジとして別に保存して適時呼び出す方針で組んでいる。
これは近似の関係ない情報をコンテキストとして持つとノイズによりタスクの精度が下がるので分けた形になる。
別の言い方をすると、ルールはどのタスクでも共通なものを、メモリにはタスクに必要な情報を、知識には次に実行するときに覚えておいて欲しいものを置いている形になる。
Custom Instruction
You must always read the .clinerules and follow these rules when performing tasks.
Rules
ルールとしてはシンプルな形になる
- 基本的に英語を使え、ただし会話は日本語でしよう（これ日本語使うと性能ガン下がりしてる感じあるので修正しそう）
- コーディングスタイルは既存に合わせろ、それ以外の詳細はナレッジを読め
- メモリとナレッジは適時更新しろ
Memory
気がついたら日本語汚染されてた。
メモリはLLMが扱うので特にコントロールはしていない。ある程度肥大化したり、新しいタスクをさせるタイミングでメモリを更新するタスクを走らせている形になる。
Knowledge
ナレッジはLLMが扱うので特にコントロールはしていない。基本は自動で更新されるが、メモリがある程度溜まったタイミングでメモリの内容から重要なものをナレッジに移すタスクとか実行している。
この構成は一見良さそうに見えるが、Clineの動作としてナレッジを全て読むわけではないので、ナレッジに貯めさせただろ？？？？みたいなケースはよくある。面倒臭い。
対策としてはナレッジを1つにまとめるのも有効だが、その場合はノイズの問題もあるのでこの辺は悩ましい。
もしかしたら重複することを前提にナレッジがもっと蓄積されれば解決する問題かも。
k
このタスクは比較的うまくいった。
ひたすらコードを読ませてドキュメントを更新するだけのお仕事。（ついでにナレッジの蓄積も）
一つやりにくかったのは1ファイルに情報を詰め込もうというあたり。
最終的に削ったりしたがgetteing-started.mdにAdvanced Configurationとしてダラダラ色々と書かれたり、container-configuration.mdの内容が一部入ってきてたりでその辺の除去が面倒臭かった。
初めに全体像を作れれば解決できたかもしれないけど、書きながら考える進め方だと回り道しまくる。
余談だけど最初にドキュメントのフォルダ構造出してというタスクやったけどセンスなかった。
k
この修正は結構良かった。
タスク指示
Tests\Unit\Containers\GenericContainer\PortSettingTest::testStaticPorts
Testcontainers\Docker\Exception\BindAddressAlreadyUseException: Failed to docker command: `'docker' 'run' '--detach' '--publish' '57603:80' '--publish' '50466:443' 'alpine:latest'`, exit code: `125`, stderr: `docker: Error response from daemon: driver failed programming external connectivity on endpoint distracted_sinoussi (9f006f12115121e9e94b997755c0d88d905cf24383868d403a7b04257d0b3bc1): Error starting userland proxy: listen tcp4 0.0.0.0:50466: bind: address already in use. というようにbind: address already in useのエラーが稀に発生します。このエラーが発生するときはPortStrategyに従ってリトライなどするように修正してください。
具体的な指示で問題特定可能、修正自体も容易な内容だったのか瞬殺で直してくれた。
逆に僕自身が修正内容を理解できず何でそれ修正するつもりなの？？？みたいなやりとりをしてしまって逆にボトルネックになってしまっていた。
修正自体は上手くいったがテストコードの生成は上手くやれなかった。
モックを使うかリフレクションを使うかというテストの書き方になり、何度それを使うなと言ってもそれを使う形になってしまい厄介な感じ。
実際ここのテストは難しく、bind: address already in useを発生する状況を作って、リトライしたら解消するのを作る必要があり、まぁ結構難しいよねと。ただ難しいからやって欲しいんだけども。
k
これは死ぬほど苦労した（現在進行系で苦労している）
テストカバレッジを取得し、不足している箇所に必要な振る舞いのテストを追加してください。
追加するテストでモックやリフレクションが必要になったらテスタブルでない証明です。対象のコードを適切にテスタブルな構成するか、ナレッジに基づいてモックの利用判断を行なってください。
こんな感じの指示でやっているけど、カバレッジ上げるために何でもやってくる感じで、それをやるなと言っていることをガンガンやってくる感じ。
犯行履歴としては下記
- LogicExceptionをキャッチするテストを書く
- モックを多用する
- リフレクションを多用する
- 対象を呼び出すだけでassertをしない（してない訳じゃないけどテストでassertしたいのと違うのをする）
とかとか。あと厄介なのがテストが上手く行かないと勝手にテストをスキップしたり、削除したり、テスト対象を変えるあたり。
この辺をどんなに注意したり、ナレッジ、記憶に入れてもテストが通せないとそういう振る舞いをしだす。
挙動的にはコンテキストから注意が外れている感じがあって、本当に外れているか、ロングコンテキスト内の優先度が下がる位置に入ったかなんかしてそうな雰囲気ある。
k個人的な感想としては、これまでAIの奴隷になって情報収集したり、コンテキスト調整してたのが、いい感じにインテグレーションされて回ってて楽でいいなという感じ。
感動という意味ではインテグレーションの繋ぎが上手くいけばこのぐらいは回ると思ってたので、そこまで感動はない。（あと周りが騒ぎすぎて期待値上がりすぎてたので、なんか「スンっ」ってしちゃった）
間違いなく楽になったのだけど、これまで手動でやっていて介入範囲が広く、細かい調整を効かせられなくなったので精度としては少し下がっている感じ。
でもかかってる時間は間違いなく短くなっているので、ここの体験的には圧倒的に良い感じ。
開発ツールとしては必須だなぁという感じで、MCPと組み合わせてある程度の情報を持ってきて、コンテキストを作るための装置としてplanを多用すると良さそうという印象でした。
actはちょっと悩ましくて良いplanを作れたら使う、ダメだったら早く諦めて自力で頑張るかな。
あとLLM特有の課題で、こちらの言うことを肯定しまくる、一度発言した内容の訂正が効きにくい、知識の誤用での齟齬とかはやっていて結構あったので、セッションはガンガン切り替えながらプロンプトやコンテキストを調整して期待した結果を生成するというのは依然として大事そう。
k1日遊んだ金額感はこんな感じ。
OSSプロジェクトでやってるのでペイできないので、どこかでOllamaで動かすように変えないと厳しめ。
今だとDeepSeek、MiniMax、Gemma3あたりがいいのかなー？
k今回は1→10、10→100で人間が扱うのに必要なラインを超えたコードを書いてもらう必要があり、LLMが扱うのに難しいPHPで、古いPHPバージョンで静的検査とかも活用しにくい中での検証なのでこんな感想になった。
TSあたりだと感想変わるかもというのと、いっそ人間はコードを読まない前提でゴリゴリ組ませてもいいかもとは思った。そのうちこの辺は検証したい。
あとルールで日本語扱えるようにしたけど日本語使うと性能ガン下がりしている感触あるので、会話面倒臭いけど全部英語にした方が評価としてはいいかも。
VSCodeの翻訳拡張探さなきゃ。