シェア:
){kind=small}
Benjamin AronovはVonageの開発者支援者です。彼はRuby on Railsのバックグラウンドを持つ実績のあるコミュニティ・ビルダーです。Benjaminは故郷であるテルアビブのビーチを楽しんでいる。テルアビブを拠点に、世界最高のスタートアップの創設者たちと出会い、学ぶことができる。技術以外では、完璧なパン・オ・ショコラを求めて世界中を旅するのが好き。
「バイブ・コーディング」を超えて：2026年のベストプラクティス
所要時間：2 分
この記事では、2026年に実際のチームが採用しているAIコーディングのベストプラクティス、ワークフロー、およびエージェント型エンジニアリングのパターンについてご紹介します。
この8か月間、私はテルアビブからニューヨークへと徐々に移り住みました。この移住はそれだけの価値がありましたが、毎週のように目まぐるしく変わるAIコーディングのトレンドにはついていけませんでした。
それに、AIのコーディングの世界では、8ヶ月なんて10年にも感じられる。
私が最後にワークフローを本格的に更新したのは、2025年12月頃でした。当時は、WindsurfとCascade（現在は Devin）を組み合わせて使用していましたが、その後 Claudeモデルに切り替えたのですが、その際の重要な発見は、非常に独自の考え方を反映した CLAUDE.md ファイルを実装することでした。具体的には、まず計画を立て、変更はシンプルに保ち、テストを記述し、テストを実行し、根本原因の分析を省略しないことです。
最も役に立ったルールは、同時に最も地味なものでもありました：
まず、問題をじっくりと検討し、関連するファイルを読み、チェックリスト形式の計画を立てて tasks/todo.md にチェックリスト形式の計画をまとめてから、コーディングに取り掛かってください。
そのたった一つの変更が、私の開発作業を飛躍的に加速させてくれました。作業に集中できるようになり、エージェントの誤動作も大幅に減り、チケットの処理も以前よりずっと速くこなせるようになりました。
そこで、私は知りたかったのです。 「この半年間で、どのような新しいスーパーパワーが登場したのでしょうか？」
私は、今や多くの開発者が急いで最新情報をキャッチアップする際に行うであろうことを、丸一日かけて試してみました。つまり、クロード、グロック、そしてChatGPTに最新のAIコーディングのトレンドを調査させ、その後、それらに互いに議論を交わさせたのです。しかし、私が求めていたのは最新のデモではありませんでした。実際に定着しているものが何なのかを知りたかったのです。
その後、私が信頼する約15人の人々――CTO、スタートアップの創業者、AI研究者、バックエンドリーダー、チームリーダー、そして実際のコードベースでこれらのツールを使用しているシニアエンジニア――に、結果の妥当性を確認してもらいました。
これが私が見つけたものです。
Share the AI coding workflows and practices that have proven useful in production.皆さんのコーディングのワークフローについてぜひお聞かせください。こちらのLinkedInの 投稿に回答をお願いします。
ソーシャルメディアでは、毎日、洗練されたデモ動画が次々と投稿されています。「このフレームワークを使えば、エージェントの生産性が10倍に！」「この新しいツールを使っていないなら、もう時代遅れだ！」といった具合です。しかし、何が真実で何が誇大広告なのかを見極めるのは難しいものです。
「バイブ・コーディング」というフレーズ アンドレイ・カーパシーが という「Vibeコーディング」というフレーズは、ソフトウェア開発に革命をもたらした。意図を記述してコーディングし、生成された変更を受け入れ、アプリが動作するまでモデルを微調整していく手法だ。 かつてはこれとは異なる方法をとっていたとは、今となっては信じがたいほどだ。コリンズ辞典はこれを2025年の「今年の言葉」に選出した。しかし、本格的な開発チームは、かつてはひとまとめにされていた2つの考え方を区別するようになった。それは、AIを使ってコードを生成することと、十分な構造や検証なしにAI生成コードを受け入れることである。
前者は今後も続くでしょう。後者が問題なのです。 CodeRabbitによる分析 によると、GitHub上の実際のプルリクエスト470件を分析した結果、AIが共同執筆したコードには、人間が書いたコードに比べて約1.7倍多くの問題が含まれており、セキュリティ上の脆弱性は最大で2.7倍も高いことが判明した。コード自体は機能する。しかし、これまで以上に綿密な検証が必要だ。
つまり、これは「バイブ・コーディング」から、いわゆる エージェント型エンジニアリングと呼ばれるものへの転換です。エージェントは、ファイルの検査、コードの記述、コマンドの実行、テストの生成、障害のデバッグ、そして自身の出力の評価を行うことができます。しかし、その周囲には依然としてエンジニアリング・プロセスが必要です。特に本番環境を重視する場合はなおさらです。
ソーシャルメディア上のブームの波に乗ると、誰もが絶えずワークフローを更新しているかのように思えてしまいます。仕様主導型、マルチエージェント型、クラウドによるオーケストレーション、MCP連携、あらゆる面で自律化されたパイプラインなどです。
そこで、重大な責任を担っている友人たちの中から、少数ながら頼りになるグループに、彼らが実際に何をしているのか尋ねてみた。彼らの取り組みは、インターネット上で言われているような複雑なものではなく、概してもっとシンプルなものであった。具体的には、強力なコーディングエージェント、計画段階、リポジトリの指示ファイル、テスト、手動によるレビュー、時折のモデル切り替え、そして時にはレッドチーム活動用の第2のモデルといったものだった。
あるCTOは次のように述べた：
「常にまず計画を立てましょう。どんなに些細な仕事であっても、ただ『これをやれ』と言うだけでは、相手は何かを見落としてしまいます。」
あるチームリーダーは次のように述べた：
「完璧に見えるまで計画を練り、それから作り上げる。特別なことは何もしない。」
また、あるシニア・フルスタックエンジニアは、自身のゼロトラストアプローチについて次のように説明した：
「まずテストを作成させ、次にそのテスト自体をテストさせます。その後、別のエージェントにレッドチーム攻撃を行わせます。そして最後に、手動でテストを行います。金銭やライフサイクルに関わる場合は、必ず手動で行います。」
今や、人間の責任の大部分は、エージェントと協力して完璧な計画を立てることにあるというのが、かなり明らかになってきました。私のマニュアル tasks/todo.md という習慣には、今やもっと凝った名前がついています。
仕様主導の開発は、より洗練されたアプローチです。まず意図を明確にし、それを仕様に落とし込み、実装計画を策定し、それをタスクに分割してから、初めてエージェントにコーディングを任せます。GitHubのSpec Kitは、これを次のように形式化しました。 spec.md、 plan.md、および tasks.md。 AWS Kiro は、追跡と説明責任を確保するための構造化された成果物として仕様書（specs）を使用しています。
ツール内部でも同様の考え方が見られます。 Claude Codeには /goalという機能があり、これは検証可能な完了条件（すべてのテストに合格し、すべてのTypeScriptエラーが解決され、マイグレーションが完了すること）が満たされるまで、Claudeに処理を継続させるよう指示します。内部では、軽量な評価モデルが各反復の後に目標が客観的に達成されているかをチェックするため、エージェントは収束するか、予算に達するまで自律的にループを繰り返します。 Codexも同様のコンセプトを実装しておりを実装しており、以下のような状態を備えています： pursuing、 pausedといった状態を用いて実装しました。、 達成、および 予算制限のある といった状態が、セッションの再起動後も維持される。
これは、 tasks/todo.mdの製品化版です。エージェントがいつでも立ち返ることができる堅牢な目標であり、これを取り巻く環境においてより自律性を高めています。
また、自律性がコスト高になる場所でもあります。完了条件が曖昧な場合、エージェントは長時間ループし続けても、結局正しい行動をとれない可能性があります。安全策のない自律性は、単に金を無駄にするスピードを速めるだけなのです。
重要な作業を行う場合、担当者はコードを編集する前に、次の3つの質問に答えるべきです。「何を変更するのか？」「どのファイルや動作が関係しているのか？」「変更がうまくいったかどうか、どうやって確認するのか？」
テスト駆動開発（TDD）は常に絶対的な真理として説かれてきましたが、実際に実践されることはそれほど多くありませんでした。しかし、エージェント型コーディングの登場により、テストへの投資は開発者の主要な業務の一つとなりました。この手法をいち早く導入したあるCTOは、私にこう語ってくれました。「計画を立てるだけでも、かなり試行錯誤を繰り返します。 開発する機能については、どれも非常に網羅的なテストを作成させている。そうすれば、完成した時に確実に動作することが分かるからだ。」
エージェントがそれを書き留めることができない場合、コーディングの準備ができていないことになります。
以前のワークフローでは、大きな CLAUDE.md ファイルに依存していました。そこにはルールや強調事項を詰め込んでいました。「怠けてはならない」「テストを決して省略してはならない」「すべてを可能な限りシンプルにすること」。その意図は、エージェントが規律を守り、手抜きをしないようにすることでした。
そして、この種の指針は功を奏した。2025年までに、すべてのエージェント型プロバイダーが、何らかの形のリポジトリレベルの指示を採用するようになった。Claude Code、Codex、Cursor、Copilot、Windsurfなどがそれである。業界は AGENTS.mdを軸に標準化が進み始めました。これは、エージェントに対してプロジェクトの基本ルールを伝えるリポジトリレベルのガイドです。
しかし、人々は自分の「Claude」ファイルにデータを詰め込み始め、それには代償が伴いました。 2026年2月にETHチューリッヒが実施した研究では では、リポジトリの指示ファイルを実際のGitHubの課題に対して検証した結果、肥大化したコンテキストファイルはタスクの成功率を向上させないことが多く、推論コストを20％以上増加させる可能性があることが判明した。
同じ指示を3回叫んだからといって、エージェントの規律が向上するわけではないことがわかりました。ほとんどの場合、トークンを無駄に消費するだけで、本当に重要なルールが埋もれてしまうだけです。
新たな障害モードは「コンテキストの腐敗」です。不良な AGENTS.md がある方が、 AGENTS.md がない場合よりも深刻です。なぜなら、エージェントは古くなった指示を疑いもなく実行してしまうからです。
そこで、業界はこの概念を2つに分けました。 AGENTS.md は、無駄を省いたシンプルなままにしておくべきです。これは、「このプロジェクトに固有のルールや慣習は何か？」という問いに答えるものです。
それ以外のすべてについては、「スキル」が役立ちます。スキルとは、特定のタスク（新しいAPIエンドポイントの追加方法、データベースのマイグレーション方法、リリースチェックリストの作成方法など）に関する、必要に応じて読み込まれるリファレンスです。スキルは、エージェントがそのパターンを認識し、必要とした場合にのみ読み込まれます。
実際には、次のような感じになります：
あなたの AGENTS.md には次のように書かれています：
以下のコマンドでテストを実行します npm testでテストを実行してください。マージする前には必ずコードを確認してください。新しい連携を追加する際は、Webhookスキルを使用してください。
Webhookスキルは次のように表示されます：
ルートを作成し、タイプを追加し、ハンドラを記述し、成功時と失敗時の処理を実装し、ドキュメントを更新します。
エージェントは、すべての手順を常時稼働のコンテキストで実行する必要はありません。手順はスキル内に残ります。あなたの AGENTS.md は簡潔なままです。また、Webhookのプロシージャが変更された場合でも、Skillを1回更新するだけで済みます。
経験則： AGENTS.md は、地味で簡潔に保つこと。繰り返し説明しているような手順がある場合は、スキルを作成しましょう。また、リポジトリの指示はコードと同じように扱いましょう。レビューを行い、古くなったルールは削除し、放置して劣化させないようにしましょう。
The モデル・コンテキスト・プロトコル（MCP） は、2025年の開発者界隈において、おそらく最も話題を集めた用語だった。そのコンセプトは確固たるものであった。つまり、ツールごとに独自のグルーコードを書く代わりに、統合機能を組み込むための標準化された単一の方法を確立するというものだった。
だから当然、2026年には「MCPは終わった」と言われるでしょう。それは事実ではありません。しかし、MCPの活用方法はより複雑化しています。
私が取材したあるCTOは、次のように率直に語った。
「モデルたちはもはやMCPにほとんど頼らなくなってしまった。CLIを駆使するだけというだけで、恐ろしいほど上手くなってしまったのだ。」
核心となる問題はオーバーヘッドです。標準的なMCPサーバーは、エージェントが何か有用な処理を行う前に、大量のツールスキーマをコンテキストに書き込んでしまうことがあります。CLIツールはローカルで、組み合わせが可能であり、そのモデルはコマンド、フラグ、パイプ、JSON出力、ログといったUnix型のワークフローにすでに非常に適しています。
しかし、エージェントは魔法のようにCLIを発見するわけではありません。彼らには指示が必要ですが、その指示はより簡潔なものであればよいのです。
もし、次のようなよく知られたCLIであれば awsや gh、 gcloud、または dockerのいずれかを使用している場合、エージェントはトレーニングを通じてそれを認識している可能性が高いです。「このプロジェクトではAWS CLIを使用しています。認証情報があります。インフラストラクチャにはそれを使用してください」と指示すれば、通常、エージェントが残りの処理を自動的に行います。
カスタムCLIや内部用CLIの場合は、スキルを作成してください。コマンド、フラグ、出力の形式について1段落で説明すれば、たいていは十分です。
MCPに関する成熟した議論は、「MCPは終わったのか？」というものではなく、「確率論的なツール呼び出し元に、今どのような権限を付与してしまったのか？」というものです。
MCPは、エージェントが外部システム（ドキュメント、チケット、可観測性、データベース、APIなど）への管理されたアクセスを必要とする場合に有効です。しかし、CLIで安全に処理できるのであれば、まずはそこから始めてください。同じCLIの手順が繰り返される場合は、それをスキルに変換してください。 どちらの選択肢も不十分な場合にのみMCPを採用し、すべてのMCPサーバーを本番環境のインフラと同様に扱ってください。つまり、最小権限の原則、承認プロセス、ログ記録、およびセキュリティレビューを徹底してください。
A popular meme highlighting how AI agents have changed the day-to-day experience of software engineering, often shifting the role from implementation toward orchestration and oversight.
2026年に起こるより大きな変化は、コーディングエージェントがもはやエディタに付属する単なるチャットウィンドウではなくなるという点だ。それらは制御プレーンへと変貌しつつある。
クロード・コードには /goal、フック、サブエージェント、バックグラウンドセッション、エージェントビューを備えています。Codexには、CLI、クラウド、アプリ、ワークツリー、コードレビュー、モバイル監視機能が備わっています。 GitHub Copilot は、イシューをプルリクエストに変換したり、コードをレビューしたりできます。 Google Antigravity は、ワークスペースをまたぐエージェントの管理を中核としています。
インターフェースは、「モデルとのチャット」から「ある程度信頼できるワーカーのキューを管理する」ものへと変化しつつあります。
それは未来的な話に聞こえますが、そこから得られる実用的な教訓は退屈なものです。つまり、どのエージェントにも、明確なタスク、狭い影響範囲、成功を証明する方法、そしてマージの責任者となる人間が必要だということです。
ここで、長時間実行されるエージェントが役立ちます。
更新が必要な依存関係が30件あると想像してみてください。通常なら、エージェントと向き合い、1件ずつ指示を出し、変更内容を1つずつ確認し、マージを1つずつ承認することになります。これには何時間もかかり、あなたの時間を奪ってしまいます。
長時間実行されるエージェントは、リストを順に処理することができます。つまり、1つの依存関係を更新し、テストを実行し、失敗した箇所を修正し、次の依存関係に進み、すべてのテストに合格したら停止します。
「完了」という状態は客観的に検証可能であるため、これは良いユースケースです。
長時間実行されるエージェントが実際に有効な例としては、依存関係の更新、テストのクリーンアップ、ドキュメントの生成、SDKのサンプル、研究タスク、あるいは「すべてのテストに合格する」、「lintでエラーがない」、「マイグレーションが完了する」といった、極めて明確な受け入れ基準を持つバックログ項目などが挙げられます。
それらが大失敗に終わる場合――課金、認証、権限、データ移行、削除、コンプライアンス、あるいは顧客データやそのライフサイクルに関わるあらゆる事柄において。こうした場面では、判断が求められます。「このデータ移行は安全か？」という問いは、単純に「はい」か「いいえ」で答えられるものではありません。「これを削除すべきか？」という問いも同様です。
ルール：「完了」が客観的に検証可能であり、万一不具合が発生した場合の影響範囲が小さい作業にのみ、長時間実行型のエージェントを使用する。それ以外の作業はすべて、人間のペースで行う。
エージェントを自分で実行している場合は、 tmux は、今でもあなたを救ってくれる「地味な裏技」です。長時間実行されるエージェントは、SSH接続が切断されると停止してしまいます。ターミナルマルチプレクサーを使えば、セッションを維持し、切断を乗り切り、何が起きたかをスクロールバックで確認することができます。
しかし tmux は、あくまで「自作の代替手段」であり、主役ではありません。実際のトレンドは、ツールがこのパターンを製品化しているという点にあります。具体的には、バックグラウンドセッション、エージェントダッシュボード、隔離されたワークツリー、リモート承認、レビューキューなどです。
検証可能な成功基準のない永続的なエージェントは、単に長くてコストのかかる妄想に過ぎない。
また、OpenClaw や Hermes のような、常時稼働型のパーソナルエージェントランタイムという並行するカテゴリーも存在します。これらは、メッセージのルーティング、セッションの監視、アラートの送信、場合によってはタスクの割り当てなど、コーディング作業を取り巻く制御プレーンとして興味深いものです。しかし、現時点ではまだコーディングワークフローの中核とはなっていません。 注目し、試してみる価値はありますが、まるで世界中の誰もが独自のOpenClawエージェントを持っているかのような錯覚を抱く必要はありません。私が話を聞いた15人のアーリーアダプターのうち、これをセットアップしていた人は一人もいませんでした。
私が自分のワークフローについて話した際、AI研究部門の責任者が最初に尋ねてきた質問は、ツールやフレームワークに関するものではありませんでした。その質問はこうでした：
「トークンの予算はいくらですか？」
これこそが、エンジニアリングとコーディングの違いです。確かに、AIエージェントの場合、問題に対して十分な資金と時間を投入すれば、おそらく構築することは可能でしょう。そのため、現在ではワークフローに関するあらゆる決定が、主に予算に左右されるようになっています。そして、エージェントの種類によって予算にも影響が出るのです。
私が話を聞いた人の中には、Codexを全面的に支持している人もいれば、Claudeを好む人もいます。Cursorのユーザーは、モデルを切り替えられる点を気に入っています。また、会社が提供しているからという理由でCopilotを使っている人もいます。
ある創業者は、Codexを使って「まるで野獣のように、機能開発を次々と片付けている」と私に語った。別の創業者は、もう少しニュアンスのある見解を示した：
「Codexは計算系の分野なら何でもとてつもなく強い。でも、センスの良さではやはりClaudeの方が上だ。」
しかし、あるCTOからの、より冷静な助言の方が役に立った：
「特定のモデルに固執してはいけない。2週間ごとに、あるモデルは陳腐化し、別のモデルがより優れたものになるのだから。」
「耐久性のあるパターン」とは、モデル管理のベストプラクティスです。具体的には、計画立案や厳密な推論には堅牢なモデルを、単純な編集にはコスト効率の良いモデルを、リスクの高いレビューには別のモデルを、そして他のモデルやセッションがその作業を引き継げるよう、移植性の高い指示書を活用します。
料金体系が従量課金制へと移行するにつれ、この点はさらに重要になってきます。成功するワークフローとは、「あらゆる場面で最も高性能なモデルを使う」ということではありません。コストのかかる推論がいつ価値を持つかを判断することこそが重要なのです。
コードのコストが安くなると、それが正しく動作し、質が高いかどうかを確認するコストが高くなります。これは、AIを使ったコーディングに反対する主張ではありません。説明のつかないコードをリリースすることへの反対論なのです。
幸いなことに、ツールも追いついてきています。 フック は、エージェントのイベント発生時に実行される決定論的なスクリプトです。これにより、チームは特定の検証を必須にすることができます。A PostToolUse フックを使えば、ファイルの編集ごとにリンターや型チェックを自動実行でき、実行終了時ではなく実行中に問題を検出できます。 Stop フックを使用すると、エージェントが時期尚早に「完了」と宣言するのを阻止できます。これらはモデルの判断に依存しない安全装置であり、長時間実行される作業や自律的な作業においては、この区別が重要になります。
適切なレビューのループは、次のようなものになるでしょう：
担当者にテストの作成または更新を依頼する。
担当者に、該当するテストスイートを実行してもらってください。
別のモデルを使用して、重要な差分に対してレッドチーム攻撃を行ってください。
リスクの高い経路を手動でテストする。
人間による審査の前に役立つプロンプト：
自身の変更内容を確認してください。
バグの可能性、欠落しているテスト、エッジケース、セキュリティ上の懸念、あるいは不必要な複雑さがないか確認してください。
まだファイルは変更しないでください。まずは発見した内容を報告してください。
セキュリティ面での重要性はさらに高まります。エージェントがプルリクエストにコメントを付けたり、ワークフローを実行したり、ツールを呼び出したり、認証情報にアクセスできるようになると、プロンプトインジェクションは単なるチャットボットの問題ではなく、CI/CDの問題となります。
多くのチームが依然として過小評価している点は、まさにそこだと思います。エージェントがイシューやPRの説明、コードのコメント、依存関係の変更履歴などを読み込む場合、それは信頼できない入力を読み取っていることになります。さらに、コマンドの実行やシークレットへのアクセス権限まで持っていれば、そこには攻撃対象領域が生まれてしまうのです。
だからこそ、ありきたりなルールがさらに重要になるのです。すなわち、最小権限の原則、サンドボックス化、承認プロセス、変更範囲の最小化、決定論的なチェック、Auditログ、そして担当者の明確化です。
リーンな AGENTS.md を作成し、インストール、テスト、型チェックのコマンド、ワークフロールール、および「完了の定義」を含めてください。内容は簡潔に保ってください。ルールは、エージェントが実際に何かで失敗した場合にのみ追加し、先回りして追加しないでください。
重要度の高い作業には、綿密な計画が必要です。コーディングを始める前に、担当者はチェックリスト形式の計画書を作成し、 tasks/todo.md に、目標、関連ファイル、手順、およびリスクを記載したチェックリスト形式の計画を作成する。
完成した計画書を以下の場所にアーカイブしてください tasks/archive/に保存してください。これらは、エージェントがどのような処理を行おうとしたのか、そしてその理由を示す履歴となります。
1つのプロンプトにつき1つのタスク、1つの差分につき1つの問題点。小さな差分は確認しやすいが、大きな差分にはバグが隠れている。
テストなしでは、行動変容は実現しません。担当者が「テストは必要ない」と言った場合は、その主張に異議を唱えてください。
何かを説明するときは、3回目に「スキル」を作成してください。初めてエージェントに手順を案内するときは、単に説明するだけです。2回目は、その手順が繰り返されていることに気づいてください。3回目は、「SKILL.md」を作成してください。
デフォルトではCLIを使用します。エージェントが外部システムへの管理対象アクセスを必要とし、かつCLIパスだけでは不十分な場合にのみ、MCPを追加してください。
長時間実行されるエージェントは、「完了」が客観的に検証可能な作業にのみ使用してください。依存関係の更新、テストのクリーンアップ、ドキュメント作成、リンティングの修正？ それなら問題ありません。課金処理、認証、マイグレーション、削除？ それはNGです。
別のモデルを用いて、レッドチームによる高リスクな差異を特定する。セキュリティ、決済、権限、またはデータライフサイクルに関わるものをマージする前に、別のモデルに問題の有無を確認してもらう。
人間としての役割を果たしましょう。差分（diff）を自分で確認してください。アプリを実行し、リスクの高い処理経路を手動でテストしてください。エージェントが提案し、決定するのはあなたです。
この調査を行ったことで、私の不安は和らぎました。ベストプラクティスとは、昔から変わらない真実のさまざまな形に過ぎません。つまり、SOLID原則に従い、TDDを心がけ、実装前に詳細な仕様書を作成することです。
最適なAIコーディングワークフローは、ソフトウェアエンジニアリングの代わりになるものではありません。それは、疲れを知らず、時には錯覚を起こし、時折すべてを台無しにし、非常に明確な指示を必要とする、はるかに速いジュニア開発者によるソフトウェアエンジニアリングなのです。
そのように扱えば、そのツールは驚くほど便利だ。魔法のように扱えば、いずれその「魔法」のデバッグをしなければならなくなるだろう。
これは、遅れを取り戻すための最初の試みです。次は、実際にこれらのツールを使って開発を行っている方々からの声を聞きたいと思っています。現在、皆さんのAIコーディングのワークフローはどのようなものですか？
Cursor、Claude Code、Codex、Copilot、あるいはその他のツールをお使いですか？Skills、MCP、サブエージェント、ワークツリー、 /goal、フック、あるいは長時間実行型エージェントを試してみましたか？どこで行き詰まりましたか？何を断念しましたか？
以下の場所で教えてください このLinkedInの投稿でお知らせください。
A LinkedIn post asking developers how their AI coding workflows have evolved in 2026, including questions about planning, guardrails, and emerging agentic practices.最も優れた回答を参考に、実際のVonage APIプロジェクトにおいて最も重要なワークフロー（並列エージェント、仕様先行の計画、リーン AGENTS.md に加え、スキル、MCP対CLI、そして実際のバグを捕捉する検証ループなどについて取り上げます。
結果は次回お伝えします。
ご質問がある場合、またはあなたが作っているものを共有したい場合は、こちらをクリックしてください。
登録する 開発者ニュースレター
フォローする X（旧ツイッター）最新情報
チュートリアルを見る YouTubeチャンネル
LinkedInの LinkedIn の Vonage デベロッパーページ
最新の開発者向けニュース、ヒント、イベント情報をお届けします。