本文へ
ハクソク

世界を動かす技術を、日本語で。

HNに聞く: 理解できないAIが書いたコードをどのように出荷すればよいですか？

元記事:

概要

  • MetaのエンジニアがAI時代の開発現場で感じる違和感
  • コード全体の詳細を把握できない現状の共有
  • 高速なAI導入による新しい開発標準の出現
  • ソフトウェアエンジニアとしての本能との葛藤
  • 他のエンジニアへの共感と対策の問いかけ

AI時代におけるエンジニアの葛藤と新たな標準

  • Metaのエンジニアによる現場の実感

    • AI導入の加速 による開発現場の変化
    • コードの多くが ブラックボックス化 する現象
    • 詳細なコード理解 が困難になっている現状

  • 新しい開発標準の出現

    • AIを活用した高速リリース が求められる環境
    • 各行のコードを 綿密に確認する時間的余裕 の欠如
    • 高レベルの理解 のみで開発を進めるケースの増加

  • ソフトウェアエンジニアとしての本能とのギャップ

    • 「自分が作るものを完全に理解したい」 という本能
    • その本能と 現実のスピード感 との間の葛藤
    • どこまで理解すれば前に進めるか という新たな課題

  • 他のエンジニアへの問いかけ

    • 同じような不安や違和感 を持つエンジニアの存在
    • それぞれの 対処法や考え方 の共有への期待

AI時代の開発現場でエンジニアができること

  • ブラックボックス化への適応戦略

    • 重要な部分のみ 重点的に理解 する方法
    • ドキュメントやテスト を活用した全体把握
    • チーム内での知識共有 によるリスク軽減

  • 新しい標準との向き合い方

    • 「すべてを理解する」から「本質を押さえる」 への意識転換
    • AIツールの信頼性や限界 を知る姿勢
    • 継続的な学習 と柔軟なマインドセットの重要性

  • エンジニアコミュニティの役割

    • 経験や課題のオープンな共有 による課題解決
    • 新しい働き方や基準 の模索
    • 心理的安全性の確保 と健全な議論の促進

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

ゆっくりだけど、動けばそれでいいって考えに慣れてきた。前は同僚の仕事を全部チェックすることなんてなかったし、彼らがちゃんとやってくれるって信じてたからね。とはいえ、LLMを盲目的に信じてるわけじゃないよ。私のプロジェクトは自動ベクトル化コンパイラなんだけど、テストを山ほど書かせて、実際にコンパイルした非トリビアルなプログラムもある。リリース前には、5つの異なるアーキテクチャで数時間かかる「ゲート」を通すんだ。このコードがテストされてるって言うのは…控えめすぎる表現だね。長いプランニングセッションをして、細かいところまで詰めて、コーナーケースを考えたり、テストケースを設計したりするのが助けになると思う。そうやって準備が整ったら、夜通し動かして大きな機能を作るのも楽になる。コードはまだレビューしてるけど、正直言って全部見たとは言えないな。複雑なチェックインで見落とすこともあるし。チェックインは小さくまとめるようにしてるけど、「壊さないで」ってルールと両立させるのは簡単じゃない時もある。だから、結局のところ、これを6ヶ月くらいやってきて、今のところうまくいってるって感じ。時間をかけて同僚のクセに慣れていくようなもんだね。私の経験では、コードの質はかなり高いと思う。多分、計画段階での努力のおかげかもしれないけど、みんなが文句を言うような「雑さ」は感じないな。人それぞれだけどね。

└

METAにはいないけど、blindで読んだことを前提にすると、彼らは長いプランニングセッションや実装計画の詳細に時間をかけてないみたい。今は並行して管理しなきゃいけないPRが多すぎて、それも無理だろうね。

└

ゆっくりだけど、動けばそれでいいって考えに慣れてきた。別名「ハンマーで叩いてもコンクリートが崩れなかった。」プロセスの質はずっと重要なテーマだよ。

└

そう、コンパイラは徹底的なテストで検証するのに良い候補だね。包括的なテストスイートが通れば、コードの各行をレビューすることはそれほど重要じゃない。

└

ここでの最初の段落を見てみて: https://alexgaynor.net/2026/sep/07/is-it-correct/ 「動作する」の定義に「脆弱性がない」が含まれるなら、単に触ってテストを追加するだけじゃ足りないよ。

└

ここも似たような感じ。内部プロジェクトでは、テストは「動作するかどうか」で、ユニットテストと統合テストが作成されて、私たちのアーキテクチャに正しく従っているかどうかを見ている。

└

自分が同僚の仕事を全部確認したことはないよ、マジで！最近のソフトウェアがクソなのも納得だわ。コードレビューって聞いたことないの？それとも、見せかけだけだと思ってたの？変更を一週間放置して、読まずに「受け入れる」ボタンを押すの？

テスト。たくさんのテスト。私は通常、LLMとインタラクティブにテストしてる。コーディングにかける時間が減った分、テストにもっと時間を使えるようになった。私の経験では、LLMを使うと、自分のコードよりも多くテストしてる。コーディングエラーは見つけないけど、実装エラーは見つけるよ。別の話だけど、私が書いた成熟したコードにLLMを使ったら、「完璧」だと思ってたのにいくつかの問題を見つけた。完璧な人なんていないよ。信頼はするけど、確認も必要だね。

└

つまり、物を作るのに時間とお金を節約できたけど、その分、検証やテストに新たな作業が増えたってこと？デザインループで時間と労力の使い方を変えただけで、何か得られたものはあるの？

└

「たくさんのテスト」を解決策として考えると、（自動テストのことを言ってるなら）たくさんのコード行を招いて、コードレビューがさらに難しくなるって問題があると思う。もし誰かが私の50行のAI生成バグ修正をレビューするのが大変だと感じてるなら、200行のテストを追加することで、レビューする行が増えるだけだよ。

└

理解できないコードをどうやってテストするの？ブラックボックスのエンドツーエンドテストは、多くのアプリケーションには適してないし、実用的でもないよ。ユニットテストや統合テストは、テストしたいコードを理解してないと、何をアサートするかもわからない。AIに全部任せてるの？

└

要するに、コードをレビューもしないで検証してないってことだよね。テストスイートがすべての可能な動作やコードパスをテストしても、LLMが追加した意図しない動作をすべてキャッチするのは難しいことが多い。実際、大抵のテストスイートは意図しない動作（例えば、意図しないインターネット接続）を見逃しちゃう。誠実な人間がコードを書いたりレビューしたりしているときは、大した問題じゃないけど、意図しないコードは見つけやすいからね。でも、LLMは何でもコードを追加しちゃうかもしれない。プロジェクトのコードがトロイの木馬のコードに似ていることがあって、それをトロイの木馬で補完しちゃうかもしれないし、サーバーにアクセスできないときにクライアントのデータを公開のGithubリポジトリにアップロードすることを見つけるかもしれない。あるいは、デバイスの空き容量がなくなったら、ユーザーのフォルダを削除することもできる。そんなことが起きたら、クライアントは理解してくれるかな？

Hacker Newsで議論の続きを見る