コーディングエージェントをなるべく自走させないメモ書き
エージェントが自走することは悪くないが、最終的な判断は人間がするので、そこの認知負荷は減らすためにあえて自走させてない
スタンスL4Ph.icon
時間効率(手戻りを含めた、最終的なプロダクトへの最終的な時間)の最大化を目的とする
OpenCode Go / Cursor / Kimi Codeがメイン
最低限の品質を担保する
新規の場合
まず技術スタックを確定させる
web
TanStack Router(Start) + Solid or React + Vite Plus
ネイティブ
T4 stack or Swift or Flutter
GeminiのCanvasで捨てる前提のプロトタイプを起こす
エディタ上に移動させてgrillingすることで仕様を決める
基本的に厳密な仕様を作らない
なぜなら流動性のない仕様はプロダクトとして成立しないため
この段階から単体テストは絶対に書く
web or Rustの場合はinsource testingを使うことで、できる限りソースコードとテストを近づける
普段から意識すること
grilling + tdd + writing-great-skillsの3つだけを基本的に外部のスキルとして取り込む
基本的に型安全でない言語は使用しない
型安全でない = データモデルの肉付けとして信頼性がない
Swift Dart TypeScript Rustあたりだけを信頼する
アーキテクチャはすでに言語やフレームワークレベルである場合はそれに従う
SwiftならMVVM
Flutter / DartはMVVMだけど、使い勝手からRiverpodパターンも
TS(React)に関してはフレームワーク依存が強いのでそこに任せる
TanStack Startがメインなので、そこから大きく外れたアンチパターンだけはやらない
AGENTS.md / CLAUDE.mdには基本的にアプリケーションのことについては書かない
特にやってちゃいけないこと、こうして欲しいことなどは書かないこと
rulesへの導線としてしか使わない
Why? 初期化時のコンテキストがデカい、あまり頻繁に変更をかけるファイルではないため
tdd とgrillingを使っていれば、基本的にコミットが必要な仕様の粒度というのはエージェントが判断できる あとはそれらをラップしたskillsとrulesを持たせれば、必要な判断が可能なloopができる
issueについて
これを使い、全てのissueのコンテキストをリポジトリ内に閉じ込める 自分は最悪Code BargやGitLabへ移動することも考慮しているので、GitHubの機能は基本的に使わないようにしている
できる限り信頼できない外部ライブラリを使わない
基本的に全てのライブラリは自作する
Rustならcrate、tsならpackagesディレクトリに切ってドメインが入らない純粋なライブラリとして構築しておくことで、そこだけをメンテできるようにしている
Next.js / Vercelは特に信用してない
定期的にパフォーマンス用のベンチマークとチューニングを入れる
大体意図しないタイミングで意図しない場所でパフォーマンスの劣化が起きているため