■ 1. 人間の役割の定義
- モデル性能の評価:
- 無茶振りをしてどこまでできるかを観察する
- 何ができて何ができなかったかがドメイン知識になる
- ループの構築:
- 自動化で得た時間を評価指標の改善に充てる
- 評価指標の作成:
- どの数値を改善すべきかを決める
- トレードオフでは何を優先すべきかを決める
- ループのイテレーションの評価:
- AI の行動ログを観察し、評価指標を正しく追えているかを確認する
- テストとCIのチューニング:
- 評価指標が増えるほど、そのためのCIは長くなる
- 何を優先し、何をやらないかを明確にして優先度を与える
■ 2. 考える順番
- AIに任せられる仕事か:
- 任せられない場合は、そのブロッカーを特定する
- 完了の定義と評価指標:
- 数値化できるものならAIで自動化できる
- 一度やらせてみる:
- まずAIに指示して実行させ、その振る舞いを観察する
- できたときの判断:
- そのワークフローを自動化できるかを検討する
- 人間がつきっきりにならず、判断基準自体を作れるかが鍵
- できなかったときの理由の切り分け:
- コンテキスト不足なら、指示や守るべきテストを追加する
- 権限不足なら、それを与えられるかを検討する
- 性能不足なら、半年ほど待つ
■ 3. 常にアンラーニングする
- プロンプトの陳腐化:
- プロンプトは高速に陳腐化する
- 「あなたは優秀なプログラマです」といった指示はもう古い
- 深呼吸を促す指示で数学の性能が7ポイント改善した例も、すでに古い
- グローバルプロンプトの役割:
- 選択肢が複数あるときの判断基準を書く
- 例: node は 24+ を使う
- 例: 既存プロジェクトの設計は尊重しつつ、新規では npm ではなく pnpm を使う
- 例: nix を使うか使わないか
- 例: Rust は stable の 1.99 を使う
- 例: gh stack を使う
- Agents.md のグローバルプロンプト:
- 基本的には書かない
- モデルの知識の鮮度:
- 最新モデルに組み込まれている知識は半年ほど古い
- skill の寿命:
- skill はおそらく重点的に学習されているため、不要になる速度が速い
■ 4. 世界知識と /compact
- 世界知識の扱い:
- 世界知識はモデルに埋め込まれた情報で、コンテキストウィンドウに与えた情報はそれより優先される
- モデルにとって既知の情報が多くなるようにすると、結果的に高効率で動く
- よく知られたOSSで構築するのがその具体策
- /compact の注意点:
- 現在のコンテキストから重要な情報だけを残して圧縮する機能
- 判断基準が正しく与えられていないと、間違っている側に倒れる
■ 5. 既存リポジトリへの適用
- 最初の一手:
- 現状の構成を読み取って解説させる
- 速習しつつ、自分の理解とズレていないかを確認する
- そのためのツールとして mizchi/explainer がある
- Agents.md に書くもの:
- 一般的ではないこだわりや制約を書く
■ 6. ループの基礎概念
- 原始的な Ralph Loop:
claude -pを while で回すだけの無限ループ- Git 履歴を見て次にやることを決めさせる
- /goal:
- セッションが終了するたびに、hook で同じ指示（例: Issues を全部潰して）が再送される
- goal を満たすまでエージェントが自律的にループする
- 実験的手法としての dspy/RLM:
- ある程度ワークフローが決まっているものが対象
- 巨大コンテキストを、インタプリタで実行されるコード断片に分解する
■ 7. マルチエージェント（実験的）
- 現状の位置づけ:
- 現在、決定的な解がない
- 難しいなら無理して使わなくてよい
- 使い方の例:
- 今あるタスクを干渉の少ないレーンに分割し、レーンごとにサブエージェントを割り当てさせる
■ 8. 探索的改善
- 丸投げの有効性:
- エージェントを信用してある程度丸投げする
- 現状でもかなり賢いため、これでもだいぶ網羅できる
- 指示の例:
- 現在の実装と最新の研究を比較し、参考になるものを列挙させる
- SRE視点でテレメトリを計装させる
- テストを壊さない範囲でリファクタリングさせる
- データベースに対するN+1を見つけて潰させる
- 攻撃側視点でチェックリストを作り、localhostに閉じてペネトレーションさせる
- 視点の重要性:
- 誰にとって何の数値が大事かが、どう改善するかの理由になる
- 安全な実行環境:
- 自信がないときは Docker や適切なサンドボックスで実行する
- Umbrella Issue による集約:
- 見つかったものを GitHub 上の一つの Issue にまとめさせる
- それを /goal に渡せば、上から順に処理していく
- レビューの分担:
- 自分の専門範囲は自分で精査し、専門外の範囲はレビューを依頼する
- そのために、メンテナーの人格や好みを調べて追従するスキル maintainer-persona を作った
■ 9. /goal と併用する評価指標
- パフォーマンスベンチマーク:
- CI では安定しないため、RSS や Fuel など決定的な指標を優先する
- メモリ使用率:
- RSS を指標とし、hyperfine、perf、valgrind などで測る
- 厳しいルールの lint warning 数
- 循環複雑度:
- moznion/cccc で計測する
- コード重複率:
- mizchi/similarity で計測する
- Mutation Test の Kill 率
- VRT の一致率
- 数値化の必要性:
- 具体的な数値に落とせる指標が望ましい
- 主観的な判断が必要だと、ユーザーが都度呼び出される
■ 10. コードの理解
- 把握すべき対象:
- 最低限、振る舞いを把握する
- 具体的にはE2Eのケース名、テストコード、関数シグネチャ
- 具体のコードをすべて読むのはとても間に合わない
- AIによる概念的な解説:
- eli5 や mizchi/explainer などのスキルで、AIに自分へコードを説明させる
- explainer で作った説明画像を gh の --attach で添付してPRを作らせる
■ 11. マージの自動化（実験的）
- OpenAI の事例:
- AIがトリアージし、ある程度マージを自動化しているらしい
- 安全なコードはAIがそのままマージする
- DBスキーマ変更や terraform 変更など危険なコードは人間にエスカレートする
- 自前の取り組み:
- 現在、これを行うレビューツールを作っている
■ 12. 形式手法
- 仕様自体の検査:
- 実装しようとしている仕様が正しいかを、依存型や時相論理などの強い型で検査する
- 実現できないもの、存在しようがないものを作ろうとしていないかを確認する
- 最適化に使うアルゴリズムが正しいかを確認する
- 自然言語との関係:
- 自然言語がそのまま形式仕様に落とせるわけではない
- 性質を記述するイメージになる
- 漏れが出やすい領域:
- 経験的に、マイクロサービスとマルチスレッドのキャッシュ制御はほぼ確実に漏れがある
- これらには TLA+ か Quint を使うよう指示する
- ツールの使い分け:
- 述語論理で書ける制約には Z3 を使う
- 困ったら Z3 か TLA+ を使っておくとよい
- Lean はアルゴリズム自体の開発に使う
- ユーザー権限まわりには Alloy を使う
■ 13. 形式仕様の実例
- 指示の例:
- 既存コードのうち形式化できる部分を形式化し、それをテストオラクルとして実装が従っているかを確認させる
- モデル検査で反例が出たら、それを実際のテストケースに落とさせる
- 何を検査したかを、ドメインの言葉を使わずに例え話で説明させる
- 使用している仕様化スキル:
- mizchi/skills の formal-methods-reconciler
■ 14. 結び
- ここに書いた内容も、またすぐに変わる