🤕

Vibe codingをワンステップ引き上げる"Dry-run"について

に公開
LLM
Claude Code
Codex
zennfes2025ai
idea

まとめ

  • LLMが持つシミュレート能力を活かして「想定実行」する
  • プロジェクト理解に関してのコンテキストが足りているかどうかが人間で判断しやすくなる
  • 出力はPlanをシミュレートしたTraceとして出してもらう

"Dry-run"はどのようなものか

計画を実行する代わりにコードの実際の修正前に以下のPromptで「想定実行」すること。

hogehogeをコードを変更せずシミュレートして、出力は日本語でシミュレートのtraceとすること

hogehogeには
「下記の修正」や「ユーザーフローの言葉」などが入ります。

/dryrunで運用するのがいいかも

なぜ計画だけではダメなのか

「修正」という単語が持つ意味が広すぎるので、実際の修正範囲が予測できず
余計なことをする可能性や目grepで逐一追う必要がある

根拠は何か

いくつか「想定実行」に関する論文が出ています
Reasoning Runtime Behavior of a Program with LLM: How Far Are We?
https://arxiv.org/pdf/2403.16437

SEMCODER: Training Code Language Models with Comprehensive Semantics Reasoning
https://proceedings.neurips.cc/paper_files/paper/2024/file/6efcc7fd8efeee29a050a79c843c90e0-Paper-Conference.pdf

Making LLMs Program Interpreters via Execution Trace Chain of Thought
https://openreview.net/pdf?id=pFyBdPyOCQ

（ざっくりは読んでいるのですがまとめきれなかったのでURLだけとしています）

"Dry-run"すると何がいいのか

  • 実際のtraceが出るので、ツールを使って実際にコード修正をする前に判断ができる
  • その部分のコンテキストがあるのが確実なので、攻める部分がわかりやすい
  • プロンプトを勘で組んだりする必要がなく、一定の手順に乗せることができる

検証が途中な理由

  • ある一定の水準には載ってそう（ただ雑にPlanを組めというよりマシになってそう）
  • だが、毎回いい感じのTraceを吐いてくれるわけではなさそう
  • 同じプロンプトを打っても出力が変わるので評価が難しい

よかったら使ってみてください

関連記事

https://zenn.dev/tesla/articles/07362ac127ce91

Discussion