ハクソク

世界を動かす技術を、日本語で。

シニアエンジニア向けのLLMを活用したペアプログラミング

366日前原文(pmbanugo.me)

概要

  • LLM（大規模言語モデル） の活用は、エンジニアにとって 有望かつ課題も多い
  • シニアエンジニア による実践的なLLM利用法のブログ記事を紹介
  • ペアプログラミング や プロンプト管理 など、現場で役立つノウハウの共有
  • LLMの限界 や注意点についても冷静に解説
  • 参考リソース として、記事やテクニックをまとめて紹介

シニアエンジニアによるLLM活用の実践例

  • LLM（大規模言語モデル） は、コーディングやデバッグ支援として期待される一方、 時間の浪費 につながる場合も多い
  • シニアエンジニア がLLMとペアプログラミングを行うことで、 新たな可能性 を実感するケースが増加
  • 本記事は、 現場のシニア・スタッフエンジニア によるLLM活用の実例ブログをまとめたもの
  • バズワードや過剰な宣伝 を排除し、実践的な知見にフォーカス

Sean Goedecke: 実践的AIテクニック

  • 「セカンドオピニオン」テクニック と 「使い捨てデバッグスクリプト」テクニック の2つを紹介
    • セカンドオピニオン： LLMに意見を求めてコードや設計を再確認
    • 使い捨てデバッグスクリプト： 特定の問題に対して即席スクリプトをLLMで生成
  • LLMツール導入のコツ や、作業効率化のヒントも解説

Harper Reed: LLMコード生成ワークフロー

  • アイデア出し→共同設計→LLMによるコード生成→繰り返し というワークフロー
  • LLMでブレインストーミングと共同設計 を行い、実装前の段階でプロジェクトの見通しを立てる手法
  • プロトタイプや機能開発 での応用例
    • LLMの活用で、 工数やリソース不足 に早期気づくことも可能

Lee Boonstra: プロンプトのドキュメント化

  • LLM利用時のプロンプト記録 の重要性を強調
  • 効果的なプロンプト の保存・整理で、再利用性や品質向上を実現
  • 構造化されたプロンプト管理方法 のアイデアを提案

Seth Godin: ChatGPTの限界

  • LLMの知能過大評価 に警鐘を鳴らす短文エッセイ
  • Claude を例に、LLMを「 パターンやプロセスの自動化ツール」として活用する姿勢を推奨
  • 「まずAIに聞き、次に人間に相談」 というアプローチを紹介

まとめと参考リソース

  • 現場のエンジニア目線 でLLMの活用法や注意点を学べるリソース集
  • プロンプト管理やワークフロー設計 など、日常業務に応用可能なテクニックの紹介
  • 新たな記事やリソースの情報提供 も歓迎
  • Seth Godinの言葉 ：「行き詰まったら、まずClaudeに、次に人間に聞こう」という姿勢の提案

Hackerたちの意見

この1年間、コーディングにLLMを使って実験してきたけど、成功もあれば、フラストレーションもいっぱいあったよ。「AIがすべてを変える」みたいな投稿を書く代わりに、実際に何がうまくいくかを見つけた他のシニアエンジニアたちの実践的なインサイトを集めてみた。誇大広告なし、 trenchesでのリアルな体験だけ。

LLMを使ったペアプログラミング、シニア以上のエンジニア向け > [...] 他のシニアやスタッフ以上のエンジニアが自分の仕事でLLMを使っている様子を探るブログ記事のコレクションみたい。シニアエンジニア向けっぽいけど、リンク先の記事にはシニアエンジニア向けだとは書いてないし、全てのレベルのプログラマーが役立つと思うよ。LLMが役立つと思うならね。

└

そうだね、シニアエンジニアじゃない人は、文書化されたアプローチの価値を事前に理解できないだろうな。価値を事前に理解するには、シニアである必要がある。

LLMをちょっとした検索エンジンみたいに使ってる。グーグルで調べる代わりに、質問してる感じ。まあ、それにはそれなりにいいけど、当たり外れがあるね。しばしば出てくる結果はゴミみたいなもんだし、グーグル使った方がマシなことも多い。コードを生成するためにはあんまり使わなくて、もっと高レベルな質問をすることが多いかな。例えば、数学の公式が必要なときとか。

└

僕の最も一般的な使い方は似たようなもので、ちょっと不慣れな領域の問題に取り組んでいるときに、その「専門用語」を見つけることだね。完全に新しい概念を思いつく可能性は低いから、既存の知識の言語で質問を形成する手助けをしてもらうだけなんだ。

└

もう一歩進めて、検索機能（tavili、searxngなど）を流れに組み込むべきだよ。そうすれば、より良い結果が得られるし、ソースを洗練させて、信頼できるソースのスコア付きリストを徐々に構築できる。

この分野はめっちゃ早く進んでるから、2ヶ月前に自分のワークフローや回避策を書き留めてたら、今はほとんど役に立たないだろうな。これらの推奨事項には、説明されているモデルやハーネスを前面に出してリストアップする必要があると思う。

└

すごく重要なコメントだね。これらのツールの能力が向上してから、私のワークフローは劇的に変わった。

└

この分野はすごく速く動いているから、2ヶ月前に自分のワークフローや作業の工夫を書き留めていたら、今ではほとんどが古くなっているだろうね。しかも、これらのワークフローは誰も検証していないという問題もある。みんな自由にSNSや個人ブログで自分の「魔法の薬」を宣伝できるから、これらのワークフローが不十分だとわかった場合、感じる古さは自己宣伝以上の無効さかもしれない。

└

そうだよ。数ヶ月前にClaude 3.5が書いたコードを、今はClaude 4が修正してる。

ハーパー・リードのワークフロー（仕様をブレインストーミングして、計画を共同で立てて、LLMのコード生成を使って実行する）が今のベストプラクティスだと言っただろうけど、著者が「この技術を使って完全な機能やプロトタイプを構築するのには成功していない」と付け加えているのには驚いた。これが実際のバグを解決するためにBrokkを使ったこのパターンの一例だよ： https://www.youtube.com/watch?v=t_7MqowT638

└

あなたのツールのワークフローはよく示されてるけど、実際にバグを修正してマージされたPRにリンクしてたら、もっと説得力があったし、印象的だったと思うよ。

LLMにコードを生成させて、それをレビューして、エラーを修正して、完全に理解するために時間をかけるのが本当に効率的なの？この点について具体的な統計や指標があればいいのに。自分でコードを書くよりも、本当に効率的なのかな？それとも、LLMを使って調べたり、ソリューションをデモしたりする方がいいのかな？

└

そうだね、でも懐疑心のハードルはそれ以上だよ。だってLLMはコードをコンパイルしたり、エラーをキャッチしたり、テストを生成して実行したりするからね。コンパイルエラーやアサーション失敗は、LLMエージェントへのさらなるプロンプトに過ぎないんだ。

└

コードによるけど、たいていはそうだね。特定の結果にこだわらなければ、効率が上がるよ。2,000行未満の一回限りのツールで、結果を簡単に検証できるなら、なんでそれを生成して、もっと面白いことに時間を使わない理由があるの？

└

最近は、LLMに簡単な小作業をやらせながら、自分はもっと難しいタスクに取り組む機会を探してる。自分の実装を進めながら、LLMにも提案された解決策を考えてもらうことも試してみたよ。タスクが繰り返し作業を必要とする場合、LLMはかなり早くなることもあるしね。そういうタスクを認識したら、最初のバージョンをコーディングしてから、他の部分で繰り返す作業のパターンをLLMに従わせるようにしてる。

└

コードを読むのがどれだけ得意かによるね。もしそれが得意なら、LLMはすごい生産性の向上になるよ。

└

LLMにコードを生成させて、それをレビューしてエラーを直し、完全に理解するために時間をかけるのが本当に効率的なの？答えはいつも「状況次第」だよ。LLMが得意な単純作業もあって、ユニットテストやドキュメントの生成なんかはその一例。最初の試みはあまり良くないことが多いけど、何度も繰り返すのがすごく早いから、自分で書くのと同じくらいの時間で何度も再生成できる。どの範囲で作業しているかにもよるし、小さなイテレーションの方が大きな再設計よりも良い結果が出ることが多い。コンテキストも重要だよ。もしコードベースがきちんと整理されていて、クリーンなコードなら、LLMはより良い提案をしてくれる。逆に、コードベースがごちゃごちゃでスタイルがバラバラなスパゲッティコードなら、プロンプトも同じようなものを生成しがち。

└

(免責事項：このワークフローに基づいた製品を作って売ってる) もし正しいタスクを選べば、たいていそうなるよ（数週間ごとに新しいタスクが増えてるし）。単一のプロンプトからシンプルだけど完全に動作するアプリが得られるけど、具体的でないと品質はまちまちだね。コードベースができたら、エージェントの出力品質はアーキテクチャとテスト次第。スケーラブルなアーキテクチャがあって、関心事がきちんと分離されていて、良い統合テストハーネスと例があって、良いドキュメント（機能、スタック、手順、設計制約）があれば、欲しい変更を正確に得るのは、自分が何を求めているかをどれだけ上手く伝えられるかの問題だよ。もう一つ注意点、開発環境はエージェントをサポートしなきゃね。人間と同じように、エージェントはコンパイラのフィードバックと相性が良く、テストツールやドキュメント/インターネットアクセスがあればさらに良い（そう、私のエージェントにはこれらがある）。私はCheepCodeを使って自分の開発を進めてるけど、まだテストライブラリやプレビュー環境を整えていて、ローカルでプルダウンして実行していない非自明なPRをマージするリスクを減らしているところ。自分が作っている他のアプリにも使っていて、そっちはもっと自己完結していてテストが簡単だから、そっちの方がずっと良い結果が出てる。自分が求めることを説明するのにあまり労力をかけたくないなら、AIとチャットしてチケットを生成してみて。それをLinearに貼り付けて、CheepCodeエージェントに処理させればいい。もっと簡単にできるツールを開発中だけど、ブートストラップした創業者として一度にいくつもの場所にいるのは難しいんだよね。

└

書く必要があるコードのブロックを特定できて、それが比較的簡単に定義できて、正しく書かれているかをレビュー/検証するのも簡単だけど、実際に書くのは面倒な場合、LLMは新しい親友だよ。他の人がどう考えているかはわからないけど、私のテーブルにはそういうのがたくさんあるみたい。LLMにアウトソースするのが難しいのは、これらの簡単なブロックをどうつなげるかだけど、幸いなことに、それがコーディングの中で楽しい部分だから、退屈な単純なものを書くのはあまり好きじゃないんだ。

└

LLMは人間よりちょっと早くタイプする傾向があるから… そうだね、ストレートなコードならそうかも。

└

よくボイラープレートの面倒な部分を組み立てるのに使ってる。例えば、新しいテストファイルを追加してビルドルールを全部設定してから、テストx,y,zを実装するとか。こないだはAngularアプリで入力フォームを作る必要があって、欲しい7、8個のフィールドを頼んだら、全部やってくれて、テンプレートとTypeScriptも繋げてくれた。そういうことを数秒でやってくれるから、15〜20分くらいは節約できるけど、自分がやらなくて済む精神的な楽さがすごくいいんだ。もう一つは、メソッドシグネチャを正しい型や変換、キャストを使って書き出すこと。自分で調べるのが面倒なときに、「ここにfooって名前のメソッドを作って、Barのインスタンスを受け取ってBazに変換する。戻り値の型はQuuxにして、最終的に返す前にBazから新しいQuuxインスタンスに変換する。ビルダーパターンを使って、blah.tsの定数マジックストリングをQuuxの適切な列挙値にマッピングする」みたいに書くんだ。これも大きな時間の節約にはならないけど、精神的に楽になって、細かいことより問題に集中できるようになる。

└

多くの場合、そうだね。多くの場合、そうじゃない。全体的には、扱える以上のことを与えて自分でやる羽目になったときの時間の無駄を考慮しても、かなりの時間を節約できるよ。

僕の主な感想は、概念的な境界を設けて、理由を考えられる範囲で使う限りは素晴らしいってことかな。例えば、APIを教えている単一のシステムコンポーネントみたいにね。そうすれば、構築される各部分について理解が持てるんだ。広げすぎると間違いを犯し始めて、メンタルモデルを失っちゃうんだよね。

└

うまく言ったね。それが僕の課題でもあるんだ - コードベース全体のメンタルモデルを失うこと。LLMを使って節約した時間を、メンタルモデルを再構築するのに戻してる気がすることもあるよ。

これらは、ピアプログラミングがただの雰囲気コーディングを上回るという全体的なアイデア以上の有用な洞察を提供しているとは思わない。私が見つけたこのアイデアを活かすための最良の構造はBMADと呼ばれ、LLMをまるで一つの開発チームのように扱い、完全にコントロールできる形でオーケストレーションするものだよ。 https://youtu.be/E_QJ8j74U_0 https://github.com/bmadcode/BMAD-METHOD

└

UI開発のための高次元なコーディング手法って感じだね。これって、非ウェブ/UI開発にも使えるの？

俺は日常の仕事で「防御的」なC#コードをたくさん書いてる。将来的に経験の浅い人やオフショアの人が触ることを想定してて、4ヶ月後にプロジェクトから離れた後にレビューすることになるからね。これを「企業コーディング」って呼んでる。守らなきゃいけないインターフェースがたくさんあって、IoCやインジェクション、うざいくらい強いパターンがある。脱線するのが大変になるようにしてる — コードレビューで目立つようにね。でも、重要なロジックは少数の大きなファイルに集中させてるから、抽象化を掘り下げるのが簡単で、新人でも理解しやすいんだ。防御的コーディングアプローチとLLMを使って、特定のプロジェクトやフォルダーにスコープを絞りたいな。フロントエンド、バックエンド、データベースを一度に知る必要はないでしょ？もちろん、混乱しちゃうよね。最近はLLMにコインと予算を与える実験もしてる。「xをするのに10コイン使えるよ。m,n,oをすればコインをもらえて、j,k,lをするとコインを失う」って感じで、無駄が減って簡潔さが増したよ。LLMが「終わったよ、ボス。2コイン残ってるけど、もっとコインを稼ぐにはどうすればいい？」って聞いてきたこともあった。選択肢を考えてるモデルを観察するのが楽しい。「これをやるとこれがかかるから、代わりに1行のコードでこれをやった方が3コイン稼げるかも！」ってね。

記事では https://www.seangoedecke.com/practical-ai-techniques に言及していて、そこにはこう書いてある: > AIは非常に短いプログラムを書くのが得意で、特に10〜30行のシンプルでほぼ動くコードをどのエンジニアよりも早く生成できる。 > これをどう活用する？普通のソフトウェアエンジニアの日常では、この種のプログラムの需要はあまりない。通常、コードは大きなプログラムの修正か、時々短い生産データスクリプト（データのバックフィルなど）で、正確さがスピードよりも重要になることが多い。技術的には正しいかもしれないけど — スタンドアロンの小さなプログラムの需要は少ない — 重要な現実を見落としている。大きなワークフロー内での小さなコードセグメントの需要は膨大なんだ。ソフトウェア開発（私の経験では）は、小さなユニットを組み合わせることを中心に構築されている — ヘルパー、グルーコード、入力バリデーション、テストケース、設定ラッパーなど。これらはスタンドアロンのプログラムではないけど、常に書かれている。そして、まさにLLMが最も効果的な10〜30行のタスクなんだ。大きなタスクをAI支援のマイクロタスクに分解できるエンジニアは、より速く動ける。開発者を置き換えることではなく、彼らを強化することが目的なんだ。