Gemini 2.5 PROのような最先端LLMは、幅広いトピックに関する膨大な知識と、数千行のコードを数秒で把握する能力によって、プログラマーの能力を拡張し、増幅してくれる。問題を明確に記述でき、LLMと協働するために必要なやり取りをいとわなければ、例えば次のような驚くべき成果を得られる。

1. ユーザーの手に渡る前に、自分が埋め込んだバグを潰すこと。RedisのVector Setsの実装で私はこれを経験した。いずれにせよ最終的にはすべてのバグを潰すことになっただろうが、その多くはGeminiやClaudeによるコードレビューで即座に取り除かれた。
2. あるアイデアが実際にどう機能するかをより速く検証すること。LLMに使い捨てのコードを書かせて、ある解決策が本当に高性能なのか、十分に良いのかなどを、できるだけ早くテストして確かめられる。
3. ペアデザインに取り組むこと。そこではあなたの直感や経験、デザインのセンスを、LLMにエンコードされた博士レベルの知識と混ぜ合わせることができる。このプロセスでLLMは時に愚かな道を提案し、時に信じられないほど優れたアイデアを出してくる。人間であるあなたがそこにいるのは、局所最適や間違いから抜け出し、あなたのデジタルな友人がどんな人間よりも多岐にわたる事柄を知っているという事実を活用するためだ。
4. 明確な仕様のもとでコードの一部を書かせることで、作業を加速すること。
5. 自分の専門から遠いが隣接する技術（例えば、Amigaのデモを68000アセンブリで書くようなこと）を扱うこと。自分に欠けている知識について、LLMを心の特定の部分の拡張として使うのだ。

1年半ほど前、私は「LLMs and programming in the first days of 2024」というブログ記事を書いた。そこではすでにLLMが有用だと述べていたが、この1年半のあいだに彼らが遂げた進歩は、状況を完全に一変させた。ただし、その能力を活かすためには、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が最良とは限らない。コーディングは主に次の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を最良の形、すなわちコントロールを保ったまま使おう。ただし、もう一つのリスクもある。思想的あるいは心理的な拒絶感からLLMを避け、不利を積み重ねてしまうことだ（そしてLLMと働くために必要な、言葉では説明しがたい大きなスキルセットを身につけ損なうことでもある）。これはまさに「In medio stat virtus（徳は中庸にあり）」というケースなのかもしれない。