この記事は自動翻訳されています。原文はこちらをご覧ください。
AI コーディングのワークフローで最もイライラするもののひとつは、実装が早すぎることです。
コード自体は技術的には問題ないこともありますが、頭の中にあった問題の別の版を解いてしまっています。
リファクタリングをしたかったのに、書き換えが始まった。 範囲を絞った改善をしたかったのに、プロジェクトの半分に触れた。 選択肢を話し合いたかったのに、すぐにファイル変更へ進んだ。
だからこそ、Visual Studio の新しい Plan agent はとても有用な追加機能です。
これは見た目の問題ではなく、実際のワークフローの問題を解決します
元の投稿は、とてもよくある状況をこう表現しています。"コードは間違っていない… ただ、あなたが望んだものではない。"
この一文は本当に的確です。
なぜなら、AI 支援開発の弱点はモデルがコードを出せるかどうかではないからです。実装が始まる前に、作業の意図した形について合意するための十分な余地がワークフローにあるかどうかが問題なのです。
それが特に重要なのは次のような場合です。
- 大きな機能
- なじみのないコードベース
- 単純ではないリファクタリング
- アーキテクチャに敏感な変更
- 編集を始める前にチームレビューが必要な作業
こうした状況では、すぐに実装へ飛び込むのはたいてい間違いです。
タスクが本物なら、計画はオーバーヘッドではありません
チームは、とても早く実装を始めることでどれだけ時間を失っているかを、時々見積もり違いしていると思います。
もし agent が:
- 間違ったファイルを触る
- 間違ったアプローチを選ぶ
- 重要な制約を見落とす
- 必要なエッジケースを無視する
なら、“速い” はずの開始が、全体としては遅いワークフローになります。
だからこそ、この機能が好きです。
次のための余地を作ります。
- 明確化の質問
- 計画の作成
- 計画の直接編集
- コード変更が始まる前に計画を共有すること
それは官僚主義ではありません。多くの場合、ただの良いエンジニアリングです。
Markdown の plan ファイルは賢い選択です
特に気に入っている点のひとつは、すべての plan が .copilot/plans/plan-{title}.md に保存されることです。
これで計画のステップが具体的になります。
plan がチャットの transcript の中に閉じ込められません。次のようなものになります。
- 確認する
- 編集する
- 頭の中で version 管理する
- チームと話し合う
- より意図的に実装へ渡す
そのおかげで、この機能は単なる一時的な前置きではなく、かなり本格的に感じられます。
ここで AI ワークフローはチームのプロセスを尊重し始めます
これは、これらのツールが成熟してきている強い兆候のひとつだと思います。
優れた AI 開発ワークフローは、途中の手順を全部なくすものではありません。正しい途中の手順を改善するものです。
そして計画は、その手順のひとつです。
plan が強ければ、実装は簡単になります。 plan が弱ければ、実装は雑然とします。
この機能はそれをそのまま認めています。
私見
これは単なる AI の気の利いた機能ではありません。
ワークフローの改善です。
そして、実際の機能や実際のリファクタリングにおいては、不要な churn、レビューのノイズ、“それはそういう意味じゃない” という手戻りをかなり減らせる種類の改善です。
今後、もっと多くの agent 体験がこういうものを必要とするはずだと思います。
Visual Studio は、それを実用的な形で早く実現しました。
