生成AIコーディングツールとエージェントは私には合わない

343日前原文(blog.miguelgrinberg.com)

概要

Generative AIツールによるコーディング経験を技術的観点から共有
AIツールは私の作業速度や生産性を向上させない主張
コード品質や責任問題に対する懸念の強調
人間によるコードとAI生成コードの違いについて説明
AIツールとインターンの違いに関する考察

Generative AIツールによるコーディング体験とその評価

Generative AIツール の利用に関する質問が多いため、見解を文章化
本記事は AI推進派でも反対派でもない 立場からの個人的経験の共有
AIに関する賛否両論の記事は既に多く、重複を避けたい意図
技術的観点を重視した 中立的な体験談 の提示

AIは作業速度を上げない理由

GenAIツール は私の作業速度向上に寄与しない実感
AIによるコード生成は便利に見えるが、 最終的な責任は自分 にある
AI生成コードの徹底的なレビュー が必須で、これには多くの時間がかかる
コードレビューは 自分で書くのと同等かそれ以上の労力 が必要
Joel Spolskyの「 読む方が書くより難しい」という業界の格言の引用
AIをブラックボックスとして扱い、 レビューを省略するのは危険 との認識
契約や法的責任 が絡む場合、品質やリスク管理が特に重要
品質低下やリスク増大を容認しない 限り、AIで効率化は不可能

AIは「生産性の掛け算」にはならない理由

GenAIツールが「 生産性の掛け算」と主張する人もいるが、 客観的なデータはない
レビューを省略することで効率化しているだけとの見解
新しい言語や技術の習得 もAIに任せず、自分で学ぶことを重視
学習自体がエンジニアの醍醐味 であり、AIに委ねるつもりはない
AI活用による時短は 責任問題や品質維持の観点から成立しない

AI生成コードと人間のコードの違い

オープンソースの 人間による貢献 も厳密にレビューしており、時間短縮にはならない
人間とのやり取りから得られる 新しい発想や共同作業の価値 を重視
AIエージェントによる大量PR生成は コスト増加や手間増大 につながる懸念
AI生成の低品質なPR が増加し、「不気味の谷」的な違和感を感じることも
提出者に 説明責任を求めても反応が薄い ケースが多い

AIとインターンの違い

AIツールを「 インターン」のように扱うべきという意見への反論
インターンは 成長し学習する が、AIは毎回リセットされる
インターンへの指導は 将来的な投資 となるが、AIにはその効果がない
知識の蓄積や自律的成長 ができない点でAIはインターンとは異なる

結論

GenAIツールのコーディング活用には 技術的な課題と責任問題 が伴う
AIで効率化・生産性向上を謳う人は、 品質基準の緩和 や 自己利益 が動機である場合も
AIによる「ただ乗り」的な恩恵は存在しない との立場
記事を読んでくれた方への感謝と、 Buy me a coffee による支援の呼びかけ

Hackerたちの意見

自分が書いてないコードをレビューするのにかかる時間は、自分でコードを書くのと同じくらい、もしくはそれ以上かかることが多い。Claude Codeをよく使っている者として、これには同意する。LLMは素晴らしいけど、彼らにコントロールを譲るほど、実際にコードを出すのに時間がかかる気がする。今のところ、私にとっての主な利点はRSIの症状が軽減されたことだけど、実際の時間の節約は大げさに言われてることが多い（その瞬間は早く感じるけどね）。

└

誰かクールなハイブリッドインターフェース作ってる人いる？実を言うと、全部を会話形式の英語でやりたいわけじゃないんだよね。

└

ここには、自分で書いたコードは著者とは違うコンテキストからレビューされる必要がないという暗黙の前提がある。古い表現に「自分の仕事がサイコパスに読まれることを想定してコードを書け」というのがあって、その後に「彼らがあなたの住んでる場所を知ってるのは、未来のあなただから」ってジョークがある。生成AIコーディングは、ずっと持っておくべきマインドセットを強制するんだ。受け入れ基準から始めて、正しさを厳密に検証する方法を考える（理想的にはコードレビューよりも回帰テストを通じて）、そしてレビューのプロセスを使って一貫したプラクティスを考え出す（それを文書化してLLMが参照できるようにする）。必ずしも早くなるわけじゃないけど、朝起きて、すでに複数のLLMにレビューされた、しっかり文書化されたPRを見て、成功したテストがついてるのを見ると、ずっと集中すべきことに時間を使ってる気がする。

└

コードをレビューしなきゃいけないの？正直に言うと、OPが考えてるように、私はしばしばざっとレビューするだけなんだ。でも、仕様書を書くために使わせることもある（私が掘り下げたものに関しては、かなり良いものが多い）し、結果はいつも慎重にレビューしてテストしてる。プロジェクトには、全くレビューしてない非AIコードもたくさんある、つまり、インストールした無数のオープンソースライブラリとかね。

└

RSIの症状は、起きてる時も寝てる時もずっと腕を温かく保つことで解決したよ。もしかしたら、あなたにも効果があるかも？

└

問題をデバッグするのにはいつもClaude Codeを使ってる。AIが数分で直せるのに、自分でやろうとする意味がないよ（最初にテストを書けば簡単に確認できるし）。o3の新しい検索機能は、私が非常に効率的にやっても少なくとも30分かかることを5分でやってくれる。何を言おうと、時間の節約は本物だよ。

ある程度、従来のコーディングとAIコーディングは同じじゃないから、どちらかが得意な人がいるのは驚くことじゃない。著者は基本的に、自分はAIコーディングよりもコーディングの方がずっと得意だと言ってる。でも、AIコーディングも自分で磨けるスキルだってことを理解するのが大事だよ。単に「最高のツールを選んで放っておく」ってわけじゃない。プロンプトの管理やコンテキストの管理は、意外と多くの人が思ってる以上にスキルが必要なんだ。手動コーディングが好きかもしれないけど、AIコーディングが苦手なだけかもしれないし、上達すれば好きになるかもしれない。とはいえ、AIにソフトウェアの大部分を任せることにはまだ懐疑的なんだ。実際にそれがうまくいくって言ってる人にも会ったけどね。今は「AIに大部分の雑務をやらせて、管理や高レベルのソフトウェアデザインをしっかりやる」方がいいと思ってる。ちょっと絵を描くのと写真撮影の違いみたいなもので、その視点で見ると、多くの絵描きが写真を好まない理由がわかる。

└

手動コーディングが好きかもしれないけど、AIコーディングが苦手なだけかもしれないし、上達すれば好きになるかもしれない。でも、どれくらいの時間を費やせば「上手くなる」って言えるの？無料トライアルやちょっとしたお金を使った感じだと、ROIが見合ってるとは思えない。

└

でも、AIコーディングは自分で身につけられるスキルだってことを理解するのが大事だよ。単に一番いいツールを選んで放っておくってわけじゃない。プロンプトの管理やコンテキストの管理は、みんなが思ってるよりもずっと高いスキルが求められるんだ。いや、そんなことないよ。数分（もしくはもうちょっと時間がかかるかもしれないけど、主に設定に時間を使う場合）で習得できることなんだから。GDBやUNIXをIDEとして使うみたいに、本を一冊読まないと始められないってことはないんだ。 > ちょっと絵を描くことと写真を撮ることに似てるかも。そういう視点で見ると、絵を描く人が写真を好まない理由が明らかになる。構図やポーズなど、共通する原則はたくさんあるけど、出力が違うから別の活動なんだよね。誰も二つを混同しないし、絵を描いてるときに「瞬間を捉えよう」とは思わない。意図は世界に観察を共有することなんだ。

└

スキルの上限は「高い」かもしれないけど、ピアニストになるために何年も練習するのとは違うよね。世界で最も経験豊富なAIコーダーでも、こういうやり方での実践は約3年くらいで、その多くはモデルが変わったせいで役に立たなくなってる。何十年も経験のある先生もいないしね。

└

でも、それは学ぶ価値のあるスキルなのかな？出力の質はどれくらい向上するの？今日のモデルやツール、そして未来のものにどれだけ移転可能なの？今のAIプログラミングツールを見る限り、開発されるスキルが、来年には見られるツールに移転するとは思えないな。

└

「ある程度、従来のコーディングとAIコーディングは同じではない。LLMベースのコーディングは、単純な自動補完の強化を超えて、ジュニアを管理するか、仕事を外注するのに近い。定義やプロンプトを与え、いくつかの作業が行われ、プロンプトを洗練させて繰り返す（または自分で問題を修正する）、外部の人間と同じように。」主な違いは、ターンアラウンドタイム（LLMに有利）、信頼性（人間に有利だけど、迅速なターンアラウンドでかなり緩和される）、そして（これは時間が経てば解消されると思うけど、そんなに時間はかからないかも）「大きな絵」の仕事に対する有用性の欠如だね。これが私が使うことに対する（いくつかの）反対理由の一つだ。私は自分がやっていることの細かい部分を理解したいし、プログラミングやデータベースのいじり、インフラの構築が楽しかったからやってた。何年も人を管理するのを避けてきたのも、同じ理由で給料が減るのを知ってたからだ。私は tinkerer でありたいのであって、 tinkerer のマネージャーにはなりたくない。AGIができたら、一緒に働けるように呼んでね。 -------- [1] そう、私はこれらのことをAIと呼ぶのにはちょっと頑固なんだ。次の10年で、これらは一般的にAIとは見なされなくなると思う。何かがAIと呼ばれるのは、それがAGIに近づいたときだけだよ。

でもインターンは時間が経つにつれて学び、成長する。コードをレビューしたりインターンにフィードバックを提供する時間は無駄じゃなくて、未来への投資なんだ。インターンはあなたが共有する知識を吸収して、後で与えられる新しいタスクに活かす。この点が、ジュニアやインターンとの比較で混乱するところなんだ。人間はビジネスやコード、システムの歴史について学ぶ。そして、成長する。もちろん、エージェントがそれをできる世界もあるし、いくつかのREADMEやドキュメントのソリューションはそれをやってるけど、制限はまだ大きいし、ビジネスコンテキストを再説明するのに多くの時間がかかる。

└

ビジネスコンテキストはシステムプロンプトに入れておいてね。

└

これが特定のLLMが14kのシステムプロンプトを持つ理由だと思う。

└

ビジネスコンテキストを再説明する必要はないよ。重要ならmdcファイルに保存しておいて。次にそのコードを見る本物の人もそれを使って学べるっていう追加の利点があるんだ。今や良い最新のドキュメントを持つことが資産になってるのは実際にクールだよ。

いい記事だね。自分でコードを書かないと、無意識が働いてくれる感覚を逃しちゃうんだよね。コードを書くことには、問題の強力なメンタルモデルを育てるという副次的な利点があって、それが神経に埋め込まれて、トラブルシューティングや新機能の統合を決めるときに役立つんだ。寝てる間に問題を解決してる自分に気づくこともあるよ。私が働いてきた組織では、LLM以前の時代と比べて、ソフトウェア開発者がほんの少しでも生産性を上げているのを見たことがない。人々は問題を解決するために脳のエネルギーを使わなくて済むことに依存し始めていて、それを生産性だと勘違いしてると思う。

└

人々は問題を解決するために脳のエネルギーを使わなくなることに中毒になっていて、それを生産性と勘違いしていると思う。それを言うのは本当にエレガントな表現だね。Google Researchは2024年にLLMの生産性への影響を測ろうとしたんだ。彼らは被験者に試験を与えて、異なるリソース（本とLLM）を割り当てた。結果、LLMを使った人たちは本を使った人たちよりも実際に終わるのに時間がかかり、しかもその分野の初心者だけがLLMを使ったときにスコアが向上した。だけど、参加者は自分たちがLLMを使うことでより正確で効率的だと感じていたけど、それは実際にはそうではなかった。研究者たちは「認知負荷の軽減」に起因していると提案した。LLMに何かを尋ねるのは簡単で、ほとんど受動的だから。本を探すのはアクティブで、もっと疲れる感じがする。君が言ったように、人々は問題を解決するために脳のエネルギーを使わなくなることに中毒になっていて、それを生産性と勘違いしているんだ。

実は、生成系AIにはあまり期待してないんだけど、それでもボイラープレートを書くのがAIを使うと「N」倍速いって認めざるを得ない（好きなNを使って）。証拠もなしにこういうことを言う人が嫌いだから、今日実際にChatGPTに頼んでみたんだ。「このセクションに基づいて、Reactコンテキストのスタブを書いて」って。// いろいろなこと うまくいったよ。いくつかのファイル（フック、プロバイダーコンポーネントなど）を作成してくれて、それをプロジェクトに追加したんだ。これを何度もやってきたけど、もうやりたくないし、面白くもない。もしメモリから間違ったら調べ直さなきゃいけないし（たぶん間違えると思うし、プロバイダーやコンテキストのボイラープレートは最悪だから）。今は、すべてのコンポーネントでconst myModal = useModal(...)って書くだけで済む。いいね。これで少なくとも30分は節約できたし、30分の時間は月に20ドル以上の価値があるよ。（注：このボイラープレートはReactがひどいせいかもしれないけど、それは別の話。）

└

こういうのが俺のメインの使い方なんだよね、テンプレ的なやつ。あんまり気にしないスクリプト、例えば一回限りのタスクをやるためのクイックなbashスクリプトとか。もっと難しい問題になると、俺の経験上、うまくいかないことが多いけど、他の人みたいにLLMスキルをあんまり磨いてないからな。プロジェクトが大きくなればなるほど、他のものと統合されるから、AIのパフォーマンスが悪くなる気がする。それに、そういうタスクは俺たち人間がやるのが大事だと思う。なぜなら、(a) 問題を考えるときにエッジケースを考慮するから、(b) システムについて深く理解できるから。

今のところ、生成AIコーディングツールは仕事の簡単な部分を早くするだけで、難しい部分には役立ってないと思う。実際、逆に難しくしてるかもしれない。コーディング自体はそんなに時間がかからないし、助けは必要ないんだ。私のコーディングの出力を100倍速くしても、全体の生産性には大きな変化はないから、そこを最適化する気にもならない。

└

あなたは配管工ですか？

AIエージェントが自分のワークスタイルに合わないって言う人がいても全然構わないし、反論するつもりもないけど、ちょっと指摘したいことがある。著者は「コードのレビューは実際にはほとんどの人が思っているよりも難しい。自分が書いてないコードをレビューするのに、書くのと同じくらいの時間がかかる」と書いてる。それは俺にとっても真実に近いと思うし、何年もコードをじっくり読んでたからね（セキュリティ脆弱性のために）。でも、AI生成のコードを扱うときは、単純で退屈なタスクに関しては、そんなに細かくコードを読む必要はないってことを知っておくのが大事だよ。少なくとも、同じレベルで責任を持つ必要はない。ちょっと待って、俺を攻撃する前に。現代のLinuxカーネルは、eBPFを介してほぼ任意のコードをランタイムで注入できるんだ（eBPFは、架空の仮想RISCにコンパイルされたCプログラム）。カーネルは、これらのプログラムがカーネルをクラッシュさせないようにほぼ確実に保つことができる。その理由は、停止問題を解決したからではなく、eBPFがほとんどのプログラムを許可しないからなんだ。例えば、プログラム内の逆方向の分岐が有限かつ小さな回数だけ実行されることが静的に簡単に判断できる必要がある。eBPFはその条件が成り立つかどうかを判断するのが得意ではない。確信のあるCFGのパターンを知っていて、それに合わないものは拒否するだけなんだ。少なくとも最初は、エージェント生成のコードをそういう風にレビューすべきだよ。人間のセキュリティ監査人のようにではなく、eBPFの検証者のようにね。エージェントの出力をレビューする際に、まばたきする必要があるなら、そのPRは却下するよ。もし君が、これまでレビューしたすべてのコードが同じくらい難しいと言いたいなら、それは認めるけど、俺にとってはそうじゃない。実際、慣用的なGo関数の単純な暗唱を見て「うん、これがそうだよね」って言うのはすごく簡単なんだ。

└

コードを読むのは書くよりずっと早いよ。これがGen AIの決定的なラインかもしれないね。コードを読むのが早い人はそれを便利だと感じるし、書くのが読むより早い人は使わないだろうね。

└

俺の挑戦は、「もしそれが慣用的なGo関数の単純な暗唱だったら、それを書く価値があったのか？」ってことなんだ。ある種のスタイル、例えば、再利用が難しいコードを促すプログラミングスタイルがあって、それは退屈で面倒で、維持が不可能で、特に価値がないんだ。「単純なコード」は、おそらく「プレーンテキスト」に近い形で簡潔に表現できたはずだけど、もっと厳密に、過剰に高価で無駄な、潜在的に危険なモデルを介さずにね。そう、eBPFの検証者のような厳格なルールに従って、無駄を排除する必要があるけど、それがすべてをeBPFで書くべきだということにはならないし、何かが「ゴミ」を排出できるからといって、それが良いモデルだというわけでもない。言い換えれば、それがそんなに単純なら、そもそもAIを使う必要もなかったし、数個のよくテストされたライブラリコールで十分だったんじゃないかな。

└

基本的に、PRはエンジニアを信頼して承認してるよ。千行のPRに対しては、どの100〜300行をじっくり見なきゃいけないか、なんとなく分かるようになった。もちろん、痛い目にあったこともあるけど、99%の確率で適切なテストカバレッジがあれば問題ないし、時間（お金）の節約もすごいよ。「出荷しよう！」って感じ。

└

これは過激だけど、健全なやり方だね。明らかに間違ってるなら拒否。明らかに正しいなら受け入れる。それ以外の場合は、非明白だから拒否。宣伝されているユースケースからはかなり離れている気がする。あと、この場合はLLMによる自動補完があった方がいいと思う。

└

エージェントが生成したコードを、人間が生成したコードと違ってレビューする理由は何なの？

「生成AIは、自分があまり慣れていない言語や技術でコードを書く必要があるときに役立つという一般的な意見を聞いたことがある。私にはこれもあまり意味がわからない。これがどういうことなのか、よくわからない。新しい技術を学ぶとき、ほとんどいつも質問が出てくる。昔はそれをググってた。答えが見つからなかったら、Stack Overflowに投稿してみたりもした。質問を打っているうちに、検索が働いて似たような質問を見つけてくれることもあった。別の時は質問を投稿して、もし閉じられなければ数時間や数日後に答えがもらえることもあった。今はChatGPTやGeminiに聞くだけで、ほとんどの場合答えが返ってくる。それだけで、他のこと（エージェントモード、AIによる編集やファイル生成）なしでも、私の生産性は上がってる。答えを得るのが10倍早くなった。これが学びにどう関係するのかはわからないけど、答えを得ること自体が学びだから、どこから答えが来ても関係ないよ。」

└

さらに、別の経験を追加すると、あまり慣れていないAPIを使ってたんだ。プログラムがクラッシュして、スタックトレースを見ても理由がわからなかった。もしこのAPIに何ヶ月も経験があれば明らかだったかもしれないけど、私には全然わからなかった。面白半分でスタックトレースをGeminiにコピー＆ペーストしてみた。C++の約60フレーム分。使っているAPIを考慮して、すぐに可能性のある原因を指摘してくれた。AIからそのヒントをもらったおかげで、2行の変更でバグを修正できた。それはかなり便利だと思う。もしそうでなければ、どれくらい時間がかかったかわからないし、さっきも言ったように、そのAPIにはあまり詳しくないからね。

└

小さなボイラープレートユーティリティには完璧だよ。ブラウザ拡張やTampermonkeyスクリプトが必要なとき、ドキュメントを読んだりマニフェストを書いたりせずにすぐに立ち上げられる。これらは小さなプロジェクトで、AIがなければ始めることすら考えなかっただろうな。少なくとも、AIは簡単なコードロジックの自動補完や、コードや設定をコピーして小さな変更を加えるときに自動で置き換えを見つけるのに非常に役立つ。

└

つまり、AIは基本的に検索エンジンとして最適ってことだね。

└

それに、ChatGPTはあなたの質問を答えなしで閉じることはないよ。なぜなら、（間違って）13年前の別の質問の重複だと思ってるから。

└

ChatGPTやGeminiは、StackOverflowを読んだからこそ答えを知っているだけだよね。Stack Overflowは訪問者がいるから存在してる。みんながAIツールを使って質問に答えるようになったら、どうなると思う？また百科事典の時代に戻るんじゃないかな。中央集権的な権威が、大金をかけて情報を手動で集めて出版してた時代に。そんで、その情報を私たちに売る方法を見つけるのに時間をかけてた。それは公平だったよね、だって彼らはその情報をまとめるのに時間をかけてたから。インターネットがそのビジネスモデルを壊しちゃったし、ある意味AIの「革命」はそれを取り戻そうとしてる。あと、彼は特にコーディングツールにコードを書かせることについて話してるだけで、AIツールを使って質問に答えることについては言ってないからね。これらは別のことだし、彼はそれを別々に扱ってるんだ。

毎日AIを使ってるよ、今はClaude Code、Gemini、Cursorにお金を払ってる。個人の遊びプロジェクトにはすごく役立ってるし、POCを動かしてアイデアを検証するのがめっちゃ得意。うちの会社は最初はまあまあの内部モデルしかなかったけど、今年の初めにやっとみんなにCopilotを使えるようにしてくれた。最初はすごくワクワクしたけど、仕事には全然役立たない。大きな古い企業プロジェクトには全く合わないんだ。企業環境では、いろんな要素が絡み合ってて、知識もバラバラだし、内部用語も多いし。もしかしたら将来的には、もっといいMCPサーバーとかがあれば、すべてのコンテキストを与えて役立つものを出せるかもしれないけど、今は仕事ではAIを検索エンジンとして使ってる（それは結構得意だよ、微妙な問題を見抜く知識があればね）。

└

大きな企業のコードベース（ドキュメントにも適用可能）にとって、最初のステップはそれを一つにまとめて、微調整することだと思う。

「速くなったり生産性が上がったりするって言ってる人は、そういう利益を得るために意識的に品質基準を緩めてると思う。」うん、まさにその通りだね。ただ、正直言うと、AIが自分よりずっと良いコードを書いてくれるから、レビューで直す必要がほとんどないんだ。だから、そんなに徹底的に見る必要もない。AIは面倒なエッジケースも考慮してくれるし、私がずぼらにやってるところでベストプラクティスを適用してくれる。

ハクソク