Gemini 2.5 PROのような最先端のLLMは、幅広い分野について膨大な知識を持ち、数千行のコードも数秒で把握できます。そのため、プログラマーの能力を拡張し、さらに高めることが可能です。問題を明確に説明でき、LLMと協働するために必要なやり取りを受け入れられるなら、次のような驚くべき成果に到達できます。

1. 自分のコードに持ち込んだバグが、ユーザーの目に触れる前に取り除かれる。RedisのVector Sets実装で、私はこれを経験しました。最終的にはすべてのバグを自分で取り除けたでしょうが、その多くはGeminiやClaudeによるコードレビューですぐに見つかり、除去されました。
2. LLMに使い捨てのコードを書かせて、できるだけ早く試すことで、あるアイデアが実際により高い性能を発揮するのか、十分な品質なのか、といったことを素早く検証できる。
3. 自分の直感や経験、設計センスと、LLMに蓄積された博士課程レベルの知識を組み合わせて、ペア設計に取り組める。この活動では、LLMが愚かな道筋を提案することもあれば、非常に鋭いアイデアを出すこともあります。人間である自分の役割は、局所最適やミスから抜け出し、どんな人間よりも多くの、しかも多様な事柄を知っているデジタルな友人の力を活用することです。
4. 明確な仕様を与えて、コードの一部を書かせることで作業を加速できる。
5. 自分の専門からは遠くても、自分ができることに隣接した技術を、LLMを自分の知識不足を補う思考の拡張として使いながら扱える。たとえば、Amigaのデモのために68000アセンブリでコーディングする、といったことです。

1年半前、私は「2024年初頭のLLMとプログラミング」というブログ記事を書きました。その時点でもLLMはすでに有用だと感じていましたが、この1年半のあいだにLLMが遂げた進歩によって、状況は完全に変わりました。ただし、その能力を引き出すには、LLMと対話する人間が一定の資質を備え、いくつかの実践に従う必要があります。ここではそれを見ていきます。

たいていの場合、バイブコーディングは避ける

現在の歴史的な転換点において、LLMは優れた増幅器ではありますが、何でも一人でこなす作業者としては優れていません。テストや数百行程度の小さなユーティリティなど、LLMにコードをすべて書かせる意味のある、小規模な使い捨てプロジェクトは今でもあります。しかしLLMは、コードベースの一部をうまく書けますし（後述するように、厳密な監督下で）、開発を大幅に高速化できます（あるいは、以前と同じ時間で、より多く、より良いものを開発できるということです。私が実際にしているのはこちらです）。一方で、重要な目標を任せきりにすると、必要以上に大きく、複雑で、局所最適の選択に満ち、さまざまな面で最適とはいえない、壊れやすいコードベースを作りがちです。さらに、取り組む課題が一定の複雑さを超えると、完全に失敗してしまいます。明日にはすべて変わっているかもしれませんが、LLMと日々コードを書いてきた現在の実感から言えば、最高品質の仕事に到達する方法は、人間とLLMの組み合わせです。人間とLLMが組めば、人間だけより生産的になれると私は考えています。ただし、そこには大きな「もし」があります。その人間が、LLMとの対話に長け、LLMを使った経験を十分に持っていることです。効率よく意思疎通する能力は、LLMを使ううえで決定的な要素です。

大きなコンテキストを与える

LLMとコードの実装や修正について推論したいなら、LLMに広範な情報を与える必要があります。論文、対象となるコードベースの大部分（可能ならコードベース全体。ただし、コンテキストウィンドウが大きくなりすぎてLLMの性能が落ちる場合を除きます）、そして何をすべきかについて自分が理解していることをすべて書き出したものです。このブレインダンプには、特に次の内容を含めるべきです。

• 一見よさそうに見えるが、実は悪い解決策についてのヒントと、それがなぜ最適でない可能性があるのか。
• 人間の側でまだ完全に練り上げられていなくても、非常に有望な解決策についてのヒント。LLMはそれを利用して正しい道筋を見つけられることが多いからです。
• 何を実現すべきか、必要な不変条件、さらにはコードのスタイルについての明確な目標。たとえば、LLMは不要な依存関係だらけのPythonコードを書きがちですが、プロンプトでこの問題を減らせることがあります。私の経験では、Cコードのほうがかなりよい傾向があります。

あまり普及しておらず、自明でもない特定の技術を扱う場合は、ドキュメントもコンテキストウィンドウに追加するとよいでしょう。たとえばVector Setsのテストを書くとき、これは新しすぎてLLMがまだ知らないRedisのデータ型なので、READMEファイルをコンテキストに加えます。このような単純な工夫だけで、LLMはすぐにエキスパートレベルでVector Setsを扱えるようになります。

適切なLLMを使う

最も有名なLLMが最良とは限りません。コーディングには主に次のモデルを使うべきです。

• Gemini 2.5 PRO
• Claude Opus 4

私の経験では、Gemini 2.5 PROのほうが意味理解の能力に優れています。より複雑なバグを見つけ、より複雑な問題について推論できます。Claude Opusは、新しいコードを書く場面ではより優れていることがあります（そうでないこともあります）。ユーザーインターフェースもより快適です。また一般に、複雑な問題では、設計空間についての人間の理解を広げるために、少なくとも2つのLLMとやり取りする必要があります。1つだけ選べるなら、Gemini 2.5 PROを選んでください。

使うLLMについての基本的な要件は、エージェントや、コーディングエージェントを統合したエディターのようなものを使わないことです。次のことを実現したいからです。

• 常に、最も能力の高いモデル、つまり最先端のLLMそのものにものを見せる。
• コードやコンテキストの一部しかLLMに見せないRAGを避ける。これはLLMの性能を損ないます。返答を生成する際にLLMが何を見られるかは、自分で完全に管理しなければなりません。
• ターミナルからLLMのウェブインターフェースへコードを手作業で移し、常にループの一部であり続ける。そうすれば、プロセスのすべてに自分が関与できます。自分がコーダーであり続けながら、能力を拡張できるのです。

結論

単独でコーディングできるエージェントに大きな関心が集まっていますが、現時点でソフトウェア開発者としての影響力を最大化するには、LLMを明示的に使い、ループに残り続けることです。AIが進歩すれば、これは必然的に変わっていくでしょう。そして最終的には、多くのコーディング作業をAIだけに任せたほうがよくなるはずです。その未来においても、人間が何を、どう実現するかを決めることは、依然として重要です。しかし、私たちはまだそこには到達していません。まさに今この瞬間は、自分が主導権を握ることで、必要なときには最小限に、必要に応じて複雑なアイデアを使いながら、可能な限り研ぎ澄まされたコードをLLMに作らせることができます。

そうでなければ自分の知識や専門性の境界にあるようなことにも取り組め、その過程で多くを学べます（そう、LLMから学ぶことはできます。本や同僚から学べるのと同じで、教育の一つの形であり、新しい形なのです）。しかも、生成されるものはすべて自分のコードとプロダクトに対する考えに沿ったものになります。品質も高く、LLMが持ち込んだエラーや欠点のせいで、予測不能な失敗をすることもありません。書いたコード全体と、その設計についての深い理解も保てます。

ときどき、エージェントに何ができるのかを試してみるのは賢明です。しかし、エージェントには自分ほどうまくできないと感じるたびに、ターミナルに戻り、AIの助けを借りてコードを書きましょう（AIが成果を高められると感じるときに。自分だけでやったほうがよい場合もあります）。エージェントが素晴らしい仕事をするようになったら、私は真っ先に乗り換えます。そして、情熱のためだけに自分でコーディングを続けるでしょう。しかし今は、誇大な期待には乗らず、AIを最も有効な形で使いましょう。つまり、主導権を手放さないことです。ただし、別の危険もあります。イデオロギーや心理的な拒否感からLLMを避け、LLMと働くために必要な、説明するのが難しい幅広いスキル群を身につけられないまま、不利を積み重ねてしまうことです。もしかすると、まさに「中庸にこそ徳あり」ということなのかもしれません。