AIのコードが機能していても拒否する理由

2026年6月21日原文(vinibrasil.com)

概要

AIによるコード生成が加速し、 レビュー作業 が新たなボトルネックに
自分自身の git diff でさえ、 認知的負荷 が増大
AI導入前と比較し、 納得感や説明力 の低下を実感
AIコードの受け入れ基準や 人間のレビュー の重要性を強調
コーディングエージェントは 補助ツール であり、 主導権は人間 が握るべき

AIコードレビュー時代の課題と気づき

AIによる コード生成速度 の向上により、 レビュー作業 が新たなボトルネック
他人のPRだけでなく、自分の git diff の確認にも多大な労力
計画モード やタスク分割、小さな変更単位でのコミットなど、良いプラクティスを実践しても 認知的負荷 は減らない現実
自分で深く考えずにAIが出力したコードをレビューする際の 納得感の低下
AI導入前は、課題をじっくり理解・検討し、コードベースを探索しながら解決策を模索
- 時間をかけて コンテキストを統合 し、最終的なPRに自信と 説明力 を持てた
AI導入後も大きな課題には日数がかかり、AI生成コードを一度全て却下して書き直すことも多い

AIコードを却下する理由

AIのアプローチを 自分の言葉で説明できない 場合
diff が問題規模よりも 大きすぎる 場合
必要性が証明されていない抽象化 を先に導入している場合
ローカルでは動作しても、 システム全体の可読性や保守性 を損なう場合
自分の理解よりAI出力を信頼 していると感じた場合

人間レビューの重要性

AI生成コード をエンジニアが 安易に受け入れる 事例が増加
AIレビュー と 人間による必須レビュー の併用を推奨
CIが通る コードでも、 本質的に悪い解決策 である可能性
エンジニアリングの本質は「 適切で拡張性・保守性のある解決策」の実装

コーディングエージェントの限界と役割

コーディングエージェントは 非常に優秀な補助者 だが、 優れたエンジニアの導き が不可欠
単なるコード生成だけでなく、問題解決プロセス全体を補助可能
しかし、 完全自律的・持続的な運用 にはまだ課題
主導権は人間 が持ち、AIを使いこなす姿勢が重要

Hackerたちの意見

「現実は、CIがグリーンになるコードが動いても、それが悪い解決策である可能性があるってこと。エンジニアリングは常に、適切でスケーラブル、かつ拡張可能な解決策を実装することが大事なんだ。」適切ってのは、たいてい「できてて安い」ってことだよね。

└

反対だな、適切ってのは適切なことを指すんだ。できてて安いってのは、解決策が適切なときに使う言葉だよ。もし解決策が適切じゃなかったら、安くても意味ないし、そもそもできてないからね。

└

安全で安定していることが基本的な要件だと仮定するなら… まあ、そうかもね？

└

「適切ってのは、たいてい『できてて安い』ってことだ。」何をやってるかによるけどね。内部ツールやシンプルなダッシュボードを作ってるなら、コードの見た目なんてあんまり関係ない。でも、他のプログラムが依存するソフトウェアを書いてるなら、悪いデザインの選択が波及して、次の世代のソフトウェアに影響を与えるんだ。LinuxカーネルやGoogle Chrome、コンパイラやランタイムに不具合があったら、許されないよ。多くの人がエンドユーザー向けのソフトウェアやウェブUIを作る仕事をしてるのは知ってる。AIはこういうコードを書くにはどんどん良い選択肢になってきてるけど、それが全員の仕事じゃないし、書かれているソフトウェアのすべてでもないからね。

└

システムエンジニアリングに関する動画を見てたんだけど、以下のことが印象に残ったよ。ステークホルダーのニーズ：人々が製品で達成したいことマネジメントのニーズ：製品を作るためのリソース（時間、お金…）の管理方法エンジニアリングのニーズ：製品は何かこの3つのバランスを取らないといけない。時にはシンプルで簡単に正解が得られることもあるけど、時には複雑すぎて、製品が世に出るまで本当に正しいかどうかわからないこともある。ソフトウェアは柔軟だから、ハードウェアではできないような反復作業が簡単にできる。でも今は、エンジニアリングに偏りすぎていて、解決策を作ることだけに集中してる。問題の理解もリソースの適切な配分もなく、とにかく何かをやる。たとえそれが11回目の亀裂を埋めることでも。

Fableを使ってた時（短期間だったけど）、計画を洗練させて、小さな段階的変更だけを指示しても、初回の結果を拒否する理由がたくさんあったよ。「反発して正解だ」って反応が多かったし、何かを達成するために巨大で複雑な抽象のセットを作り出すことがあったけど、もっと優雅でメンテナンスしやすい方法が見つかることも多かった。自分が深く知っているコードベースでこういうツールを使うのは本当に目から鱗だよ。どこにでも問題があるからね。でも、他の言語の知らないプロジェクトを開いて、メンテナンスするつもりもなくちょっとした機能を追加したいときは、変更を受け入れて、うまく動くまでループするのは全然構わない。怖いのは、チケットを閉じてクレジットを集めることしか考えてない同僚と一緒に作業しているときだよ。トークン予算があれば、LLMを使ってループを回して、プログラムがうまく動くまで試すことができる。コードレビューを頼んで、何をしているのか理解せずにPRを提出することもできる。こういうことに対して反発する良いメカニズムがない職場が多くて、技術的負債がどんどん増えていくんだ。

└

「トークン予算があれば、LLMを使ってループを回して、プログラムがうまく動くまで試すことができる。コードレビューを頼んで、何をしているのか理解せずにPRを提出することもできる。」こういうことに対して反発する良いメカニズムがない職場が多くて、技術的負債がどんどん増えていくんだ。自分はこれに対してLLMを使うことを推奨してるわけじゃないけど、LLMが出る前からこういうことはあったし、ただ少し遅かっただけなんだよね。長期的にうまくいかないとは言えないし、実際、こういうことをやってて、ほぼ24時間働きながらアデロールを大量に摂取してた人たちとも一緒に働いてたから。組織内のインセンティブ構造は、こういうことをやることを奨励してたし、若手エンジニアからの社会的信用も得られてた。最後に一緒に働いたカウボーイは、こういうことをやってたけど、結局会社の最年長エンジニアになって、億万長者になり、雇ってたほとんどの新卒から神のように崇拝されてた。問題は、こういう人たちが結局燃え尽きて去ってしまうと、その後に大きな空白が残ることなんだよね。彼らが担っていた負荷ではなく、彼らが作り出していたもののせいで。自分がいた組織が大きくなるほど、夜や週末に大きなコミットをする人をより評価する傾向が強くなった。さらに悪いことに、彼らは自分のコードをTBRしてレビューなしでマージすることができてしまった。LLMは、私たちがすでに抱えていた悪習慣や組織の問題をスピードアップさせたものに過ぎない。正しくやっているところもあるけど、元々そうだったんだよね。

└

こういうことに対して反発する仕組みが整ってない職場が多いから、技術的負債がどんどん増えていくんだよね。「スパゲッティボール」理論が正しいなら、技術的負債を管理できないソフトウェア企業は、スパゲッティコードを追加し続けて自滅することになると思う。そうなると、数ヶ月後には「ソフトウェア破産」を宣言する企業が続出するかもね。これらの職場が少しでも気を使って、いい方向に進むことができるかどうかが鍵だね。

└

クロードのモデルはみんなおべっか使いだよね。「あなたが絶対正しい」というミームは本当だし、そのフレーズがあまり出てこなくても。喧嘩を始めたくはないけど、私の経験ではCodexの方が少しはしっかりしてる。変なことを指摘すると、時々ちゃんと理由を返してくれる。でもクラウドはいつも「おっと、あなたが正しいです、さすがです」と言うだけで、私が見落とした時でもそうなんだよね。

└

「反発してもいいよ」というシナリオは、私にとって怖いんだ。私は主にMLの実装をコーディングしてるけど、Claude Code（CC - Opus 4.7しか使ったことない）が出すエラーはすごく巧妙で、特定の分野に十分な経験がないと（MLに入ってきたばかりの人がCCで実装を書くときに見かける）、CCに疑問を持つタイミングがわからなくて、エラーや将来の落とし穴が静かにコードに入り込んじゃうことがある。最近の例では、モデルのキャリブレーションステップでデータリークがあったんだけど、CCはそれをエラーとして認識せず、私が詳細な理由を書いたら「微妙なリークがある」と認めたんだ。

└

公平に言うと、どんなに経験豊富なエンジニアでも、新しいコードベースに放り込まれたら、すぐに侵入的でリスキーな作業をさせると、たぶん何度もミスをすると思うよ。

└

見つけたいいテクニックは、「もっとシンプルにして」と続けること。たいてい、2〜3回それを繰り返すと、要件を満たしつつ、理解しやすいものができるんだ。私はRailsのバックグラウンドがあるから、KISSが私の哲学に根付いているかもしれない。少なくとも、デザインパターンを強く推しているわけではないし…。

Hacker Newsで議論の続きを見る

ハクソク