「谈谈 AI 编程工具的进化与 Vibe Coding」（おおよそ「AI プログラミングツールの進化とバイブコーディングについて」の意）は、2025 年 8 月 28 日に guangzhengli.com で公開された個人ブログ記事である。著者は、2023 年に GitHub Copilot を使い始め、2024 年からは Cursor を継続的に使い、執筆前の数か月間は Claude Code を多用していたと述べている。その著者が論じるのは、バイブコーディング が AI でコードを書くあらゆるやり方のラベルになってしまっており、それをめぐる現在の議論の多くは 2 つの異なる実践を区別していないことから生じている、ということである。
記事は「バイブコーディング」という語を、記事が引用する Andrej Karpathy の投稿の意味にとどめる。記事はその投稿を 4 つの点として読んでいる。コードが存在することを忘れること、小さなエラーでさえ手ではなく AI を通じて直すこと、AI が書いたものをもはやレビューせず結果だけで判断すること、そして使い捨てのプロジェクトならそれも悪くなく、かなり楽しいと受け入れることである。AI 支援プログラミング一般については コンテキストコーディング という名前を提案し、記事の大部分をその実践に費やして、よく知られたコーディングツールの歴史を コンテキストエンジニアリング の歴史として読み解いている。
要点
- 著者は、AI 支援プログラミングの名前としてバイブコーディングよりも「コンテキストコーディング」のほうがふさわしいと提案する。その背景にあるのは、モデルを固定すれば、AI 支援プログラミングのあらゆる改善は、チャット、RAG、ルール、MCP のいずれを通じてであれ、より適切なコンテキストを LLM に渡すことにかかっているという見方である。
- GitHub Copilot の初期の成功は、エディタで開いているウィンドウ内のコードとカーソル周辺のコードという、コードのコンテキストを LLM のために集めた最初のツールだったことによるとされる。著者が振り返る当初の限界は、コードについてまだ幻覚の多いモデル（当時は GPT-3.5）、小さなコンテキスト、コードを直接編集できないこと、そして開いているファイル以外は見えないことだった。
- Cursor は、RAG によってプロジェクトのコードベース全体を意味（ベクトル）検索用にインデックス化したことと、ユーザーが自らファイルやフォルダーをコンテキストに添付できるようにしたことが評価されている。著者は、このより充実し、よりユーザーが制御できるコンテキストこそが、Cursor が Copilot を追い抜いた理由だと読んでいる。
- Claude Code は、モデルに惜しみなくコンテキストを与えるものとして描かれる。まずコードベースの構造と技術スタックを分析し、次に RAG ではなく grep、find、git、cat といった Unix ツールでコードを取得する。著者の経験では、小規模・中規模のタスクでは両ツールは同程度だが、10 を超えるファイルにまたがる大規模なタスクでは Claude Code のほうがはるかに優れている。著者はその理由を、モデル提供者である Anthropic はトークンの消費量について制約が少ないことに求めている。
- 著者は RAG 対 grep の論争の双方に一理あるとし、本格的な AI IDE はいずれ両方の検索方式を備えるようになると予測する。一方で、Claude Code や Gemini CLI のようなターミナルツールは RAG を採用する必要はないと論じる。その強みは、コードベース、MCP、CI/CD パイプラインと統合できるスクリプト化可能なワークフローにもあるからである。
- 著者自身の実践から引き出された実用的な助言として、新しいチームメンバーが必要とするもの、すなわち技術スタック、ディレクトリ構造、ファイルの命名とその用途、install、lint、test、build といったよく使うコマンドを、GitHub Copilot の
.github/copilot-instructions.mdや Claude Code のCLAUDE.mdのような指示ファイルに書いてモデルに与えることが挙げられている。著者は、そうしたコンテキストは多ければ多いほど良いわけではないと警告する。ディレクトリ構成や頻繁にリファクタリングされるユーティリティのように、ファイルが更新されないまま古くなる情報は、書かずにおくよりも害が大きいという。 - 複雑なタスクについては、モデルに作業をサブタスクに分割させてドキュメントに記録させ、1 つ終わるたびにそのドキュメントを更新させ、小さなステップでコミットし、最後にドキュメントを削除するというやり方を著者は提案しており、これによって幻覚が大幅に減ると報告している。
- 記事が勧めるほかのコンテキスト源は、context7 のような MCP サーバーを通じて渡す最新のドキュメントと、デバッガーで入出力を見る代わりとして、不具合のあるコードの随所にモデルにログ出力を追加させることである。また、Claude Code の組み込みの
/contextコマンドを特に取り上げている。これは、コンテキストウィンドウのうち各種類の内容がどれだけを占め、どれだけが残っているかを示すもので、著者が見た中で初めてコンテキストの使用状況をユーザーに示したツールだという。 - 著者自身の実践はエージェント一辺倒ではなく、併用である。本格的なエンジニアリング作業で著者が最もよく使うのは Cursor の Tab 補完で、レイヤー構成や抽象化は手で書き、コードは補完に埋めさせている。著者の経験では、LLM は依然として抽象化が苦手だからである。
- 本来の意味でのバイブコーディングについて、記事は、プログラミング経験のない人にとっては短期的には欠陥やセキュリティ脆弱性を、長期的には保守できないコードと技術的負債をもたらすと論じる。借金について説明する前に子どもにクレジットカードを渡すようなものだという比喩を借り、さらに、完全にバイブコーディングで作った製品を発表した投稿が注目を集めた数日後に、その製品を閉鎖することになった X ユーザーの例を紹介している。製品は攻撃を受け、API キーの使用量が上限に達し、何者かにサブスクリプションを回避されたという。
- キャリアについて、著者は悲観的な見方を示す。ほとんどのプログラマーは自然言語の要件をコードに翻訳する翻訳者として働いており、LLM はますますその役割を担えるようになっていて、平均的なプログラマーの数は減っていく。一方で、AI のレバレッジによって独立系開発者や小規模チームはより一般的になるという。
背景
この記事は一人の実践者の意見であり、何らかの計測ではなく、記事が取り上げる 3 つのツールを著者自身が使った経験に基づいている。著者も、急いで書いたもので個人的な見解に満ちていると述べている。Cursor のインデックス化の仕組みについての説明は著者自身の言葉による簡単なものであり、記事の参考文献リストにはコードベースのインデックス化に関する Cursor のセキュリティページが含まれている。命名については、記事はコンテキストコーディングを、AI 支援プログラミングを指す名前としてバイブコーディングよりふさわしいと考える複数の候補の 1 つとして示しており、ほかの候補として AI 支援プログラミング、AI Coding、Agents Coding を挙げたうえで、個人的にはコンテキストコーディングを好むと述べている。バイブコーディングの境界がどこにあるかを論じた別の文章については、AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） を参照。