- 筆者は、AIツールでは自分の作業が速くならないことを最大の理由として、生成AIコーディングツールを使っていない
- AIが生成したコードは、レビューして理解するための時間が自分で書くより長くかかることがあると考えている
- コードの品質と責任は依然として開発者本人にあるため、レビューなしでAIコードを使うのは危険
- AIをインターンのように見ればよいという主張に対し、AIは学習できないので記憶喪失のあるインターンのようなものだと批判
- オープンソース貢献とAIコードの違いを説明し、人との相互作用は新しいアイデアをもたらす点で価値があると述べる
序論
- 多くの人が筆者に、生成AIコーディングツールを使っているか、どう考えているかをよく尋ねる
- 本文では賛成・反対の立場を離れ、個人的な技術的経験だけを整理する
- AIが自分のコーディングに役立たない理由を技術的観点から説明する
AIは速くない
- 生成AIコーディングツールを使っても、自分の作業速度は速くならない
- AIがコードを書いてくれても、コードの責任は自分にあるため、コード全体を丁寧にレビューして完全に理解してからでなければプロジェクトに反映できない
- コードレビューはコードを書くのと同じくらい時間と集中力を要し、「コードを読むのは書くより難しい」という業界の格言もある
- AIが書いたコードを「ブラックボックス」のように信頼するのは非常に無責任な選択である。コードの欠陥が発生した場合、法的・金銭的責任もプログラマにある
- 品質低下やリスク増大なしに、AIで生産性向上や収益増加を実現することはできない
AIはレバレッジツールではない
- 生成AIコーディングツールが効率を何倍にもしてくれると主張する人もいるが、それは主観的な印象にすぎない
- 一部の利用者は、AIが生成したコードをレビューなしで使うか、部分的なレビューだけで時間を節約するが、筆者にはその過程を省けないため役に立たない
- 新しい言語や技術の学習でAIを使うのが効率的だという主張にも同意しない。新しいことを学ぶ過程そのものがプログラミングの楽しさだからだ
- 実際にRust、Go、TypeScriptなどさまざまな言語を自分で学んでおり、そうした経験をAIに委ねない
- すべてのコードに対する責任感は結局自分にあるからだ
AIコードは人間のコードと違う
- 「オープンソースへの貢献も自分が書いていないコードなのに、なぜAIコードとは違って扱うのか？」という質問をよく受ける
- 実際にはオープンソースのPRにも時間をかけて徹底的にレビューする。しかし、ユーザーとの協業は新しいアイデアや動機づけにつながる
- 複数のAIエージェントを動かしてバグ修正Issue向けのPRを受け取ることがゲームチェンジャーだという主張もあるが、結局コードレビューのボトルネックは人間なので、むしろ遅くなる
- AIツールの普及によって品質の低いPRが頻繁に生成されるようになった。AIコードには微妙な違和感があり、PRの提出者に質問しても答えないことが多い
- 責任あるコード貢献とオープンソースコミュニティとの対話が、人間のコードの重要な差別化要素である
AIとインターンの違い
- AIをインターンにたとえる主張もあるが、根本的に異なる
- インターンの初期のコードには多くのレビューと時間が必要だが、フィードバックを通じて急速に成長する
- インターンへの成長投資は、やがて独立して任せられる重要な仲間へとつながる
- AIツールは新しい作業のたびに知識を忘れて最初からやり直し、成長したりノウハウを蓄積したりできない
- これは一度も成長しないインターンのようなもので、生産性向上に貢献できない
結論
- この記事を通じて、生成AIコーディングツールを適用する際の技術的な問題点を明確に伝えようとしている
- AIコーディングに**「ただ飯」は存在しない**
- AIによって速くなったり生産性が上がったりしたという主張は、品質基準を下げて追加リスクを引き受けているか、AI販売者の利益から生じている
- プログラマは常に最終責任者であることを忘れてはならない
5件のコメント
copilot（claud）+ codex（o3/4o/codex-miniの3モデル同時mcp）のagentモードに完全に定着しましたが、これを使う人やプロジェクトの性質によって、効果は千差万別だと思います。
私は5〜6個のワークスペースで同時に作業を走らせ、完了した順に確認していますが、オープンソースコードの内部まで見て検証する作業をモデルが全部やってくれるので、かなり良いと感じています。昼休みに作業を投げておくと、1つか2つは終わっています。たまに一晩中進むこともありますが、copilot rate limitというものがブラックボックスなので……
高性能カーネルやcall stack全体の単純化、readabilityの確保のように、人間にとってはコンテキストスイッチが多くて時間のかかるタスクも、プロンプトと目標さえ適切に与えればこなしてくれます（人間より多くのコードをメモリに載せられるので）。こういうコードでパッチをレビューするのは簡単ですし…… さらに、APIの使い方のミスやオープンソースプロジェクト自体のバグによって発生する障害を経験したことがある人にとっては、Agentに確実に検証させるのはメンタル面でも良いと思います……
ただし、あくまで使う開発者がそのパッチを理解できなければなりません。そして、プロンプトを投げられなければならないでしょう。経験から素早く問題を定義して投げられてこそ、そこから始められるわけですから。数式なしに高性能カーネル開発が不可能なのと同じです。問題がchip/osレベルなのか、アプリケーションレベルなのか、remote resourceの問題なのかの見当をつけるのは、まだシニアの役割だと思います。
Copilot、ChatGPT系、Cursorなどをある程度使ってみた立場からすると、開発ツールのテンプレートやスニペット程度の役割にはよく合いますが、agentやcoworkerほどではありません。
Cursor を使っています。
chat モードでは agent より ask を好みますが、やはり確認したうえで自分のコードに適用してほしいからであり、全体的に本文で述べられているような欠点には同感です。
それでも生成 AI は今後も使い続けるつもりです。自分では思いつかなかったアイデアやコードを生成してくれることも多いため、参考目的としては十分に価値があると判断しているからです。
個人的な経験としては、生成系コーディングツールの使用について感じた点とかなり近いです。
Hacker Newsの意見
新しい言語や技術を学ぶたびに疑問が生じる人もいて、以前は Google 検索や Stack Overflow に質問を投稿して返答を待っていたが、今は ChatGPT や Gemini にすぐ尋ねられ、はるかに速く回答を得られるため生産性が大きく向上している。このように質問への迅速な回答を得るだけでも学習プロセスが速くなる点を強調したい
ChatGPT や Gemini が正解を提示できる根拠は、Stack Overflow を含むウェブ上にすでに存在していた知識を学習しているからである。すべての利用者が AI だけを使って質問するようになれば、最終的には信頼できる公開知識の源泉が枯渇する可能性がある。これは百科事典の時代、つまり高コストで情報を収集・販売していた時代の復活に似ている。また、筆者が批判しているのはコードを直接書いてくれる AI コーディングツールであり、質問に答えるツールとは区別して説明すべきである
以前、使い慣れていない API を使っていてプログラムがクラッシュしたことがあった。スタックトレースを Gemini に入れてみたところ、すぐに原因の手がかりが得られ、2 行だけ修正して問題を解決した。こうした経験を見るだけでも AI の価値は実感できる。慣れていない分野でつまらないミスのせいで長く迷わずに済む点が大きな利点である
検索はますますブログスパムを優先するようになっているが、それよりもしっかりした公式ドキュメントやユーザーガイドで根本から学ぶほうが教育的である。良い API ドキュメントを読んでいると、全体設計や追加機能まで自然に学べる。ブログの例やチュートリアルでは目先の問題は解けても、本当の実力向上には役立たない。宿題を代わりに解いてくれるだけなので、ChatGPT が真の自己学習を促進するとは思わない
難しい問題では、必ず AI の結果を検証する過程が必要である。AI の自動補完機能を切っている理由も、実際には効率がそれほど高くなく、むしろ不要な修正が多かったからだ。不思議なことに、完全なオフラインのローカルモデルだけでもかなりの参考資料を得られる。Google 内蔵の Gemini の結果も品質はいまひとつだ。私が主に懸念しているのは、人々が AI だけを使って情報を得るようになると、Stack Overflow のような本物の知識保存庫が消えるかもしれないという点である
小さなボイラープレート用のツールには AI が完璧である。ブラウザー拡張や Tampermonkey スクリプトのような簡単なものなら、ほとんどドキュメントを見ずにすぐ作業を始められる。複雑でないコード補完や些細な修正にも AI はかなり有用だ。普段なら始めることすらなかったような小さなプロジェクトを素早く処理できる
直接コードを書くことで得られる潜在的な利点は、問題に対する強力なメンタルモデルを脳内に残せる点である。後で問題解決や新機能の統合をするとき、この「無意識的」な学習効果が非常に大きく働く。自分の手で直接やってみた記憶が積み重なってこそ、本当の実力が向上する。私が見てきた組織では、LLM 導入後も生産性で実質的な倍増は経験していない。単に脳をあまり使わず、楽な道だけを探すことを勘違いしているのではないかと思う
人々が脳のエネルギーをあまり使わずに問題を解くことに慣れ、その錯覚があたかも生産性であるかのように感じる現象を非常によく要約していると思う。Google Research が 2024 年に LLM の生産性効果を実験した結果、書籍で学習した集団よりも LLM 使用集団のほうがむしろ時間が長くかかり、内容に習熟した人ではなく初心者だけが点数を少し上げた。しかし多くの参加者は自分がより速く正確だと錯覚しており、研究者たちはその理由を「認知負荷の減少」だと解釈した。関連論文リンク https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
脳のエネルギーをあまり使わずにより長く働けるなら、実際により多くの仕事量をこなせるのではないか。現在でも高難度の仕事は 3〜4 時間が限界だ。歩く速度でマラソンを走れるなら、結果として総出力が増えるという見方である
伝統的なコーディングと AI コーディングは互いに別個のスキルだという点に同意する。私自身も AI がコーディングを代替するという主張には非常に懐疑的である。しかし、プロンプト管理やコンテキスト維持のような「AI コーディング」自体にもかなりの習熟曲線が存在すると見ており、この点で多くの人がその価値を過小評価していると思う。まるで手描きの絵と写真撮影のように、そもそも追求する目的自体が異なるかもしれないという見方である。私が好むやり方は「AI が大変な作業を処理し、私は全体設計と調整を担当すること」である
LLM ベースのコーディングは単なる自動補完以上の作業、つまりタスク定義→フィードバック→反復を繰り返しながら外注する体験に近い。違いは処理速度（LLM が優位）と信頼性（人間が優位）だが、長期的にはこの境界も次第に薄れていきそうだ。重要なのは、私は本質的に作業の細部を自分で扱いたいタイプだということだ。インフラとプログラミングを学び、掘り下げるのが好きで始めた仕事なので、管理者役を避け、収入が少なくなっても自分で作る仕事にこだわっている。いっそ AGI が同僚になれるレベルになったら、また関心を持つだろう。AI という名称自体も今後はそれほど特別視されなくなる可能性が高い
AI コーディングの学習曲線が思ったより大きいとしても、何年も投資しなければならないピアノとは違う。現存する最も熟練した AI コーダーたちでもせいぜい 3 年ほどの経験しかなく、モデルも継続的に変わるので、過去の経験が現世代モデルには合わない部分も多い。師匠から学ぶ構造がない点も限界である
AI コーディングスキルは果たして長期的に価値があるのか。現在の AI ツールのスキルセットが未来世代にどれだけ移転されるかには懐疑的である。目先の効率が上がっても、モデルやツールが変われば無用の長物になる可能性を念頭に置くべきだ
AI コーディングの習熟は数分か、せいぜい 1 時間もあれば十分だと思う。比喩的に言えば GDB や UNIX のように一冊ずつ掘り下げる分野ではないと感じる。絵画と写真も根本原理や目標がまったく違うため混同しないように、AI コーディングも従来のコーディングとは完全に異なる活動である
直接コーディングを好むのは、単に AI コーディングの腕が足りないからだと見るその自信には同意できない。これまで少額課金や無料トライアルを使ってみた ROI だけでも十分に判断できる
実際には AI コードレビューや結果の検証の代わりに、AI が生成したコードをそのまま PR に上げ、レビューを他人に押し付ける文化が生まれている。こうした状況では GenAI が本当に有用というより、仕事を先送りするために使われる副作用のほうが大きい
私もこういう経験をした。管理者の能力が低いと、誰が実質的な価値を生み出しているかを見分けられない。私はコーディングエージェントから本当に多くの価値を得ているが、能力のない組織が雑な成果物に報酬を与える構造は深刻な問題だと思う
提出される PR が継続して AI の出力そのままなら、フィードバックを蓄積したうえでチームリーダーが必ず問題提起すべきだという立場である
Claude Code をよく使う立場として、他人が書いたコードをレビューするとき、直接書くのと時間差がほとんどないという主張に 100% 同意する。LLM はそれなりに使えるが、コントロールを渡せば渡すほど、実際のリリースまではむしろ時間がかかる。RSI 症状の緩和には良かったが、時間節約効果は思った以上に誇張されることが多かった
コードを本当にレビューしなければならないのかという質問を受けて、普通私は主に AI の成果物をスポットレビューするだけで、仕様文書は AI に書かせ、その後で私が最終レビューとテストを入念に行う。実際、大半のオープンソースライブラリのコードは最初から直接レビューしたりもしない
ここには「自分で直接書いたコードは別の視点でレビューする必要がない」という前提がある。実際には未来の自分も潜在的なコード読者である。AI コーディングはこうしたマインドセットを強制する。つまり、明確な受け入れ基準を立て、テストと一貫したルールで検証していく構造である。結果として、より堅牢で記録の残る開発文化を促す
Claude Code でのバグデバッグは「先にテストを書けば」AI が数分で直すのが日常である。新しい検索機能の導入後は複雑な作業も 5 分で処理可能になり、この点での時間節約は体感として非常に明確だ
RSI 症状の解決法として、常に腕を温かく保つ方法も勧めたい
「すべてを対話型インターフェースで処理したいわけではないが、ハイブリッド方式の UI を導入した事例はあるか」という疑問の提起
Generative AI コーディングツールは仕事の簡単な部分だけを速くし、むしろ難しい部分はさらに難しくする。実際、コーディングそのものにかかる時間はそれほど大きくないので、その部分だけが 100 倍速くなっても全体の生産性は大して変わらない。だからそこにわざわざ時間を使いたくない
すでに特定のスタックと問題領域を知り尽くしたエンジニアなら、そもそもどんなツールも必要なく、学習も不要である。しかしこの論理は現実的には意味がない。結局ツール選択は個人最適化である
私は AI にアルゴリズム作成、コードの原因説明、API 呼び出し、特定関数の実装などをさせている。完全なコード全体ではなくても、デバッガーと一緒に活用することが徐々に増えている
もしかして配管工なのか、という冗談交じりの質問
筆者が「コードを直接書くのと同じくらい、あるいはそれ以上に他人が書いたコードのレビューにも時間がかかることがある」と述べた点は、セキュリティ監査のような精密なコードレビュー経験がある私にも共感できる。しかし AI がごく単純なルーチン作業に特化するなら、コードを具体的に細かく見る必要はなく、eBPF verifier のような包括的な検証だけで十分かもしれない。あまりに複雑な問題があれば、そのまま PR を却下する。単純で反復的なコードには、人間が細かく監修する必要も少ない
しかし、これが本当に効率的な方法なのかは疑問である。何十もの PR を開いて 1 つだけ通すくらいなら、むしろ同僚のコードのほうがはるかに信頼できる。時間と金銭、環境資源の浪費を招くだけの構造は望ましくないと思う
本当に「反復的な Go 関数」なら、そのコードをわざわざ書く価値があったのか疑問である。非効率で再利用性の低いコード、ただありふれたライブラリを 1、2 行書けば済むようなことを、わざわざ AI で作る理由を感じない
コードを読む速さが書く速さより速い人には GenAI が有用で、逆に書くほうが速い人はあまり使う必要がない
なぜ AI が書いたコードを人間が書いたコードと違う形で検証しなければならないのか、という疑問の提起
反復的で単純な作業なら IDE のテンプレートバインディングや変数自動補完機能でも十分にカバーでき、この方法は無料だという点を強調する
インターンと AI コーディング補助ツールの比較では、インターンは実際のコード、ビジネス、システム履歴を学ぶが、AI には繰り返し文脈を説明しなければならず、こうした限界は依然として残っている
重要な文脈を mdc ファイルに保存しておけば、次の担当者もその情報を参照でき、むしろドキュメント化と知識の持続性が良くなるという見方
一部の LLM では、このようにしてシステムプロンプトが 14k もの長さになる原因になる
インターンは本当に CARE（気にかける）してくれることが多い
重要なビジネス文脈をそのままシステムプロンプトに入れる方法も可能である
現在の AI モデルは本質的に既存データのパターンだけを学習している。成功事例のテンプレートを組み合わせているのであって、根本から新しい解法を導く構造ではない。問題を見ると最も似た経験から答えを探そうとし、最初から原理的にアプローチしない。人間の専門家は First-principles（AI が苦手とする根本原理からの論理的アプローチ）に習熟している。AI は類似性を優先して型にはまった解決策を出し、とくに革新が必要な領域や慣習が通用しない問題では限界が目立つ。コンテキスト汚染（context poisoning）にも人間のほうがはるかに効率よく対応する
私は AI の生成コード分野にはあまり期待していない立場だが、反復的で退屈なボイラープレート作業は AI のほうが N 倍（体感では非常に大きな値）速い。実体験として、ChatGPT に React Context ベースのモーダル構成例を投げたところ、フック、プロバイダーなど一連の構造をすぐ出してくれた。その場で 30 分ほど節約でき、このような反復作業に月 20 ドルはまったく高くない
こういう場合はライブラリのドキュメント例を持ってきて使うことも多く、5 分あれば自分で最低限必要な基本実装を終えられることもある。しかし生成コードは主に現状に合わせた全体解法を出してくるため、その後の段階的な構造改善やリファクタリングではかえって不便が多い
私も主にボイラープレートや ad-hoc スクリプトに AI を使う。複雑な実問題はまだ AI に全面的に任せにくいと思う。特にシステムの深部まで入り込む問題は人が直接扱い、その過程で得られる洞察が重要である。AI はプロジェクトが大きくなるほど、統合された要素が多くなるほど限界が大きくなると感じる