Ask HN: 理解していないAI生成コードを出荷する際の対処法は？
Ask HN: How to deal with shipping AI-written code you don't understand?
私は引退していて、進捗について答える相手は自分だけです。品質を速度より優先する頑固な人間ですが、進歩は好きです。今朝、コンパイラの'C'フロントエンドの予備結果を得ました。これはclangを使ってLLVM IRにコンパイルし、それを我々のIRに変換して、あたかも自分でコードを解析したかのように自動ベクトル化器に供給します。同じソースコードで、clang -O2と比較して最大1,312倍の高速化が得られ、チェックサムも一致して正しく動作していることを確認しました。しかし、Hacker Newsは興味を示さず、リンクを投稿してもすぐにブロック/デッドになります。C++フロントエンドが来週準備できたら、別の場所で発表するつもりです。標準のC/C++コードを自動的にデータ並列領域を見つけてGPUでスケジュールし、プログラミングのオーバーヘッドなしで高速化するコンパイラはかなり珍しいです。さらに、ローカルネットワークも管理し、LAN上のマシンやMac間のTB4/5ブリッジ経由でxcdを実行して他のGPUでスケジュールできます。レイテンシと計算時間の両方を特徴づけて、スケジュールする価値のあるデバイスを判断します。
AIが書いたコードを理解していないなら、それは技術的負債です。私は常にコードをレビューし、理解できない部分はコメントを追加してでも把握するようにしています。理解できないコードを出荷するのは、後で自分やチームが苦しむことになります。
AI生成コードでも、テストが十分にあり、動作が保証されていれば、必ずしも完全に理解する必要はないと思います。重要なのは、コードの動作を検証する手段を持つことです。ブラックボックスとして扱い、入出力のテストを徹底すれば、理解していなくても安全に運用できます。
私はAIが生成したコードをそのまま使うのではなく、必ずリファクタリングして自分のスタイルに合わせます。そうすることで理解が深まり、保守性も向上します。AIはあくまで補助ツールであり、最終的な責任は人間にあるべきです。
理解していないコードを出荷するくらいなら、AIにコードを説明させるのが良いでしょう。ChatGPTやClaudeにコードを貼り付けて、行ごとに説明を求めれば、理解が進みます。また、AIにコメントを追加させるのも有効です。
チームで開発しているなら、AI生成コードのレビュープロセスを確立すべきです。コードレビューで理解を共有し、疑問点を解消する場を設けることが重要です。個人開発でも、未来の自分のためにドキュメントを残すことをお勧めします。
HNでの議論
218- trezm
https://getchronosphere.com をいじってみています。これは巨大な塊ではなく、一貫した流れでPRを（再）構築しようと試みます。今のところ多少役に立っていて、まだ改善中です。
- ChrisMarshallNY
テスト。
とにかく大量のテスト。普段はLLMと対話的にテストしています。コーディングに費やす時間が減った分、テストに時間をかけられるようになりました。
経験上、LLMを使うと自分のコードよりもテストが増えます。コーディングエラーは見つかりませんが、実装エラーは見つかります。
別の話ですが、自分が書いたかなり成熟したコードでLLMを走らせたところ、「完璧」だと断言できたはずのコードからいくつかの問題が見つかりました。
完璧な人などいません。信頼せよ、されど検証せよ。
- skeledrew
技術的にはただの役割の変更です。あなたは今や開発者ではなく、プロジェクトマネージャーのようなものです。プロジェクトマネージャーの仕事はコードを理解することではなく、コードがすべきことを行い、すべきでないことを行わないようにすること、そして開発者などがブロックされずにうまくやっていることを確認することです。新しい役割を受け入れましょう。
- 4ndrewl
これはすべてのプロダクトマネージャーが毎日感じていることです。
もしあなたがLLMプロンプターとして製品を出荷しているなら、あなたのアウトプットはソフトウェアエンジニアのものというより、プロダクトマネージャーのものに近いです。
- spacedcowboy
動けばそれでいい、という考えにゆっくりと傾いてきています。以前も同僚の仕事をすべて個人的にチェックしていたわけではなく、彼らが良い仕事をしたと信頼していただけでした。
だからといってLLMを盲信しているわけではありません。私のプロジェクトは自動ベクトル化コンパイラです。膨大な数のテストを書かせ、実際の非自明なプログラムをコンパイルさせています。リリース前には5つの異なるアーキテクチャで文字通り数時間かかる「ゲート」を実行させています。このコードがテストされていると言うのは……控えめに言っても見事なものです。
役立つのは、詳細を詰め、コーナーケースを洗い出し、テストケースを設計するような、いわゆる作業と努力を伴う長い計画セッションだと思います。それが終われば、一晩中動かして主要な本番機能をやらせるのは簡単です。
今でもコードはレビューしていますが、正直に言ってすべてをレビューしたとは言えません。複雑なチェックインでは見落とすこともあります。チェックインは小さくまとめるようにしていますが、「壊すな」というルールと並行して管理するのは時に簡単ではありません。
つまり、これについて6ヶ月ほど取り組んでいて、今のところうまくいっています。長い時間をかけて同僚の癖に慣れるようなものです。
経験上、コードの品質はかなり高いと言えます。それは計画段階で事前に費やした努力のおかげかもしれませんが、私の場合は人々が不満を言うような「スロップ」には悩まされていないようです。ただし個人差はあります。
- solatic
AI以前のプリンシパルレベルのエンジニアの生活とそう大きくは変わりません。あなたは技術的には多くのエンジニアがそれぞれのシステムで行う仕事を監督しますが、すべてのコードを自分でレビューすることは到底できません。人間のコードレビューが本番に出荷されるバグの数と深刻度を減らすことはあっても、なくすことはないと理解しています。頭の中に低レベルの詳細はなく、高レベルのものだけがあります。これらのエンジニアが互いに足を踏まないようにどう相互作用するかを設計します。
低レベルのシステムを理解する人間を信頼するシステムから、高性能な計算機を信頼するシステムに移行したのが正しかったかどうかは、時間が経てばわかるでしょう。しかし今のところ、うまくいっています。
- cadamsdotcom
テスト駆動開発とテストピラミッドです。
エージェントがテストを書き、決定的なことに、テストを通すための作業を始める前にそのテストが失敗するのを目撃していれば、大きな自信が持てます。
自分の仕事のレビューも簡単になります。テストとプロダクションコードは互いに鏡像となる傾向があり、はるかに完全な全体像が得られます。プロダクションコードに混乱したら、しばらくそのテストを読んでから戻ってきましょう。
ビルドに立ち会い、トランスクリプトを見て、時々チェックインしていれば、変更を理解するのも簡単です。主要なタスクである必要はありません。セカンドモニターに置いておけば、自然に目に留まります。
そして最後に、テスト駆動開発に加えて、エージェントに最初のTDDサイクルの前に、これから行う作業をカバーするエンドツーエンドテストを構築させましょう。そのテストがグリーン（TDD用語で「合格」）になったら、作業は完了し、自由にクリーンアップできます。
出荷する前に遊んで、しっかりと仕上げましょう。技術的負債をきれいにし、UIを完璧にするのがこれほど簡単だったことはありません。
最終的にはPRにまとめる準備ができるでしょう！
ここでエージェントを活用して創造性を発揮できます。同僚をうならせてレビューさせましょう。Loomビデオを作って説明するのもいいでしょう。コミットシリーズに再構成するのもいいでしょう。エージェントなら数秒ででき、人間に物語を語れます。苦労に合わせて順序立てるのもいいかもしれませんし、各コミットで異なるレイヤーが現れるのを見せる方がいいかもしれません――[…]
- vjerancrnjak
形式検証です。それが統合された言語を選び、関連する事後条件を証明しましょう。
AIはまだ不可能な状態を表現不可能にするコードを書くことすらできず、テストは役に立ちません。