- LLMについて、ソフトウェアエンジニアの立場は大きく二つに分かれる
- 一方では、業界を揺るがす革新的な技術だと信じられている
- 他方では、単なる誇張された蜃気楼にすぎないという見方もある
- 筆者は個人的にLLMを有用に使えていると感じており、それを効果的に活用する方法を紹介している
本番コードの作成
- コードを書くときは、Copilotの自動補完機能を常に活用している
- 自動補完の提案の多くは、関数の引数や型入力などの反復的なボイラープレートに当たる
- 主な業務領域（例: Ruby on Rails）では、自分で直接書くコードのほうが優れていると判断している
- 業務上の専門性が低い領域では、Copilotが提案するロジックをより多く受け入れる
- 例: GolangやCのような言語で、小さな戦術的変更をしなければならないとき
- あまり慣れていない言語の文法や慣用的なコードスタイルを、Copilotの助けで素早く把握する
- 専門知識が不足しているため、必ずその分野の専門家にレビューしてもらうようにしている
- こうすることで「賢いインターン」程度の水準である程度の作業は可能になるが、検証プロセスを通すことが不可欠である
使い捨てコードの作成
- 本番にデプロイしない使い捨てコードを書くときは、LLMをはるかに積極的に活用する
- 研究用途で一度だけ実行して捨てるコードは、保守の必要性が低い
- 例: APIから公開データを取得して分類し、正規表現を適用して簡単に検証してみる作業
- この場合、LLMによって2〜4倍は速く進められたとしている
- 一度使って捨てるコードの作成には、LLMは非常に効率的である
新しい領域の学習
- 最も効果の高い活用例として、LLMをオンデマンドの家庭教師のように使う方法を挙げている
- 例: Unityを初めて学ぶとき、ChatGPT-4oのようなモデルに質問を投げ続ける
- 「Xはどう動きますか？」だけでなく、「XはYとどのような関係がありますか？」のような追質問もできる
- 「自分が理解した内容は合っていますか？」のように、理解内容を確認してもらう用途にも使う
- 学習の過程で書いたノートをそのままコピー＆ペーストして、レビューしてもらう形でも使っている
- ハルシネーションへの懸念
- GPT-3.5以降は、全体としてハルシネーションが大きく目立つとは感じていない
- 日常的に学ぼうとする領域のほとんどがすでによく確立された分野なので、誤答のリスクは低かった
- これまでLLMを通じて誤った情報を学んでしまったことはなかった
最後のバグ修正
- 完全に行き詰まったときは、CopilotやClaudeなどにファイル全体とエラーメッセージを見せて助けを求める
- ほとんどの場合、LLMは混乱して適切な解決策を提示できない
- それでも、ときどき見落としていた部分をLLMが指摘してくれて、時間を節約できたことが何度かあった
- 性能は期待するほど高くないため、何度も試すことはせず、一度くらいだけ尋ねる
誤字脱字と論理ミスの修正
- 文章（ADR、技術要約、社内文書など）をLLMに全面的に代筆させることはしない
- 自分のほうがより明確に書けると判断しており、LLM特有の文体も好まない
- 文法チェックや誤字脱字の修正のために、草稿をLLMに入力してフィードバックを受けることはある
- LLMはスペルミスをよく見つけてくれ、ときには興味深い観点を提案してくれることもある
- 何度も修正提案を受けるのではなく、一度だけ「大枠」でのフィードバックを確認する
要約
- LLMの活用範囲
- Copilotを使った「スマートな自動補完」
- よく分からない領域での短い戦術的変更（専門家レビュー必須）
- 一度使って捨てる研究用コードの作成
- 新しい技術やドメインを学ぶときに絶えず質問すること
- 行き詰まったときに最後の手段としてバグ解決を試みること
- 英語文書の草稿に対する全体的なスペルミス・誤字脱字・論理エラーの修正
- まだLLMを使っていない部分
- 自分がよく知っている領域で、Pull Request全体の作成を代行させること
- ADRのような技術文書を丸ごと作成すること
- 大規模コードベース内部の複雑なアーキテクチャ把握
6件のコメント
これが…スタッフエンジニア…？
GitHubのスタッフエンジニアですね
私もこれがスタッフエンジニア級に見えるわけではないですね……単にアシスタントレベルが妥当なのではないかと思います。
タイトルに誤訳がありますね。"staff engineerのように"ではなく、"staff engineerとして"です。
👍!!
Hacker Newsの意見
「staff engineer」として見ると、LLMは慣用的なコードを書いたり教えたりするのが非常に苦手で、むしろコードレビューにより多くの時間を費やすことになる。LLMを使ってコードを書くのは、悪い慣行を学び、コード量やボイラープレート、不確定な結果への依存を招く危険がある。LLMはアイデア出しや信頼できない情報の探索には役立つかもしれないが、コード生成に依存するのは狂気じみている。
バグ修正時にCopilotを使い、ファイル全体を添付してエラーメッセージを貼り付け、助けを求める方法がある。「reasoning」モデルはこれよりはるかに良い結果を出し、コードベース全体を貼り付けてエラーメッセージを説明すると、しばしば問題の根本原因を見つけ出す。
LLMはボイラープレートコードや自動補完には有用だが、複雑な作業には限界がある。ビジネスロジックを理解していないからだ。ただし、企業向けドキュメントを素早く作成するには非常に有用である。
GitHubで働き、Copilotに直接関わった経験がある。
静的型付け言語と優れたIDEを使っている場合、「smart auto complete」機能の有用性は低くなるかもしれない。Intellijの自動補完は、ほとんどの場合こちらの考えを読んでいるように感じられる。
ソフトウェアエンジニアがLLMに対して否定的な感情を抱く理由についての省察。多くの人は絶対的な基準で判断しがちで、それがツールを効果的に活用する能力を制限している。
Pythonプロジェクトの保守にAIを使う方法。他の言語でのやり方をPythonに変換するのに役立つ。
ChatGPTを使ってユーティリティコードを書く体験は良かった。コードレビューではしばしば些細な問題を指摘されるが、改善点を見つけるという点では依然として価値がある。
VSCodeからCursorに移行して以降、Sonnetとのエージェントモードが印象的だ。経験豊富な開発者がこれを導けば、生産性向上に大きく寄与しうる。
LLMを使って文書の誤字や論理的なミスを修正する助けを得ている。Graphite Reviewerを使い、実際のバグやミスに集中できるよう調整している。AIは完璧ではないが、コード校正ツールとして有用だ。