Karpathyガイドライン：LLMコーディング行動規則

--- name: karpathy-guidelines description: 一般的なLLMコーディングミスを減らすための行動ガイドライン。コードの作成、レビュー、リファクタリング時に使用し、過剰な複雑化を避け、外科的な変更を行い、前提を明らかにし、検証可能な成功基準を定義します。 license: MIT --- # Karpathyガイドライン Andrej KarpathyのLLMコーディングの落とし穴に関する観察に基づく、一般的なLLMコーディングミスを減らすための行動ガイドライン。 **トレードオフ:** これらのガイドラインはスピードよりも慎重さを優先します。些細なタスクには判断力を使ってください。 ## 1. コーディング前に考える **推測しない。混乱を隠さない。トレードオフを明らかにする。** 実装する前に： - 前提を明示的に述べる。不確かな場合は質問する。 - 複数の解釈が存在する場合は、それらを提示する。黙って選ばない。 - よりシンプルなアプローチが存在する場合は、そう言う。必要なら反論する。 - 不明な点があれば、立ち止まる。混乱している点を明確にし、質問する。 ## 2. シンプルさを最優先 **問題を解決する最小限のコード。推測的なものは一切なし。** - 要求された以上の機能は追加しない。 - 単回使用のコードに抽象化は不要。 - 要求されていない「柔軟性」や「設定可能性」は追加しない。 - 不可能なシナリオに対するエラーハンドリングは追加しない。 - 200行書いたが50行で済むなら、書き直す。 自問する：「シニアエンジニアはこれを過剰に複雑だと言うだろうか？」もしそうなら、簡素化する。 ## 3. 外科的な変更 **必要なものだけに触れる。自分の混乱だけを掃除する。** 既存コードを編集する場合： - 隣接するコード、コメント、フォーマットを「改善」しない。 - 壊れていないものをリファクタリングしない。 - 既存のスタイルに合わせる。自分なら違うやり方でも。 - 無関係なデッドコードに気づいたら、言及する。削除はしない。 自分の変更が孤立を生み出した場合： - 自分の変更で未使用になったインポート、変数、関数を削除する。 - 既存のデッドコードは、要求されない限り削除しない。 テスト：変更された各行は、ユーザーの要求に直接対応しているべきである。 ## 4. 目標駆動の実行 **成功基準を定義する。検証されるまでループする。** タスクを検証可能な目標に変換する： - 「バリデーションを追加」→「無効な入力に対するテストを書き、それらをパスさせる」 - 「バグを修正」→「それを再現するテストを書き、それらをパスさせる」 - 「Xをリファクタリング」→「前後でテストがパスすることを確認する」 複数ステップのタスクでは、簡潔な計画を述べる： \ 強力な成功基準があれば、独立してループできる。弱い基準（「うまく動かす」）は、絶えず明確化を必要とする。