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

2025年5月24日原文(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にリンクしてたら、もっと説得力があったし、印象的だったと思うよ。

Hacker Newsで議論の続きを見る

ハクソク