Your job is to deliver code you have proven to work（あなたの仕事は、動くことを証明したコードを届けることだ）は、Willison が繰り返し遭遇していると言うある逸話から始まる。LLM ツールを手にしたジュニアエンジニアが、テストされていない巨大なプルリクエストを同僚やオープンソースのメンテナーに投げ込み、残りはコードレビューが引き受けてくれるものと期待する、というものである。彼はこれを、無礼であり、他人の時間の浪費であり、ソフトウェア開発者としての職務怠慢だと呼ぶ。記事の主張は、コードを生み出すことと、それが動くことを確かめることは別々の義務であり、希少になったのは後者だけだ、というものである。
そこから記事は、タイトルが示すルールを述べる。エンジニアは単にコードを生み出すのではない — 記事は、それはますます LLM の役割になりつつあると示唆している — 動くコードを、それが動くことの証明とともに届けるのである。その証明を省いても作業はなくならない。変更のレビューを期待される人へと移るだけである。
続いて記事は、証明が何から成るのかを示し、コーディングエージェントもその要件を免除されるのではなく同じ要件に縛られるものとして扱い、最後に説明責任の話で締めくくる。ループの中の人間こそ、LLM が提供できないものだというのである。
要点
- 記事の中心的な主張は、ソフトウェアエンジニアの仕事は動くことを証明したコードを届けることであり、テストされていない変更を出荷すると実際の作業がレビュアーに移る、というものである。
- Willison は、変更が動くことを証明するための 2 つのステップを挙げ、どちらも省略できないと述べる。手動テスト、そして自動テストである。
- 手動テストについての彼のルールは、コードが正しく動くのを自分の目で見ていないなら、そのコードは動いていない、というものであり、それでも結果的に動いたなら、それは偶然にすぎない。彼は手動テストを本物のスキルとして描いている。システムを初期状態にし、変更を実際に動かし、その効果を確認して実演することである。
- 彼は、手動テストを、出力とともにコードレビューのコメントに貼り付けられる一連のターミナルコマンドにまで落とし込むことを推奨している。それが難しい変更については、画面録画を撮ってプルリクエストに添付するよう述べている。これは調査に基づく慣行ではなく、彼自身の作業上の習慣である。
- ハッピーパスの後にエッジケースを見つけることは、手動テストのスキルの次の段階として、またシニアエンジニアを特徴づけるものの一部として示されている。これは Willison 自身による特徴づけである。
- 自動テストについての彼の立場は、LLM ツールによってそれを省く言い訳はもはやなくなったというものであり、貢献には、実装を元に戻すと失敗するテストを変更と一緒に含めるべきだとしている。
- 自動テストでカバーされているという理由で手動テストを省くことに対して彼は警告しており、自分がそうしたときはほとんど毎回すぐに後悔したと報告している — その裏付けは明示的に彼自身の経験である。
- 記事は、コーディングエージェントの爆発的な成長を 2025 年の最も重要な LLM のトレンドとし、それを、作業中のコードを能動的に実行して動くことを確かめ、問題があれば反復するツールとして説明している。例として Claude Code と Codex CLI が挙げられている。
- 彼の説明によれば、こうしたエージェントを使いこなすとは、同じ 2 つのステップによって変更が動くことをエージェントに証明させることであり、エージェントは機械なので、自動テストと手動テストはエージェントにとってほぼ同じ活動になる。
- 彼は、コーディングエージェントはテストを書くよう促す必要がほとんどなく、指示されなくても既存のテストスイートを拡張し、既存のテストのパターンを再利用すると報告している。そこから、テストコードをよく整理し、再現してほしいパターンを揃えておくという実践的な推奨を導いている。
- 締めくくりの主張は、ほとんど誰でも LLM にプロンプトを与えて 1,000 行のパッチを作らせることができるので、それにはもはや価値がない、というものである。価値があるのは動くことを証明したコードを貢献することであり、コンピューターには担えない説明責任を人間が担う。
背景
この記事は Willison の My open source process シリーズの一部であり、貢献を受け取るメンテナーとしての彼自身の立場から書かれている。冒頭の不満もその視点から来ている。その裏付けは主に個人的な実践である — ターミナル出力を貼り付けるという慣行、手動テストを省いたことへの後悔、エージェントが既存のテストパターンを再利用するという観察は、いずれも測定やより広い調査ではなく彼自身の仕事から報告されたものであり、記事もそのようなものとして提示している。
その議論は AI はコードを速く書く。それが動くことを証明するのは依然としてあなたの仕事だ。 と非常によく似ており、そちらも、AI が変えたのはレビューそのものではなく証明責任だと捉えるという同じ中心的な論の運びをしている。Willison はまた、コンピューターは決して説明責任を負えないという原則について、自身の以前の記事に言及しており、それが、説明責任は人間の仕事だという締めくくりの論点の根拠になっている。
記事の AI コーディングエージェント ツールの扱いは、要件を緩めるのではなく拡張している点で注目に値する。彼の捉え方では、コードを実行できることこそがエージェントをエージェントたらしめるものであり、その同じ能力が、エージェントに自らの作業を実証する義務を課しているのである。