原文リンク(2026-03-31)
最近のAI DevOps PodcastでPaul Duvall氏は、最新モデルの能力向上に伴いエージェンティックAIパターンが中核的なエンジニアリング規律をどのように強化しているかについて論じた。彼はAI支援ソフトウェア開発の実践を記録し、進化させているエージェンティックAIエンジニアリング・パターンのリポジトリもシェアした。
Continuous Integration: Improving Software Quality and Reducing Riskの著者 Duvall 氏は自身のパターン集を、クライアントワークにおけるエージェンティックAIの実践的試用を通じて既存エンジニアリング・プラクティスがどのように適応されているかを探求するものと位置付けた。彼はAI生成出力を共有パターンに根拠づけることの重要性を強調し、「AIがコードを生成する状況ではエンジニアリング・プラクティスはこれまで以上に重要になる」と述べた。
AIによって生成されるコード量を踏まえ、Duvall氏はtrunk-based development、早期かつ頻繁なコミット、そして自動テストの重要性が引き続き高いことを強調し、変化の速度が高まり続ける中で品質維持するためにこれらが不可欠になると説明した。
Duvall氏は開発者がコードとどのように関わるかについての変化を述べ、変更量が増大しているためAI生成出力を扱う際には「今ではコードのすべてをレビューしているわけではない」と指摘した。その代わりに、Duvall氏はエージェントが自身の出力をレビューおよびリファインできるようにするコード化スキルを含む、自動検証およびエージェント型ガードレールへの依存を強調した。
Duvall氏は仕様駆動開発のようなアプローチが既存エンジニアリング・プラクティスをどのように進化させているかについても議論した。Duvall氏のリポジトリにはAWS IAMポリシー生成シナリオ用のエージェント読み取り可能な仕様例が含まれており、期待される振る舞い、制約、受け入れ基準を事前に定義することで、エージェントが明確な仕様に基づいて出力の生成と検証ができるようにしている。よく知られたtest firstパターンがAI支援ワークフローを導くためにどのように適応されているかを説明し、彼は言った：
私は文字通り…AgileやXPで行ってきたことを再現しています…そこには赤、緑、リファクタと書かれています…私はそのプロセスに従って進めています。
Duvall氏はエージェンティック・ライフサイクルの初期段階、特に意図の定義に関する課題もハイライトした。AIツールは迅速にコードを生成できる一方で、曖昧または仕様が不十分な入力がよく一貫性のない、あるいは予測不能な結果をもたらすことを彼は指摘した。その結果、役割、コンテキスト、制約を通じて意図を記述する構造化プロンプトを含むより明確な仕様、これには仕様駆動開発や定義された振る舞いに基づく受入れテストも含む、によってエージェントを駆動することに注目が高まっており、「意図を完全に記述していなければ」あなたは「ランダムな結果を得る」と彼は述べた。
より明確な仕様への同様のフォーカスは、System InitiativeのDirector of Productであり、インフラストラクチャの自動化と検証のためのエージェンティック・オープンソースプラットフォーム SWAMPに携わるPaul Stack氏との最近のDevSecOps Talksポッドキャストにおいても議論された。Stack氏はエージェント中心に開発プロセスを再構築しており、仕様駆動開発に連動するGitHub Issueベースのワークフローを優先するためにpull requestを受け付けないところまで踏み込んでいると述べた。彼は言った：
私たちはpull requestを受け付けません…もし設計があるなら…Issueを立ててください。インタラクティブにウォークスルーしながら一緒に設計するでしょう。
Scott Hanselman氏のポッドキャストに出演したThe Pragmatic Engineerニュースレターの著者 Gergely Orosz氏は、pull requestをマージせずに「remixing」を採用し、提出されたPRをプロジェクト標準に沿ってエージェントが再構築するオープンソースプロジェクトについて議論した。 これをサブエージェントが要件を満たすまで反復的にソリューションをリファインする完全自動化済の「Ralph loops」を用いる自律型エージェントと対比しつつ、Hanselman氏は、重要システムではアーキテクチャや設計の「テイスト」が重要である一方で、「無限に忍耐強いジュニアエンジニア」というメンタリティは定型作業に適していることを認めた。
Stack氏はアーキテクチャ、制約、テストに関する期待値をあらかじめ定義することでエージェントが「コードベースと整合した形でコードを生成」できるよう、適切なアーキテクチャパターンとプラクティスを提供する重要性を強調した。InfoQによるBoris Cherny’s agentic workflowの報道と同様、Stack氏は実行前に意図をレビューするためClaudeの「plan mode」も使用しており、「AIホラー・ストーリー」を回避する助けになっていると述べた。
Duvall氏はshift-rightの重要性と、これらのフィードバックループを本番環境まで拡張することの重要性を指摘した。彼は可観測性、テレメトリ、本番環境でのテストを活用してフィードバックサイクルを短縮し、ライブシグナルを解釈して開発ライフサイクルへ送る方法を説明した。将来的にはAIによってより小規模で集中したチームが可能になると示唆し、調整オーバーヘッドが減少し自動化が進むことで「one pizza team」への移行が進むと述べた。
Duvall氏はこれまでのエンジニアリングのシフトと同様に、品質は人間による検査ではなく自動化によって達成される傾向が強まると示唆した。彼は述べた：
あなたは仕組みを導入している…コードがレビューされるような…しかしそれは文字通りあなたが毎回レビューするという意味ではありません。
Duvall氏とStack氏はともに、AI支援開発にはshift-leftプラクティスとshift-rightフィードバックの混合が必要であり、振る舞いの定義や本番環境の状態そのものが検証プロセスの一部になると強調した。Duvall氏はパターンや問題をより早期に発見するためにAIが本番テレメトリをより広範に分析する利点についても言及した。
Duvall氏のリポジトリは継続的に更新されており、開発、セキュリティ、運用の各領域にわたって成熟度レベルを備えた構造化パターンを定義している。これらのパターンには仕様駆動開発、コード化ルール、アーキテクチャ上の制約、並列エージェントによるアトミック分解、自動化トレーサビリティを備えたワークフローのための可観測性重視の開発が含まれる。
コード中心の開発を超えるシフトを認めつつ、Orosz氏はエンジニアリングのアイデンティティと実践が、コードそのものを超えるレベルに移行するだろうとの見解を示した。彼は語る：
私たちを特別な存在にしているのはコーディング以上の何かだと思うし、それを育てるべきだと思う。