私のLLMコード生成ワークフロー

 (harper.blog)
43 ポイント 投稿者 GN⁺ 2025-02-19 | 6件のコメント | WhatsAppで共有
  • tldr: 仕様をブレインストーミングし、計画を立て、その後 LLM codegen を使って実行する。個別の反復ループ。すると魔法が起こる
  • 私は LLM を使って、さまざまな小規模プロダクトを素早く作っている。楽しくて、実用的だ
  • ただし、間違ったアプローチにはまると大きく時間を無駄にすることがある
  • 多くの開発者が似たようなアプローチを取っており、以下は私のワークフローだ

    「今はうまく動いているが、2週間後には動かなくなっているか、2倍うまく動いているかもしれない」

  • 開発方法は2つある
    • グリーンフィールドコード: 新しいプロジェクトを始める
    • レガシーなモダンコード: 既存のコードベースを改善または拡張する

Greenfield: ゼロから始める

  • 「最初から始める」状況によく合うプロセスだ
  • アイデアをブレインストーミングし、文書化し、小さな段階的計画を立てた後、コード生成ツールを使って実装する流れだ
  • Step 1: アイデアの具体化
    • ChatGPT のような LLM にアイデアを説明しながら、質問を1つずつ促して、具体的な仕様へと磨き上げる
    • 最後には詳細な仕様書 spec.md を作り、開発者に渡せる文書形式にまとめる
    • 必要なら Deep Research のようなツールで、アイデアに関する根拠資料を得ることもできる
  • Step 2: 計画の策定
    • 仕様をもとに、より強力な「理解・推論」モデルに詳細な段階別ブループリントを生成させる
    • TDD 方式であってもなくても、各段階ごとに小さな作業単位を作り、順番に整理する
    • このプロセスを通じて prompt_plan.md と todo.md を生成する
      • prompt_plan.md にはコード生成に必要なプロンプト設計を、todo.md にはチェックリストを含める
    • この計画策定は15分ほどで十分なことが多く、あとで参照しやすい
  • Step 3: 実行
    • Aider、Cursor、Claude など、さまざまなコード生成・支援ツールを使って実際のコードを書く
    • 代表例として Claude と Aider を挙げられる
    • Claude 方式
      • あらかじめプロジェクト構造（boilerplate など）をセットアップしてから、段階ごとのプロンプトを Claude に入力する
      • 生成結果のコードを IDE にコピー＆ペーストし、テストを行う
      • 問題が起きたら repomix のようなツールで現在のコードベースを Claude に渡してデバッグする
      • ワークフロー
        • Repo セットアップ (boilerplate, uv init, cargo init, etc)
        • Claude にプロンプトを貼り付ける
        • claude.ai から IDE へ copy & paste
        • コード実行、テスト実行など
        • …
        • 動いたら、次のプロンプトへ進む
        • 動かなければ、Repomix を使ってコードベースを Claude に送ってデバッグする
        • この作業を繰り返す (rinse repeat)
    • Aider 方式
      • Aider でも prompt_plan.md を順番に入力して進める
      • 自動でテストを回したり、エラーを見つけて修正したりする過程を支援してくれる
      • 必要に応じて対話的デバッグで問題を解決する
        • Repo セットアップ (boilerplate, uv init, cargo init, etc)
        • Aider を実行
        • Aider にプロンプトを貼り付ける
        • Aider が踊るのを見る ♪┏(・o･)┛♪
        • Aider がテストを実行したり、アプリを起動して検証したりできる
        • 動いたら、次のプロンプトへ進む
        • 動かなければ、Aider と Q&A しながら直す
        • この作業を繰り返す (rinse repeat)
  • 結果
    • このやり方で、スクリプト、Expo アプリ、Rust CLI など複数のプロジェクトを短時間で実装できる
    • 先延ばしにしている大小さまざまなプロジェクトがあるなら、一度試してみることを勧める
    • 新しい言語や技術を学びながら素早く試せるのが利点だ

Non-greenfield : 既存コードに対する段階的・反復的作業

  • すでに存在するコードベースに小さな作業を繰り返し適用するときに使う方法だ
  • 全体的な大きな計画よりも、作業単位ごとに具体的な依頼と結果をやり取りする流れになる
  • コンテキストの確保
    • repomix のようなツールを使ってコードベースを要約し、LLM に渡せる
    • mise などで反復設定を管理し、output.txt というファイルに要約結果を保存する
    • 大きすぎるコードベースの場合は、必要な部分だけを要約するよう調整する
  • ワークフロー例
    • mise run LLM:generate_missing_tests のようなコマンドで、テストが不足している箇所を LLM に把握させる
    • Claude や Aider でその提案事項（issue）を適用し、結果を再びテストする
    • このように既存コードベースを段階的に改善していく

主なプロンプト例

  • Code review
    「シニア開発者として、このコードを徹底的にレビューしてほしい。行番号と文脈情報も含めること。浅いレビューではなく、深く確認すること」
    “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
  • GitHub Issue generation
    「シニア開発者としてコードをレビューし、主要な issue を GitHub issue 形式で書いてほしい」
    “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
  • Missing tests
    「シニア開発者としてコードをレビューし、不足しているテストケースや必要なテストを具体的に示してほしい」
    “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

スキー ᨒ↟ 𖠰ᨒ↟ 𖠰

  • LLM を使って高速にコードを書いていると、ある時点で複雑さや文脈が絡み合い、混乱してくる
  • 計画段階（たとえば Greenfield プロセス）の文書を見直したり、テストを体系的に整備しておくと役立つ
  • 速く動くぶん、少し休憩したり、考えを整理したりする時間を持つことも重要だ

私はとても孤独 (｡•́︿•̀｡)

  • ほとんどの LLM ベースのワークフローは「1人モード」に最適化されている
  • チーム単位で一緒にコーディングしようとすると、コンフリクトやマージの問題などが複雑になる
  • 複数人が同時に LLM を活用できる「マルチプレイヤー型」の協業環境が発展してほしい

時間

  • LLM によってコード作成の効率は大きく上がったが、トークン処理の待ち時間による「ダウンタイム」はある
  • この時間を使って別のプロジェクトのアイデアを考えたり、音楽を聴いたり、会話したりしている
  • 個人の生産性が以前より大きく向上したと実感している

Haterade ╭∩╮( •̀_•́ )╭∩╮

  • 多くの友人は「くそったれな LLM、こんなのまったく役に立たない」といった態度を見せるが、私はそうした見方をあまり気にしていない
  • もちろん私もその立場を共有しているわけではないが、懐疑的な視点が必要なのは事実だ
  • AI を嫌う理由はいくらでもあり、私が最も心配しているのは電力消費と環境への影響だ
  • それでも… 「コードは流れなければならない」 そうだよな… はぁ
  • もっと知りたいが、別にサイボーグ・プログラマーになりたいわけではないなら、私のおすすめは「意見を変えずに、Ethan Mollick の『Co-Intelligence: Living and Working with AI』を読んでみること」だ
    • この本は、テクノ・アナーキズム的な資本主義スタイルの大げさな煽りなしに、LLM がもたらす利点をうまく説明している
    • 個人的にもとても助けられたし、この本を読んだ友人たちともずっと深い会話ができた
    • 強くおすすめする

関連記事

6件のコメント

 
devs5 2025-02-25

Ethan Mollickの『Co-Intelligence: Living and Working with AI』は、
3月に『デュアル・ブレイン』というタイトルで出版予定のようですね
 
kipsong133 2025-02-25

Repomixというものがあったんですね。毎回コピペしていたのに..（泣）
 
chugue85 2025-02-21

ありがとうございます！
 
ahwjdekf 2025-02-21

他の開発者から浴びせられる悪口までLLMが代わりに受けてくれるのだろうか？
 
aer0700 2025-02-20

私はまだLLMを、高度なGoogleや親切なStack Overflowのようなものとして使っている段階ですが、もっとうまく活用する方法があるのか考えてみる必要がありそうです。
私としては、どう作るかももちろん重要ですが、なぜ動くのかをAIと一緒に考えることも重要な気がします。昔の技術文書や標準のようなものを探すときには、LLMが役に立ちます。
 
GN⁺ 2025-02-19
Hacker Newsのコメント

  • LLMは新規プロジェクトのプロトタイプを素早く作るためのツールである。しかし既存コードや成熟したプロジェクトに変更を加える際には、文脈不足によって複雑性を増したり不要なフレームワークを追加したりしがちである。LLMはコード理解の代替ではない。

  • LLMとの協業では、質問を通じて文脈を構築することが重要である。これは直接文脈を作るより効果的である。

  • 最近はLLMと一緒にモブプログラミングを試している。あるLLMが実装を担当し、別のLLMが批判と改善提案を行う。

  • プロジェクトに意見の強いフレームワークを追加しない方が望ましい。これはモデルが認識すべき文脈の大きさを増やすためである。たとえばPlasmoの代わりに、LLMにブラウザ拡張機能の設定を任せる。

  • Cursor chatから始めて、より良いワークフローへ発展させた人たちの体験談を聞きたい。計画に投資した時間が有益だったのか、幻覚が減ったのか、全体として時間を節約できたのかが気になる。

  • この記事はLLMを正しく活用する方法を説明している。多くの人は言語モデルと効果的にコミュニケーションする練習が不足している。著者はLLMとのコミュニケーションを習得しており、このワークフローは効率を最大化する。

  • LLMを使ったワークフローで効率を最大化するには、速いタイピング速度、適切な判断力、各モデルの強みと弱みに対する習熟が必要である。

  • LLMを使ったコーディングツールは面白いが、本当に役立つかを確認するには具体的な目標と締め切りを設定する必要がある。LLMはこうした条件下で失敗する可能性が高い。

  • 多くの新人プログラマーは、プログラミングにおける仕様策定と実行計画の部分を忘れている。LLMをうまく使うには、仕様と実行計画を作らせる必要がある。

  • Claudeへの期待が理解できない。Apache Sparkに関する質問では幻覚が多く発生する。Claudeが他のモデルより優れている理由を理解したい。

  • 個人開発者には問題ないが、同じコードベースを分析する複数のLLMインスタンスをチームで使うのは、経済的でもなく危険でもありうる。チーム向けに中央集約された文脈を提供する製品があるのか気になる。