月曜の朝、PR が7本たまっています。
1本目は丁寧に読みました。2本目も読みました。3本目で、テストが通っていることを確かめて、diff を上から下まで流し見ました。
5本目のころには、ファイル名と行数だけを見て approve を押していました。
読んだことにはなっていません。
2つの規則
2026年2月6日に、StrongDM の AI チームが文書を出しました。アクセス管理と安全性の製品を作っている会社です。
規則は2つだけです。
コードを人が書いてはならない
コードを人がレビューしてはならない書かないだけなら、よく聞く話です。読まない、と明記しているところが違います。
では人は何をするのか
手放していないものが3つあります。
仕様を決めること。テストの筋書きを用意すること。そして点数を見ること。
何を作るかと、できたかどうかの判定は人が握っています。手放したのは、途中の作り方と、その検査です。
ここを読み落とすと「全部 AI に任せた」という話になりますが、そうではありません。入口と出口は人が持っていて、間を渡しただけです。
検査が判定になります
コードを読まないなら、できたかどうかは別のもので判定することになります。それがテストの筋書きです。
人が読む場合、テストが薄くても「まあ大丈夫そう」で通ります。読まないと決めると、その逃げ道が無くなります。テストが通ったかどうかが、そのまま唯一の判定になります。
レビューを手放すには、先にテストを厚くする必要があります。順番が逆になると、ただ見ていないだけの状態になります。
ここが、この話のいちばん実務的な部分だと思います。
費用の目安
同社の技術責任者が、1つ目安を出しています。技術者1人あたり1日1,000ドルぶんのトークンを使っていないなら、改善の余地がある、というものです。
数字そのものは規模によります。読み取れるのは、人の時間を機械の費用に置き換える、という方向がはっきりしていることです。
呼び名
この形は「ソフトウェアファクトリー」や「ダークファクトリー」と呼ばれています。
後者は、人のいない工場から来ています。明かりを点ける必要がないので暗いまま動く、という意味です。AI を使った開発を段階で分けた一覧の、最上段に置かれることがあります。
名前が強いので一人歩きしやすいのですが、上に書いたとおり人は残っています。工場の喩えで言えば、何を作るかを決める人と、出荷の検査をする人は残っていて、ラインから人が消えた、という形です。
全部やらなくてもよい
2つの規則を丸ごと採るかどうかは別として、分けて考えられます。
書かないことは、多くの現場で既に起きています。読まないことは、テストの厚みと相談になります。
一部だけ採る、という選択もあります。性質の軽い部分では読まない、重い部分では読む。境界をどこに引くかを決めれば、読む量は減らせます。
境界を決めずに量だけ増やすと、なしくずしで読まなくなります。それがいちばん悪い状態です。
並べるときに効くこと
並列で動かしていると、どれがどこまで進んだかを見る必要があります。コードを読まない方針であっても、終わったかどうかと、人を待っているかどうかは知る必要があります。
npx mulmoterminal@latestMulmoTerminal は枠ごとに色で状態を出します。読む対象を減らしても、見る対象はむしろ増えます。 5つ並べれば5つの状態を追うことになります。
まとめ
StrongDM の2つの規則は極端ですが、何を手放して何を手放していないかを分けると読めます。手放したのは書くことと読むこと、残したのは仕様と検査です。
レビューを手放すなら、先に検査を厚くする。順番を逆にすると、ただ見ていないだけになります。
- Simon Willison による紹介
- MulmoTerminal —
npx mulmoterminal@latest