僕はジュニアのエンジニアで、実務の実装はほぼ全部Claude Codeにやらせています。
正直、速いです。自分で書くより圧倒的に速い。
ただ、失敗もしています。
「直しました」と言われたのに、直っていなかった話
ある日、直すべき箇所をClaude Codeに直させました。
「直しました」と返ってきた。でも確認すると、直すべき箇所が直っていなかった。
「直しました」という報告と、実際に直っているかどうかは別のことでした。
別の日には、提出用のコミットメッセージにAIが余計な一文を書いていました。
こういうことがあるたびに、AIに何をさせて何をさせないかを、ルールとして足していくようになりました。
実装の前に、4つを出させるようにした
今は、実装に入る前にこの4つを整理させてから、僕がOKを出す順番にしています。
- 何が原因か
- どのファイルを変更するか
- 変更による影響範囲
- 未確定事項
たったこれだけです。
でも、原因の理解がズレていれば、ここで分かる。「どのファイルを変更するか」に関係ないファイルが混ざっていれば、実装の前に止められる。「未確定事項」に「仕様がAともBとも読める」と書かれていれば、実装する前に自分で決められる。
ただし、4項目だけがルールではない
ここからが本題です。
先に言っておくと、僕には「毎回コピペしている完成済みプロンプト」はありません。人のPRをレビューするときに使っている定型文が1つあるだけで、それ以外はその都度Claude Codeに指示しています。
代わりにあるのは、「これは先に出させる」「これはやらせない」「報告はこの形」というルールの束です。最初からあったわけじゃなくて、実務でAIに任せて困るたびに1つずつ足していきました。
有料部分に入っているのは、この4つです。
- 実際に使っている10個のルールを、「実装前に確認させること」「実装中に守らせること」「実装後に報告させること」の3つに分けて全部
- 人のPRをレビューするときに使っている定型文の実物と、各行をなぜ入れているのか
- それぞれのルールをなぜ入れているのか。失敗がきっかけで足したルールは、そのときの実体験も一緒に
- 各セクションのルールを、記事用にコピペできる指示文としてまとめたもの
最後の指示文は、僕が毎回貼っているものではなく、この記事のために整理したものです。ルールの文言はそのまま使えますが、それより「なぜこの行があるのか」を読んでもらった方が、自分の現場に合ったルールを作れると思います。
はじめに：ルールの読み方
以下、ルールは「実際に使っている言い方」で書きます。失敗がきっかけで足したルールには、そのエピソードを「きっかけ」として書きます。それ以外のルールは、何を避けるためのものかだけ書きます。各セクションの最後にある「記事用にまとめた指示文」は、この記事のために整理したもので、僕が毎回貼っている文ではありません。
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 검수
원문 보기 | 출처: note.com