法則一覧
コラム
AI がコードを書くとき
AI のおかげで、コードを書くのは安くなった。このコラムは、それがチームに何を起こしうるかを順に読む。コードが増え、確かめきれなくなり、理解が追いつかなくなりうる。最後に、任せる範囲を広げたときの代償をたどる。
AI がまず変えるのは、コード一行の値段だ。値段が下がったとき書かれる量がどうなるかは、古くからある問いだ。
ジェヴォンズのパラドックス
資源を安く使えるようにすると、かえって総使用量が増えることがある。心得：安くすれば、使われる量は増えると見込むコードが増えても、後ろの工程が追いつかなければ届く量は増えない。仕事は次に詰まる工程、たとえばレビューに溜まる。
制約理論
システムの処理量は、最も詰まっている一か所で決まる。心得：改善はボトルネックに集める。ほかはそれを待っているだけだ制約理論は、まずボトルネックを使い切れと言う。レビューの場合、いちばん安い手は書く側が何を送るかだ。
小さな変更
レビューに出す変更が大きいほど、一行ずつは丁寧に読まれなくなる。欠陥はすり抜け、最初に見てもらうまでの待ちも長くなる。心得：一度に読み切れる大きさで変更を出す変更を分ければ一つずつは読みやすくなるが、数は減らない。どれも、このコードは動くという主張だ。その主張は、確かめるよりずっと安く出せるようになりうる。
ブランドリーニの法則
誤った主張を論破するには、それを言うよりはるかに手間がかかる。だから安い主張が大量に来ると、確かめる側の手が回らなくなりうる。心得：反論に手間をかける前に、まず主張に証拠を出させる減らないキューと、作るより確かめるほうが高くつく変更を前にしたレビュアーには、手近な近道がある。ツールの答えをそのまま通すことだ。
自動化バイアス
自動化された補助を使う人は、自分で確かめる代わりにそれを頼りがちだ。補助が指摘しないものを見落とし、補助が間違っていてもそれに従う。心得：ツールに従ったかではなく、結果に責任を持つ自然な手は、確認をテストに任せ、そのテストもツールに書かせることだ。元になるのは、ツールがいま生成したそのコードだ。
テストオラクル問題
テストが誤った答えを捕まえられるのは、コードとは別に正しい答えを知っているものがあるときだけだ。そして多くのプログラムには、それがない。心得：通ったテストは、何と照合したかを問うそれでもすり抜けたものは、誰かがデバッグすることになる。その人はそのコードを書いておらず、隅々まで追えているとも限らない。
カーニハンの法則
デバッグは書くより難しい。だから、最大限に凝って書いたコードは自分でもデバッグできない。心得：疲れた他人でもデバッグできるコードを書くコードがなぜそうなっているかを誰も言えないとき、デバッグはいちばん難しくなる。生成されたコードは、最初からそうなりうる。
プログラミングは理論の構築である
プログラムの設計は作った人たちの頭の中にあり、コードや文書が運べるのはその一部だけだ。だから作った人たちがいなくなると、文書がそろっていても、変更を重ねるうちに設計が崩れやすい。心得：理由を言える人がいるうちが、保守できるコードだ前の法則の処方は、コードがなぜこの形なのかを言える人を置くことだ。そういう人は手を動かすことで育つ。そして手を動かす部分こそ、いま任せている部分だ。
自動化の皮肉
自動化は人に最も難しい例外だけを残し、その対応に要る腕は使わないうちに鈍る。心得：自動化するほど、手で扱う練習が要る任せる範囲が広がると、たいていエージェントに渡す権限も増える。権限の組み合わせによっては、書くコードが正しくても危ない。
致命的な三点セット
非公開データを読めて、外から来た内容を取り込み、外へデータを送れる AI エージェントは、その内容を書いた誰にでも操られてデータを漏らしうる。心得：エージェントが読む文章は、書いた人からの指示だと思う
