動作が実証されたコードを届けるのがあなたの仕事だ

• AI支援の開発環境で、経験の浅いエンジニアが検証されていない大規模なPRを提出する事例が増えている
• 開発者の中核的な任務は単なるコード記述ではなく、動作が実証されたコードを提供すること
• そのために、手動テストと自動テストの2段階を必ず実施しなければならない
• コーディングエージェントについても、自分が作成した変更を自ら検証するよう設定すべき
• 最終的に責任は人間の開発者にあり、検証の証拠を含むコードだけが本当の価値を持つ

---

検証されていないコード提出の問題

• LLMツールを活用するジュニアエンジニアが、巨大な未検証PRを提出してコードレビューに依存する事例が挙げられている
  • これは無礼で非効率的であり、開発者としての責任放棄だと指摘されている
• ソフトウェアエンジニアの役割は単なるコード生産ではなく、動作が実証されたコードの提供である
  • 検証されていないコードは、レビューアに負担を押し付ける行為と見なされる

コードが動作することを実証する2段階

• 第1段階は手動テストで、実際にコードが正しく動作することを自分で確認しなければならない
  • システムを初期状態に設定し、変更を適用した後、結果を検証するプロセスが必要
  • ターミナルコマンドと出力結果をコードレビューコメントに添付したり、画面録画で証明したりできる
  • 正常動作の確認後は、エッジケースのテストを通じて問題点を探るべき
• 第2段階は自動テストで、LLMツールの進歩によって必須の手順として強調されている
  • 変更内容とともに自動テストを含めるべきであり、実装を元に戻したらテストは失敗しなければならない
  • テスト作成は手動テストと同じ手順に従い、テストハーネス統合能力が重要になる
  • 自動テストだけで十分だと判断して手動テストを省略するのは、誤ったアプローチだと指摘されている

コーディングエージェントの役割と検証

• 2025年のLLM分野の主要な流れはコーディングエージェントの急成長で、Claude CodeやCodex CLIなどが代表例
  • これらはコードを実行し、問題を自ら修正できる
• コーディングエージェントも自分の変更を証明しなければならず、手動テストと自動テストを実施すべき
  • CLIツールでは、エージェントが直接実行するよう学習させたり、ClickのCLIRunnerのような仕組みで自動化したりできる
  • CSS変更時には、スクリーンショットの取得で結果を確認するよう設定できる
• プロジェクトに既存のテストがあるなら、エージェントはそれを拡張したりパターンを再利用したりする
  • テストコードの構成と品質は、エージェントのテスト生成品質に直接影響する
  • テストコードに対する美意識は、シニアエンジニアを見分ける中核的な能力として言及されている

人間の責任とコードの価値

• コンピュータは責任を負えず、その役割は人間が担わなければならない
  • LLMが大規模なパッチを生成することは、もはや価値ある行為ではない
• 本当の価値は、動作が実証されたコードを提供することにある
  • PR提出時には、コードが正しく動作することを示す証拠を必ず含めるべき

[ethanhur]

とても共感します。現在のPR方式では、コードの責任がメンテナーやレビュアーに転嫁される構造になっています。レビューしていないLLMコードを提出する人には不利益がありません。

Googleのコードベースに貢献してみると、コントリビューターのcreditのようなものを測定しているようですが、他のオープンソースや企業もこうした仕組みを導入することになりそうです。信頼がさらに重要な資産になるのではないかと思います。

[roxie]

ああ、そういう概念を使うんですね、Googleは

[tested]

> 動作が検証されたコードを届けることがあなたの仕事だ

[GN⁺]

Hacker Newsの意見

• 最近よく見かける憂うつな話がある。LLMツールで力を得たジュニアエンジニアが、巨大でテストされていないPRを同僚やオープンソースのメンテナに投げ、コードレビューが残りを何とかしてくれると期待するケースだ。しかも悪いことに、こうした振る舞いはジュニアだけでなくシニア開発者にも見られる

  • ちょうど昨日と今日、私がまさにそれをやった。チームがバグレポートを受け取り、外部ベンダー側の問題だと判断した。ところがベンダーから差し戻され、こちらの問題だと言われた。そこでCodexに調べさせたところ、問題を見つけてPRまで用意した。私は自分でレビューやテストをせず、チームに検証を任せた。その過程は、チームがLLMを業務ツールとして活用することを学ぶ助けにはなった
  • この2日ほどで、非開発のチームメンバー2人がAIエージェントにモバイルのバグ修正方法を尋ね、その回答をチケットの主要内容として貼り付けてしまった。結局、私がそれを全部読んで実際の要件を把握し直す羽目になった
  • 「シニア」という肩書きを持ちながらジュニアのように振る舞う人は多い。最近は卒業2年目でもシニアと呼ばれるので、そのせいで起きている現象のように思える
  • ルールを無視したり回避したりできる開発者が最も危険だ。以前に出会った10x開発者たちを思い出す。ルールを無視して機能だけ量産すると、結局は他の人が後始末をすることになる
  • コードレビューの中でジュニア開発者がどこにいるのか気になる。レビューに参加していないなら、自分のコード品質に責任感を持ちにくい

• 良いPRの書き方は、AI生成コードに限らずあらゆる場合に当てはまる。私はPRの説明を書くとき、現在の動作、変更理由、変更内容の順に整理する。テスト方法やスクリーンショット、E2Eテストのコマンドまで含めて、レビュー担当者の負担を減らす。こうすると、非同期コラボレーションや時差のあるチームにも役立つ

  • レビューを依頼する前に、自分でもう一度見直す。些細なタイプミスやログの削除を先に片付けておけば、レビュー担当者の時間を節約できる。Copilotのレビューもこういう点はよく拾ってくれる
  • 説明を丁寧に書いても、誰にも読まれないことが多い。それでも書き続けるのは、自分の責任感のためだ
  • AIが手伝ったPRであれそうでないPRであれ、テストの証拠と検証が含まれているべきだ
  • 以前は説明を長く書いていたが、誰も読まないことに気づいた。要点だけを箇条書きでまとめるほうが効果的だった
  • 私たちのチームのPRテンプレートには、チケット番号、依頼内容、現在の状態、変更後の状態、そして「mood gif」まで入っている

• エンジニアの本質は、要件を理解し、論理的な流れに変換し、トレードオフを調整し、結果に責任を持つことだ。コード生成や無作為なPR提出は、こうした基本が欠けている症状だ。コーディングエージェントは、むしろエンジニアリングの本質をあらためて思い出させるきっかけになっている

  • この記事を見ると、1行のコードが6,000万ドルの損失を生んだ事例がある。コードを理解せずにAIが作った1万行のPRは、潜在的な災厄だ
  • 現実には企業は品質よりもマーケティングと収益性を重視する。高品質な製品より、「プレミアム」というラベルの付いた製品のほうが売れる。結局、エンジニアリングより「売れること」が優先される構造だ
  • しかし組織が「AIを使って3日以内に機能を完成させろ、さもなくばHR面談だ」と圧力をかけてくるなら、理想的なエンジニアリング原則を守るのは難しいのが問題だ

• テストは必要だが、それだけで十分ではない。コードを論理的に検証する必要がある。テストは特定の入力と環境で正常に動作することを実証するにすぎない

  • 私も同感だ。ちゃんと動くコードでも、依然としてひどいコードでありうる
  • 「証明」よりも「demonstrate（実証する）」という表現のほうが適切だ。テストは特定のケースにおける証拠にすぎない
  • 単にテストだけを信じるのではなく、自分でいろいろな方法でアプリを壊そうとする。その過程で、より良いコードへ改善することになる
  • ほとんどのコードは形式的に証明できないので、property-based testingのようなアプローチが有用だと思う
  • テストカバレッジ100%を達成しても、コードが堅牢でなければ意味がない

• 私はテストを義務としてやっているわけではない。ただコードが実際に動くのを見たいからやっている。コードが動くのを見てワクワクしないなら、この仕事は向いていない

• LLMのおかげでジュニアが巨大なPRを投げてくるという話は聞いたが、私たちの組織ではまだそういうことはない

  • 巨大PRではないが、開発者自身が理解していないLLM生成コードはよく見る
  • 私たちの組織にもそうした事例がある。問題は次のとおり
    • エージェントが以前のフィードバックを巻き戻す
    • コードベースの標準に従わない
    • 既存の解決策を再発明する
    • PRフィードバックにエージェントの出力で返答する
    • 10〜20行の修正で済むはずが、5万行のPRとして提出する
    • テスト不足、エラー処理が不十分
  • 以前から低品質なPRを出していた人たちが、LLMのおかげで単により速く提出するようになっただけだ
  • WireGuard Android PR #82、#80を見ると、AIがコピペした回答がそのまま残っている。「files changed」タブを見ると混乱する
  • 友人が11人規模のスタートアップで働いているが、CTOが午前3時に1万行のコードをmainへ直接プッシュする。探索段階ならまだしも、安定化段階ではひどいリスクだ

• 「コードを証明済みの状態で引き渡すのが仕事だ」という言い方には同意しない。本当の仕事はビジネス上の問題を解決することだ。もちろん多くの場合、それはコードにつながるが、この区別は重要だ

  • だが、コードの正確性を証明することはビジネス問題の解決の一部だ。別の仕事ではない
  • 要件を満たさないコードを引き渡して、ビジネス問題を解決することはできない
  • 問題を解決しつつ、新たな問題を作らないことが重要だ。だからセキュリティと安定性が必要になる
  • まだ経験が浅いせいか、検証されていないコードでどうやって問題を解決するのか理解できない
  • 結局、あらゆる仕事の目的は問題解決だ。ただ、私たちはそれをコンピュータを通じて行っているだけだ

• 以前の職場では、日本の高品質なハードウェアメーカーで働いていたが、QA部門がバグを見つけると製品のリリースが止まった。そこで各開発部門が独自のQCチームを作り、事前テストを強化した。その結果、ソフトウェアは非常に徹底して検証されていた

  • 「get dinged」がどういう意味なのか気になる。こういう構造は、かえって変更を恐れるようにしてしまうかもしれない

• 最近は仕事の本質がチケットを閉じることに変わってしまった。コード品質は統計に表れないので重要視されなくなる。私はそんなシステムには加わらない。今では職人技は消え、誰もが安い合板と接着剤を欲しがっている

  • LLMを全面導入して全員が使うことを期待するようになった瞬間、ソフトウェアエンジニアリングはもはや真面目な工学ではない
  • そうした態度を批判する人に対して、「ではあなたは政府補助金で暮らしているのか？」と尋ねる人もいる

• 「証明されたコード」の意味が問題だ。LLMが作ったテストを付けて巨大なPRを提出するケースもある。私も個人プロジェクトではvibe codingをするが、チーム単位でそうするのは悪い習慣だ。エンジニアを雇う理由は、彼らの専門性を買うためなのだから

  • だから私は手動テストを重視する。スクリーンショットや動画で実際の動作を見せるだけでも、大きな信頼につながる