AIコーディングの罠！知らぬ間にハマってない？
引用元：https://news.ycombinator.com/item?id=45405177
AIが人を怠惰にするって批判は嫌だなぁ。LLM使っても計画→構築→テスト→反省は超大事だし、そうすれば建築やテストみたいな楽しい部分に時間を使えるよ。AIは「考える」のが好きな人にはいいけど、「手を動かす」のが好きな人には楽しみを奪うってのが対立点だね。
AIコーディングがコードの深い理解を奪うって批判は的確だよ。SEの仕事はコードを書くことじゃなく、機能するシステムを作ることなんだ。コードの「精神モデル」を理解するのが超重要だけど、LLMはこの部分が苦手で、構文レベルの推論だけじゃ限界があるって話だね。
なんで？コードってただの成果物じゃん。本当に価値があるのは、ドメインをしっかり理解して問題を解決することだよ（でも、これも将来的にはAIがやっちゃいそうだけどね）。
今のメンテナーがオリジナルのコードを書いてないってケースはよくあるよね。コードを読む時間と書く時間の比率を考えたら、GenAIが書いたコードと、昔の作者不明のコードって、正直あんまり変わらないんじゃない？って疑問に思うんだ。
LLMへの批判って、別に精神的な敏捷性が落ちるとかじゃないんだ。OSSへの脅威、人の創造性が奪われる、大規模なIP盗用、仕事がなくなる、情報格差が広がる、人間性が曖昧になる、ボットが増えすぎてオンラインコミュニティが壊れる、みたいな問題があるよ。これらは訓練や運用方法に起因するんだ。
これって昔Pythonが批判されてたのとそっくりだよね。「スクリプト言語じゃ本当のコードが何してるか分からない」って言われてたけど、結局は高レベルな部分に集中することで大きな価値を生み、ユニコーン企業もたくさん生まれたじゃないか。
AIコーディングが深い理解を奪うなんて、それはないよ。理解を飛ばすのは開発者本人のやる気がないだけだ。LLMに詳しく聞けばちゃんと理解できるし、批判してる人たちは最初から偏見持ってるか、ただのスキル不足じゃないかな。
テクノロジーが不注意を招くとは限らないけど、このAI技術はそうなりがちだ。アーキテクチャは好きだけど、チャットボットは意図を伝えるのが間接的だし、コードの理解がすぐに消えちゃう。細かくレビューするとツールの目的と合わないしね。良い自動化は安全で予測可能だけど、チャットボットはそうじゃないんだ。
人間って、自分が嘘だと知らない嘘を好む傾向があるよね。LLMは正確さじゃなくて、「正確そうに見えること」を優先しちゃうから、ミスしても気づきにくい危険なツールなんだ。それに、LLMを使うことで認知負荷が増えて、かえって不注意になっちゃうこともあるんだよ。
AIは本質的な思考を促さず、CEOみたいな大風呂敷の計画を推奨してる。プロAIの投稿は手続きとか方法論ばっかりで、本質的な思考じゃないよ。AIを使うのは演習なしで数学書を速読するようなもので、プロAIの人たちは真面目な公開コードベースを持ってないんだ。
「目的が手段を正当化しない。AIによる知的財産権侵害は著作権侵害だ」って言うけど、AIコーディングってほとんどオープンソースコードとか公開ドキュメントで学習してるんじゃないの？
「AIで思考に集中できる」って主張はもううんざり。実践なしに思考だけじゃ、思考はどんどん浅くなるって反論に、誰もまともに答えられないのはなぜ？実践がなければ、思考なんて深まらないってこと。
俺はLLMでコーディングしてるし、その使い方が気に入ってる。思考を丸投げせず、文脈を与えれば1000行のC言語プログラムも成功したよ。もちろん、一行ずつレビューしたし、なんでレビューしないのか理解できないね。小さく始めて積み上げていくことで、LLMは俺の考えや好みを理解してくれたんだ。
GenAIが作ったごちゃごちゃコードと、元の作者がいないごちゃごちゃコードの違いは、後者には改善の希望があるってこと。自力で読み解き、書き直すことでコードを理解し、推論能力を磨ける。でもAIに任せっぱなしだと、いつまでたっても他人のコードを「初日」から所有する感覚で、自分のモデルは育たないんだ。
「AIが人を怠けさせる」以外の反AI意見が見たいって？俺はAIでコード書くけど、手書きに戻ることが増えたよ。理由は、AIだとコードじゃなくてプロンプトを書くことになるからね。プロンプトとAIの処理時間が手書きより短ければ使うけど、大抵はリファクタリングだけ。それ以外のタスクだと、AIを使うと結局手書きより時間がかかったり、AIクレジットを無駄にしたりする。結局、手書きの方がコードも時間も「安全」って気づいたんだ。
LLM否定派のコメントはエンジニアとして悪い印象を与える。俺はMetaやGoogleのスタッフエンジニアだったけど、LLMに価値を見出せないって言う人は、新しいツールに適応できない人だと思うよ。LLMが万能じゃないのは確かだけど、全く活用できないのは単にそのツールを学んでないだけ。適応できない人は大手テック企業でも解雇されるし、「デバッガー使わずprintfデバッグ」って言ってるのと同じくらい時代遅れな考え方だよ。
「AIツールを使うとコードを書く代わりにプロンプトを書くことになる」って言うけど、俺はAIコーディングの時の方がタイピング量が増えて手が痛くなるって確信してる。音声入力モデルをコーディングエージェントに早く統合してほしいね。
LLMをプログラミング言語と比べるのは間違ってる。LLVMはアセンブリを100%正確に生成してくれるけど、AIはそうじゃないかもしれない。特にテンプレートみたいな単純なアプリから離れるほどね。
「AIは理解をスキップさせるわけじゃない、開発者のやる気次第」って言うけど、それが問題なんだよ。普通の開発者は楽な道を選んで理解をスキップする。君の言うことは正しいけど、論点がズレてるんだ。平均的な開発者はAIを巧みに使う努力をしないだろうから、広範囲にわたるAIコーディングは懸念材料だよ。
ソフトウェアエンジニアリングの議論では、1000や10000 SLoCみたいなちっぽけなプロジェクトなんて誰も話してないよ。そんなのつまらないし、マジで話すべきは100k SLoC超えのプロジェクトだろ。
AIって過去のものをリサイクルしてるだけじゃん。新しいものは生み出せないんだよ。
AIが書いたコードは機能的には合ってるかもしれないけど、自分で書いた方がはるかに速かっただろうね。
MacだとホットキーでエージェントCLIと会話できるけど、まだもうちょっと磨きが必要かな。ホットキーなしで、音声コマンドでAIのタスクを中断できるくらいになれば最高なんだけどな。
俺たちのほとんどは、過去のソリューションをただリミックスしてるだけなんだよ。世界に何がすでに存在するのか深く探求しないと分かんないから、自分たちがすごくオリジナルでユニークなことやってるって勘違いしちゃうんだよね。
なんでいつも10k LOC以下のプロジェクトは無視されるんだ？LLMで成功したプロジェクトって言っても、10k LOC以下だと“カウントしない”って言われるのはなんで？全部の重要なプロジェクトが100k LOC以上である必要はないし、“重要”の定義を勘違いしてるんじゃない？
マネージャーやテックリードは単純作業を部下に任せて、難しい問題に集中することで効果的になると思わない？これはAIが抽象化レベルを変えるのと似てるんだよ。アセンブリをやらなくてもPythonが使えるように、AIがより高い抽象度で思考することを可能にするんだ。
AIの問題じゃないよ。知識のない「vibe-coding」で有能なエンジニアが不要になるって考えが問題なんだ。現実離れしたプロジェクトはいずれ破綻するし、開発者は本気でコーディングを学ぶかPIPされるかのどちらか。学生や見習いは、AIを使う前にしっかり基本を学ぶべきだよ。
LLMを使った音声テキスト変換モデル使ってる？Macの標準のやつってマジでひどいじゃん。ChatGPTの音声モデル使ったことあるなら、俺の言ってることわかるだろ？
Electronがこれだけ普及してるんだから、開発者の時間の方がCPU時間よりはるかにコストがかかるってことはもうみんな知ってるだろ。
小さいプログラムは簡単に書けるし、プログラマーの仕事のほとんどはデカいプログラム作りに使われてるから、LLMが小さいプログラムを自動化しても、全体的な影響はあんまりないんだってさ。
プログラマーの代わりにはならないけど、ホワイトカラーとかの仕事の自動化には役立つかもね。
もっとコメントを表示（1）
LLMエージェントって、他の人のごちゃごちゃしたコードに入ってすぐに活躍できるからマジ助かるよ。
修正や理解にかかる時間が激減するし、技術的負債を返すコストもめっちゃ下がるんだってさ。
エージェントコーディングの世界は、新しい考え方とやり方が必要だけどね。
LLMを使っても、熟練エンジニアはコードを書く前にめっちゃ考えるって。
むしろLLMエージェントを使うからこそ、もっと深く計画を立てるようになって、それが設計ドキュメントに残るようになったのはマジで良いことだってさ。
「DO NOT WRITE ANY CODE YET.」ってプロンプト、よく使うよ。
LLMは学習しなくても、俺たちはその使い方から日々学んでるんだから、これってすごく価値があることだよね。
コード書く前の考える時間って、ソフトウェア開発全体から見るとすごく大事な部分なんだよ。
だから、実際にコードを書くスピードが上がったとしても、全体の生産性や人手にかかる時間は劇的に変わらないんだよね。
この理屈、ちょっと変じゃない？
考えるのが大事なのはわかるけど、実際にコードを動かすことも同じくらい重要だろ。
理想を言えば、考えてる時間とコード動かしてる時間には桁違いの差があるべきなんだ。
コードを動かすのは簡単に任せられるけど、考えることはそうはいかないってこと。
LLMが俺たちとの会話から学習して、その記憶を保存・復元できる機能がマジで欲しいんだ。
文脈窓とか関係なく、情報が失われない形でね。
RAGとか要約は一時しのぎに過ぎないんだよ。
例えば、昨日foo関数がmooオブジェクトをbarfizeするって教えたら、今日splarferのこと聞かれた時に、その知識を使ってbarfizeされたmooオブジェクトに変換できるって教えてほしいわけ。
これってウォーターフォールとアジャイルの議論を思い出すよね。
コード書く前に完璧な設計図とすべての落とし穴を見つけるのが理想だけど、実際はコードを書き始めて30分で誰も思いつかなかった問題が出てくるもんだからね。
「DO NOT WRITE ANY CODE YET.」ってプロンプト、俺もいつも使うよ。
そうすれば、LLMがコードを吐き出す前にちゃんと何をしようとしてるか理解できるし、制御できるからね。
コード書くのはあんま好きじゃないけど、問題解決とかロジックの組み立て、システム統合はマジで楽しいんだ。
ミクロはともかく、マクロで30分でアーキテクチャの問題を見つけるとか、それってちゃんと事前に計画してないってことじゃないの？
Claudeにコードをすぐに書かせない設定がないのは意外（か、俺が知らないだけか）。Claudeは間違いなく、すぐ行動したがる傾向があるよな。
俺はエージェントへの最初のプロンプトを「まだコード書くな」から始めるのが好き。実際に編集したりファイルに触る前に、まずどんな行動計画を考えてるか聞くようにしてるんだ。
何を作ってるかによるよ。もし単なるCRUDアプリならもちろんそうだけど、少しでも斬新なものなら、一度は試さないと全体の状況なんて理解できないんだ。
君が求めてるのは、エンジニアリングのブレークスルーが必要なものなんだろうな。モデルには記憶も、訓練で学んだこと以上の理解や知能もない。
コンテキストを与えれば、次に何が来るか予測するだけだ。訓練と推論をクソみたいにスケールして大規模なコンテキストを扱おうとしても、今のところ高すぎるし、もう一つの問題にぶち当たる。モデルがその膨大なコンテキストのどの部分が関連しているか確実に判別できないんだ。無関係なトークンがノイズになって、シグナルを薄めたり、間違った方向にバイアスをかけたりする。
だから、関連性の高いコンテキストをしっかり与える、つまりコンテキストエンジニアリングが必要になる。10万行のコードベースを見て、何が問題に関連してて、何が関係ないか、なんてモデルには判別できない。その部分は自分でやるしかないんだ。
あるいは、その部分を別のモデルを使って調査させ、コンテキストを構築することで、少し自動化しようとする人もいる。これが研究→計画→構築のループと言われるものだ。小さいタスクに留めるのがベストだよ。でないと、大きなタスクに必要なコンテキストはあまりにも大きくなりすぎるからね。
「まだコード書くな」ってプロンプトは、IntelliJだとすべての変更を承認しなきゃいけないから、必要ないんだ。承認なしで勝手に変更しちゃうYOLOモードもあるけど、俺は絶対使わない。誰か使うやついるのかな？
事前にドキュメントを書いておく（別のリポジトリにドキュメントとして保管する）ってやり方も成功したよ。それを各段階で参照するんだ。ドキュメントにはさまざまな機能の擬似コード例を入れておけば、まずモデルで大まかに作って、次にテストを失敗させるとかできる。LLMと俺、両方が参照できるガイドラインがあるって感じだね。
要するに、エンジニアリングのブレークスルーが必要なものが欲しいってことだね。今のLLMの働き方じゃ俺が望むものは提供できないのは分かってるけど、俺が欲しいのは違うやり方で実現するものなんだ（LLMを使わなくてもいい）。
ここでは、彼の最初のチャートについて議論してるんだな。俺は同意するけど、君はそうじゃない。
もしコードを動かすのに思考と同じくらいのエンジニアリング時間を費やしてるなら、君のプロセスは何か間違ってるってことだよ。
プランモード（shift-tabを2回押すやつ）が君が求めてるものかもしれないね。
≫新しいことだと実際にやってみないと全体像はつかめないって？そんなことないよ。未知のものをマッピングし、それぞれを知れるように計画するのが、アーキテクチャ設計者の最も重要な仕事さ。事前設計は全能の神が完璧なアーキテクチャを宣言するんじゃなくて、他のエンジニアリング作業と同じくリスク管理なんだよ。
よくわからないな。コーディングが劇的に速くなっても、全体的な生産性の向上は控えめになるのは、コード入力が仕事の大部分じゃないからってのは、両方のグラフと矛盾しないし、かなり分かりやすいと思うけど。LLMがドキュメント作成だけでなく、思考部分も加速させるってのが君の主張なの？
疑似コードって、表現豊かな人間言語よりもプロンプトに適してるんじゃないかなって時々思うんだ。構造に従えるし、表現力もあるけど制約されてるからね。これに関する研究とか、効果的なテクニックとして見たことある？
君が求めてるのは本当のAGI/ASIだよ。それはまた別のやっかいな問題で、存在論的な問題がたくさん付いてくるだろうね。
僕はLLMに高レベルな点を要約させて、ガイダンスとしてAGENTS.mdやCONVENTIONS.mdに追加するのを日常的にやってるよ。コンテキスト肥大化の制限はあるけど、セッション間で引き継ぐべき重要なことを維持させるのにかなり効果的だね。
≫未知のものをマッピングするのと≫全能の神の話じゃないってのが、自分の考えと大きく矛盾してるみたいだね。彼らが言うように…既知の既知、既知の未知、未知の未知があるってことだよ。
思考とコーディングを人工的に区別するのは好きじゃないな。密接に絡み合ってると思う。だからこそLLMが本当に気に入ってるんだ。複数のアプローチを試してどうなるかを見る苦痛を取り除いてくれるからね。コードを見て初めて、違うやり方にしたいって思うことがよくあるんだ。その反復時間を減らせるのが大きくて、やった”タイピング”を捨てたくないからって妥協するより、正しい設計にたどり着ける可能性が高くなるよ。
みんなに警告だよ。Claudeは「計画モード」でもファイル勝手に変えちゃうんだ。
「計画モードだから変えないで」って言ったら、めちゃくちゃ謝りながら変更を元に戻そうとして、かえって状況を悪くしたよ。僕の経験だと、計画モードってシステムプロンプトが変わるだけで、書き込みツールは無効にならないみたい。
まあ、二人とも正しいのかもしれないけどさ、なんか全然違うソフト開発プロジェクトや領域の話をしてるように聞こえるよ。
上司はAIが95%の仕事をすると考えてるけど、僕の経験では80/20ルールだよ。AIは80%をすぐやってくれるけど、最後の20%は人間じゃないと無理。今のAIは人間みたいにコードを書いて、シミュレータやFigmaのデザイン見てデバッグするみたいな反復作業ができないんだ。100年後にはできるかもね。今はまだ無理だよ（2025年9月28日時点）。
使うアプリによるよ。「RooCode」みたいなVSCodeの無料拡張機能は、いろんな「モード」があるんだ。
「Architect」LLMでプロジェクトの概要作って、「Coding」LLMでコード書いて、「Debugging」LLMでバグ直す、って感じ。
質問に答えるLLMもあるよ。CodingとDebuggingのLLMだけがコード書くけど、変更は全部承認制にできるよ。
もっとコメントを表示（2）
80/20には同意。ワークフローの面では、CopilotからCursor、Claude Codeまで、たった2年でめちゃくちゃ進歩してるよね。これは神秘的な線形代数の部分よりも、裏側の仕組みやI/Oの改善が大きいから、普通のソフト開発でも十分対応できる話だよ。
僕のAIの使い方もこれと一緒。最初の80%（いわば下書きみたいな感じ）をAIにやってもらって、そこから自分で仕上げてるよ。
記事が言いたいのって、Casey Muratoriの「学習ベースでプログラミングするならAIは無用」って話に似てるよね。個人的には、AIのコード生成は学ぶつもりのない使い捨てコードに一番使えると思う。学習を最大化するなら、AIにコードを生成させない方がいいってことかな。
「AI-Driven Engineering」が合う人もいるだろうけど、僕はAIに頼らず自分でコード書く方が楽しいし、結果的に続くんだよね。https://youtu.be/apREl0KmTdQ?t=4751
これって個人の好みだと思うんだ。僕はAIエージェントと一緒にコーディングすることで、ツールの使い方を効率的に学んでるよ。10年コードを書いてきたけど、AIアシストコーディングの方がもっと楽しいし。
それに、ビジネスとしては品質の高いアップデートを早く出すのが重要でしょ？ AIアシストコーディングを使えば、それがずっと速くできるって確信してるよ。
「AIがコード生成しない時に学習が最大化される」って意見、努力しないと学べないのは当然だけど、それって「誰とも話さず助け求めない時が一番学べる」って言うくらい、ちょっと極端すぎるんじゃないかな。
AIってさ、人間みたいに助けてくれないんだよな。俺のチームメイトは「努力の証拠を見せて」ってPRとかtypedefとか図とか求めるし、コードベースの経験があるから問題解決方法も知ってたりする。
でもAIは、何でもかんでも言われた通りにコード書くばっかりで、チームメイトみたいな洞察力は全くない。だからAIにはちゃんと「質問」できないって感じなんだ。ただコードを生成するだけだと、全然そこには到達しないね。
“LLMは高速なジュニアエンジニア”って意見、もう心底うんざりなんだよ。もし本当にそう思ってるなら、お前は最低なジュニアエンジニアとしか働いたことないか、ジュニアエンジニアと一緒に働いたことないかのどっちかだね。
LLMは学習しないし、質問もしないし、間違った方向に進んでるかどうかなんて考えないし、センスもないし、意見もないし、めちゃくちゃな論理でコード書くし、顧客にとって何がベストかなんて考えないし、お前がそのタスクのために明示的に与えたもの以外の文脈は一切持ってないし、他にもたくさんあるわ。
“LLMはセンスがない”
これがLLMの根本的な問題だと思うわ。
Claude Codeを使うようになってから、むしろ考える時間が増えたんだ。今までやらなかったような400〜600語の機能説明を書くようになったりしてね。
その思考は大きなトレードオフを生むけど…結果は早く良くなる一方で、コードの理解度は浅くなるんだ。
でもClaude Codeを使うと経験豊富な開発者の思考が減るって考えは、単純に間違いだよ。多くの人がエージェントを下手くそに使ってる可能性は高いけど、それは必ずしもエージェントのせいじゃない。
この記事が見落としてること:
1) コーディングって全部が同じじゃないんだ。本番システムで働いてる人もいれば、俺みたいに概念実証が必要な人もいる。
2) コーディングエージェントの使い方も人それぞれだ。
3) 開発者の時間、特に優秀な開発者の時間にはコストもかかるんだ。
AIアシストコーディングのトレードオフを、善悪の判断をせずに論じる記事を読みたいな。自分のアイデンティティがコードを書くことで成り立ってると、こういう客観的な話って本当に難しいけどね。
この記事、お前が言ってる最初のポイントはちゃんと触れてるぞ。
「庭師になる」ミームを思い出すよ。でも気持ちはわかる。今はゴールデンケージって感じだよね。すごく快適だけど、画面の前で人生を無駄にしてる気がするんだ。
AIは今、ジュニアコーダーを排除し、シニアコーダーを燃え尽きさせるために使われている印象だね。
そのうち燃え尽きるシニアがいなくなることに気づくんだろうけど、まだそこまでいってない感じ。
LLMが今のレベルで停滞すると考えるのはおかしくない？だって今までずっと改善され続けてるし。
数年前、Copilotが1行コードを補完するだけで画期的だったのを覚えてる？今は毎週新しいモデルが出てるし、オープンソースモデルも閉鎖的なモデルと遜色ないくらい進んでるよ。
＞ビジネスやコードベースの知識が不足しているって？じゃあ、AIにコンテキストを与えればいいじゃん。
僕はClineのMemory Bankアプローチを使ってるよ（https://docs.cline.bot/prompting/cline-memory-bank）。アーキテクチャやロードマップとかを含んでて、複雑なプロジェクトだとこれだけで30kトークンも使うんだ。コンテキストが多すぎるとモデルが悪くなることもあるけど、僕のコーディングスタイルやアーキテクチャの決定をかなり良く維持してくれるから、全体的に良いトレードオフだと思う。
あと、コード生成前にPlanモードを使って満足できるデザインにするのがおすすめだよ。
過去2ヶ月間Claude Codeを使ってるけど、ほとんどの時間をPlanモードで過ごしてるよ。良い計画を練るのに最高だね。良い計画があれば、実装はたいてい一発で決まるんだ。悪い計画だとダメだけどね。
あと、強力な型付けと厳格なコンパイラを持つ言語を使うのも大きいよ。Claudeにコンパイラやアナライザー、デバッガーを呼び出させると、既存のパターンに従わせることでコード品質を驚くほど維持できるんだ。
最近偶然わかったんだけど、Claudeは接続されたAndroidデバイスのadb/logcatを呼び出して、アプリ実行中の実際のデバッグログを取り込めるんだ。大量のログでも、まるで綿菓子みたいに処理して、人間が読むよりずっと早く実行時エラーを見つけてくれる。IDEやブレークポイントでは見つけほぼ不可能だったバグも、ログ出力から直接見つけてくれたよ。
全体的に記事は素晴らしいけど、僕らの働き方は今後根本的に変わると思うね。
いきなりコーディングするのはジュニアがやることだよね。Clineとか他のエージェントベースのワークフローのPlanモードを使うと、アウトプットが全然違うよ。
だけど、ClineのPlanモードはファイルを読まずにコンテキストだけで動くみたいで、僕にとっては信じられないし、そのせいで使い勝手が悪くなってるんだ。誰か理由を知ってる？
＞Planモードはアウトプットが全然違うって？同感だよ。
僕はツールに依存しないワークフローで、まずdocs/feature-plansフォルダに計画/仕様書を作るんだ。それを1つのチャットスレッドで作らせる。まず基本的な計画を作らせて、それから一緒に議論して、僕が間違った仮定を手動で修正する。そして新しいチャットで実装するんだ。実装の前後には、/gilfoyleコマンドで建設的なレビューを、/secコマンドで徹底的なセキュリティレビューを走らせる。これを実行したら、最終的なLLMの出力品質がすごく高くなったよ。
追記：”アプリで使われている既知のパターンを適用し、車輪の再発明はしないように”って指示を加えるのもすごく効果があったよ。
ファイルを読んで詳細な計画を作るにはActモードに切り替えろって言われたら、僕はやんわりと”Planモードでファイルを読んでくれ”って頼むんだ。毎回うまくいくよ。こんなことしなくて済めばいいのにね。
ClineのPlanモードはデフォルトではファイルを読まない傾向があるけど、”詳細な計画を立てるのに必要なファイルをすべて読んで”って指示すれば読ませられるよ。GPT5はもっと積極的にファイルを読みたがるみたいだね。
”@”記号でプロンプトにファイルを追加すればいいだけだよ。
