Addyosmani Agent SkillsがGitHub Trendingに再登場、だが重要なのはプロンプトではない

Addyosmani agent skillsは、公開から数か月が経過しているにもかかわらず、8月6日にGitHub Trendingのホットリストで7位に入った。このリポジトリは、AIコーディングエージェントが必要に応じて読み込める指示として、ソフトウェア開発の実践をパッケージ化している。再び注目を集めたことは、モデルに依然として不足しているもの、すなわち信頼できるエンジニアリングの規律への需要を示している。

この順位はサードパーティーの集計サイトによるものであり、新たなリリース日を示すものではない。基盤となるプロジェクトは、Osmaniが2026年5月3日に説明した時点ですでに公開されていた。拡張版は5月27日にO'Reillyで公開された。その時点で、同氏はリポジトリのGitHubスター数が27,000を超えたと述べている。

プロジェクトリポジトリは、8月6日の確認時点で約82,000スター、8,800フォーク、391コミットを表示していた。これらの数値は変動しうる。より本質的な対立は、再利用可能なワークフローと、毎回モデルが規律を選ぶことに依存する場当たり的なプロンプトとの間にある。

Addyosmani Agentプロジェクトは再びトレンド入りしたのであって、本日ローンチされたわけではない

確認できる出来事は、既存プロジェクトへの関心の再燃であり、新製品の発表ではない。

ホットリストの掲載は、8月6日にaddyosmani/agent-skillsが7位だったことを示している。信頼できる公開日時は示されておらず、その順位が日次、週次、地域別のどの期間を対象とするかも説明されていない。GitHub Trendingの順位は、リポジトリの活動が増えるにつれて変動する。

この不確実性は重要だ。トレンド入りは、新しいリリースがなくても速報のように見えることがある。このケースでは、基盤となるタイムラインは別の事実を示している。Osmaniは元のagent skillsに関するエッセイを5月3日付としており、観測された順位のほぼ3か月前に当たる。

このプロジェクトは以前にも大きな注目を集めていた。Osmaniのエッセイの5月27日版では、リポジトリが27,000スターを超えたと記している。8月6日のGitHubページでは約82,000スターが表示されていたが、GitHubのカウンターは固定された過去の記録ではなく、リアルタイムで変化する。

この差は、採用、ブックマーク、再配布が継続していることを示唆する。ただし、実運用で活発に使われていることの証明にはならない。スターは関心の表明を測るものであり、フォークは複製や実験を示す。いずれの数値からも、チームがワークフローを実行したか、導入を維持したか、ソフトウェア成果を改善したかは分からない。

リポジトリ自体も、5月のエッセイ以降に変化している。Osmaniは以前の記事で20のスキルと7つのスラッシュコマンドを説明していた。8月時点のリポジトリでは、仕様策定、計画、実装、テスト、レビュー、Webパフォーマンス、簡素化、出荷を対象とする24のスキルと8つのコマンドが記載されていた。

こうした拡張は、古いリポジトリが再びトレンドリストに現れる理由の説明になる。より幅広いパッケージへと成長し、統合を追加し、複数のコーディングエージェントコミュニティで注目を蓄積してきた。活動の様子は、単発のローンチ当日の急騰というより、継続的な配布に近い。

このリポジトリはMITライセンスで提供され、主にMarkdownの指示、補助リファレンス、コマンド、フック、エージェントペルソナで構成される。AIモデルでも、コード生成エンジンでも、ホスト型開発プラットフォームでもない。ユーザーには対応するコーディングアシスタントが必要であり、そのアシスタントにどの権限を与えるかも決めなければならない。

この区別が、見方を変える。このプロジェクトは、別のコーディングエージェントとしてClaude Code、Codex、Cursor、Gemini CLI、GitHub Copilotと競合するものではない。複数のツールの内部で利用できる、再利用可能なプロセス層を提供することを目指している。

このタイミングは、エージェント開発におけるより大きな変化も反映している。チームは、どのモデルが最も優れた関数を書くかという問いを超え始めている。エージェントがスコープを守り、証拠を収集し、長時間のタスクを完遂し、人間がレビューできる変更を生み出せるかを、ますます問うようになっている。

Addyosmani agentプロジェクトは、こうした運用上の問いに直接取り組む。GitHubでの再登場は、開発者が高性能なモデルを取り巻く制御構造を求めていることを示している。それらの制御構造が、プレーンなMarkdownで書かれている場合であってもだ。

なぜagent skillsは巨大なプロンプトに取って代わりつつあるのか

agent skillsは、永続コンテキストがすべてのリクエストで抱え込むことになる手順から、持続的なプロセスを切り分ける。

スキルはSKILL.mdファイルを中心に構成されたディレクトリだ。このファイルにはYAMLメタデータとMarkdownの指示が含まれる。オープンなskill formatによれば、補助スクリプト、リファレンス、アセットを同じ場所に置くことができる。

この形式は単純に聞こえるし、実際に単純だ。説明文は、どのような場合にスキルを適用すべきかをエージェントに伝える。本文は、従うべき手順を示す。周辺のハーネスが、いつ指示を読み込むか、エージェントがどのツールにアクセスできるかを決める。

この設計は、すべてのポリシーを1つの巨大なシステムプロンプトに置く方法とは異なる。永続的なプロンプトは、関係のない作業中にもコンテキストを消費する。また、テスト方針、リリース手順、セキュリティルールを、区別のない単一のブロックへと変えてしまう。

スキルは段階的開示を用いる。つまり、ハーネスは詳細な指示を、それらが必要になったときだけ読み込む。テストタスクではテストのガイダンスを有効化できる。デプロイ要求では、以前のすべての会話にデプロイ関連の情報を持ち込むことなく、出荷チェックを有効にできる。

Anthropicの現行skills documentationも、同じ基本的な利点を説明している。スキル本文は使用時に読み込まれる一方、永続的なプロジェクト指示はセッション全体で存在し続ける。Claude Codeは一部のスキルを自動的に呼び出し、他はユーザーが要求したときだけ呼び出せる。

Osmaniのライブラリは、この仕組みを従来型のソフトウェア開発ライフサイクル全体に適用している。現行リポジトリでは、仕様の作成、作業の小タスクへの分解、段階的な構築、振る舞いのテスト、変更のレビュー、安全な出荷といった活動に、8つのコマンドを対応付けている。

この一連の流れこそ、リポジトリの真の製品だ。個々の推奨事項は目新しいものではない。エンジニアはすでに、テストを実行すべきこと、前提を明確にすべきこと、無関係なファイルを触らないことを知っている。

問題は、プレッシャー下での実行にある。コーディングエージェントは、特にリクエストがスピードを強調する場合、目に見える完了を最適化する傾向がある。ユーザーが明示しなかった証拠、レビュー境界、運用チェックを省きながら、要求されたコードを生成することがある。

Osmaniはこの対応を「文章よりプロセス」と呼ぶ。有用なスキルは、行動を規定し、完了条件を定義すべきだ。望ましいエンジニアリング行動についてのエッセイをモデルに与えるだけでは不十分である。

テスト駆動開発を考えてみよう。リファレンス文書はテストを称賛し、その利点を説明するかもしれない。一方でワークフローは、失敗するテストを作成し、失敗を確認し、最小限の変更を実装し、テストを再実行してからリファクタリングするようエージェントに指示する。

これらの手順は、観測可能なチェックポイントを生み出す。ユーザーは失敗、成功した実行、最終的な差分を確認できる。したがって、このスキルは判断の一部をモデルの内部推論から、モデルの外部で確認できる証拠へ移す。

このライブラリは、「合理化防止」のガイダンスによってこのパターンを拡張している。これらのセクションでは、受け入れ基準を設けるにはタスクが小さすぎるとみなすことや、テストは後で追加すると約束することなど、よくある言い訳をあらかじめ想定している。エージェントがそれらを使う前に、指示が反論を示す。

これは珍しいが実用的な設計選択だ。言語モデルは、面倒な作業を省く理由を含め、もっともらしい説明を容易に生成する。あらかじめ書かれた反論は、望ましい境界をより明確にする。ただし、従うことを保証するものではない。

組織にとっての魅力は一貫性にある。チームはリリースチェックリストを一度だけコード化し、コードベースとともにバージョン管理し、複数のエージェントに提供できる。結果として生まれる指示は、1人の開発者が保存した私的なプロンプトではなく、レビュー可能な組織知になる。

これは検索可能なナレッジベースとも自然につながる。チームには依然として、各ワークフローが存在する理由を説明する設計判断、ランブック、技術的コンテキストが必要だ。スキルは、選別された知識を行動へと変換できる。

巨大なプロンプトが完全になくなるわけではない。どのハーネスにも、境界、リポジトリの慣例、安全性に関する常時適用のルールが必要だ。新たに見えつつある役割分担は明確である。永続ファイルには常に適用される事実を置き、スキルには特定の作業によって起動される手順を置く。

主な対立は、再利用可能なワークフローとモデルの判断の間にある

このリポジトリは、より優れたモデルなら明示的な足場なしにエンジニアリングプロセスを確実に提供できる、という考えに異議を唱える。

モデルの改善は引き続き重要だ。より強力なモデルは、より大きなコードベースを理解し、より多くのツールを呼び出し、難しい失敗から回復できる。しかし、生の能力だけでは、エージェントがどの手順を実行するかは決まらない。

モデルは設計文書の書き方を知っていても、それを省くことがある。コードレビューを理解していても、レビュー担当者が評価するには広すぎる変更を作る可能性がある。実践について知っていることと、一貫して実行することは別である。

Addyosmani agentのアプローチは、ユーザーの意図とモデルの行動の間に再利用可能なワークフローを置く。モデルは依然として実装の詳細を推論するが、スキルがその経路を制約する。タスクをまたいで安定しているべきフェーズ、チェックポイント、停止条件を定義する。

このアプローチは、独自のオーケストレーションに依存するベンダーに圧力をかける。チームが価値ある振る舞いを可搬なMarkdownで表現できるなら、エージェントの差別化の一部は隠れたプロンプトから、透明なワークフローライブラリへと移る。

リポジトリは、共通インストーラーを通じて70を超えるエージェントでスキルが動作するとしている。また、Claude Code、Cursor、Gemini CLI、Windsurf、OpenCode、GitHub Copilot、Kiro、Codex向けに、ネイティブまたは適応したセットアップも文書化している。

互換性は、同一の振る舞いを意味しない。あるプラットフォームは説明文に基づいてスキルを自動選択するかもしれない。別のプラットフォームでは、ユーザーが指示をルールファイルにコピーする必要がある。さらに別のプラットフォームでは、スキルをサポートしていても追加メタデータを異なる形で解釈する場合がある。

open specificationが標準化するのは、控えめな中核だ。SKILL.mdを含むディレクトリと、名前および説明を含むフロントマターを求める。スクリプト、リファレンス、アセット、互換性に関する注記、許可ツールの宣言は任意である。

この小さな共通分母は、利点であると同時に制約でもある。スキルを簡単に作成・確認できる一方、すべてのエージェントがリクエストをどうルーティングし、コンテキストを管理し、承認を求め、ツールを実行し、完了を証明するかまでは標準化できない。

Osmaniのリポジトリは、プラットフォーム固有のディレクトリとセットアップ文書によって、こうした違いを補っている。Claude Codeにはプラグインパッケージングが提供される。Gemini CLIにはネイティブインストールのガイダンスがある。Copilotユーザーは、ペルソナとスキルの内容をリポジトリの指示ファイルに合わせて調整する。

これは完全なランタイム等価性ではなく、翻訳による可搬性だ。ワークフローの意図は移植できるが、その強制力は移行先のハーネスに依存する。あるプラットフォームで必須として扱われる安全チェックが、別のプラットフォームでは助言的なテキストになる可能性がある。

ワークフローが外部ツールを呼び出す場合、この問題はより深刻になる。Markdownの指示は、テストの実行やブラウザの挙動の確認をエージェントに命じることができる。しかし、テスト環境を作成したり、ブラウザアクセスを付与したり、認証情報が隔離されていることを保証したりはできない。

したがってチームは、モデル、ツール、権限、フック、ワークスペース規則、監査証跡を含むハーネス全体を評価する必要がある。よく書かれたスキルは一つの層を改善するが、他の層の代わりにはならない。

この区別は、スキルと決定論的な自動化を分けるものでもある。継続的インテグレーションのルールは、テストが失敗すればマージをブロックできる。スキルはエージェントに先へ進まないよう指示できるが、別の制御が停止を強制しない限り、モデルやハーネスは処理を続ける可能性がある。

最も強力なアーキテクチャは、両者を組み合わせる。厳格なスクリプトでは対応しにくい柔軟な判断をスキルが導き、コンプライアンスを任意のものにできない領域では、フック、権限システム、保護ブランチ、CIチェックが境界を強制する。

このハイブリッドモデルは、エージェント導入における「プロンプトを改善すればよい」という考え方に疑問を投げかける。プロンプト設計は依然として重要だが、再現可能な本番業務には、バージョン管理された手順と機械検証可能なゲートが必要だ。トレンド入りしたこのリポジトリは、その移行を実現するための分かりやすい手本を示している。

Addyosmani Agent Skillsが実際に強制するもの

このライブラリはシニアエンジニアの習慣を順序立てた作業に変換するが、各手順は独立した権限ではなく、あくまで指示にとどまる。

現在のコレクションは、曖昧な要求から本番リリースまでの全工程をカバーしている。仕様策定スキルでは、実装開始前に前提を明らかにし、目標を明確化し、受け入れ基準を定義するようエージェントに求める。

続く計画ガイダンスでは、仕様を小さく検証可能なタスクへ分解する。この構造により、フィードバックが得られる前に生じる変更量を抑えられる。また、要件とそれを満たすためのコードの関係が、レビュー担当者にとっても明確になる。

実装スキルは、薄い垂直スライス、安全なデフォルト、フィーチャーフラグ、ロールバックしやすい変更を重視する。目的は単にファイルを小さくすることではない。変更と、ユーザーが確認できる証拠との距離を縮めることにある。

テストワークフローは、レッド、グリーン、リファクタリングの段階を用いる。まずエージェントは、想定どおりの理由で失敗するテストを書く。次に、成功に必要な最小限の動作を実装し、その後、結果を変えずに設計を改善する。

コードレビューでは、グリーンのテストスイートを超えて証拠を広げる。テストは想定ケースを確認できても、セキュリティ境界、分かりにくいインターフェース、過度な複雑性、意図しないスコープを見逃すことがある。レビューワークフローは、エージェントにこれらの観点を個別に検討するよう求める。

このリポジトリには、API設計、フロントエンド開発、セキュリティ、パフォーマンス、デバッグ、ソースに基づく開発、コンテキスト管理、廃止、移行に関する専門的な資料も含まれている。メタスキルがリクエストを関連する手順へ振り分ける。

そのリリースコマンドは、デプロイを単一のアクションとして扱うのではなく、最終チェックを調整する。これはOsmaniのより広い主張を反映している。エージェントが「完了」に至る最短経路には、その完了を信頼できるものにする運用作業が含まれていないことが多い。

多くの実践は、公開されているGoogleのエンジニアリングガイダンスに基づいている。リポジトリは、小さな変更、読みやすいテスト、慎重なAPI進化、早期検証、既存コードを理解してから削除することなどの概念を参照している。

これらは新しいエンジニアリング原則ではない。その価値は、パッケージ化とタイミングにある。エージェントは、一般的な学習データを適切な瞬間に思い出すことに頼るのではなく、判断を下す時点で対象を絞った手順を確認できる。

具体的なバグ修正を見ると、その違いが分かる。ワークフローのガイダンスがなければ、エージェントは疑わしい関数を見つけ、変更し、限定的なテストを実行して成功を報告するかもしれない。元の失敗が説明されないままでも、パッチは説得力があるように見える可能性がある。

デバッグスキルがあれば、エージェントは問題を再現し、証拠を収集し、競合する仮説を立て、それらを検証し、原因を特定し、回帰テストを追加し、修正を実装し、ユーザーに見える挙動を確認するべきだ。各ステップによって、見栄えはよいが誤ったパッチが入り込む余地が狭まる。

機能要求は、別の検証課題を生む。仕様策定ワークフローは、コードを変更する前に不確実性を表面化させるべきだ。二つの要件が衝突する場合、エージェントは最も簡単な解釈を黙って選ぶのではなく、確認のために停止すべきである。

この停止行動は、流麗に生成されたコードより重要だ。必要な質問を一つ行う有能なエージェントは、誤った機能を自信満々に構築するより強力なモデルよりも、安全であり得る。

ただし、指示ファイルだけでは、こうした改善が起きていることを証明できない。リポジトリの人気は、このパターンへの関心を示している。しかし、24のスキルすべてが、異なるエージェントやリポジトリで不具合、レビュー時間、インシデント率を低減するという統制された証拠は示していない。

Osmaniの5月の記事は、幅広い比較ベンチマークではなく、設計上の考察と経験を提示している。後のエンジニアリングワークフローに関するエッセイでは、各ステップが存在する理由と、確立されたソフトウェア実践をどう反映しているかを説明している。

この証拠は有用だが、範囲には限りがある。ライブラリを導入するチームは、流出不具合、差し戻された変更、レビューの待ち時間、テストカバレッジの変化、ツールコスト、不必要なエージェント停止の頻度を含む独自の指標を定義すべきである。

また、インストール前にすべてのスキルを確認すべきだ。指示ファイルはコマンドを要求し、ツール利用に影響を与え、補助資料をモデルのコンテキストへ取り込む可能性がある。人気のリポジトリを信頼済みの実行可能ポリシーとして扱うことは、このプロジェクトが防ごうとしているのと同じ近道を繰り返すことになる。

ポータビリティと検証は依然として難題

最大の不確実性は、ポータブルな指示が、異なるエージェントハーネス間で同等かつ強制可能な挙動を生むかどうかにある。

このプロジェクトは、再利用可能なワークフローについて説得力のある主張をしている。一方で、均一な実行についての主張は弱い。どのプラットフォームも、スキルの検出、コンテキストの組み立て、コマンド権限、失敗時の処理を異なる方法で制御している。

自動ルーティングは、ばらつきの一因である。スキルの説明は、いつ有効化すべきかをエージェントが判断する助けとなる。説明は重複し得るうえ、ユーザーのリクエストは複数のフェーズにまたがることが多い。ハーネスは、手順を読み込みすぎたり、誤ったものを選んだり、関連するスキルを見逃したりする可能性がある。

コンテキスト制限は、別のトレードオフをもたらす。段階的開示は恒常的なプロンプトの負荷を減らすが、有効化されたスキルは依然として注意資源を消費する。複雑な機能では、一つのセッション内で複数のワークフロー、補助資料、リポジトリの指示、コード、ログ、ツール出力が必要になる場合がある。

コンテキストは多ければよいとは限らない。関連する制約が実装の詳細と競合することもある。エージェントにコードについて慎重に考える余地が十分になければ、長い手順は表層的なチェックリスト消化を促す可能性もある。

ポータビリティには意味論的なずれも加わる。リポジトリは同じMarkdownをClaude Code、Cursor、Gemini CLI、Copilotにコピーできる。しかし、各モデルとハーネスは「must」「verify」「stop」といった語を異なる信頼性で解釈する可能性がある。

ツールの可用性も結果をさらに変える。ブラウザ検証ワークフローは、ブラウザにアクセスできなければ稼働中のインターフェースを検査できない。ネットワークアクセスが無効でローカルデータベースが古い場合、セキュリティレビューは依存関係の結果を検証できない。

権限がリスクの上限を決める。無制限のシェル、本番認証情報、デプロイ権限を持つエージェントは、優れたプロセス指示があっても損害を引き起こし得る。権限を狭く制限されたエージェントは、スキルを誤解しても制約を受け続ける。

これが、スキルが決定論的な制御を補完すべき理由である。ブランチ保護はレビューを必須にできる。CIは失敗したテストをブロックできる。サンドボックスはファイルとネットワークへのアクセスを制限できる。承認ゲートは、人間が正確なアクションを承認するまでデプロイを停止できる。

サプライチェーンリスクにも同等の注意が必要だ。スキルリポジトリは、権限を持つモデルの挙動を形作るコード隣接の設定である。更新によって、基盤モデルを変更せずに、指示、スクリプト、フック、参照ファイルが変わる可能性がある。

チームはレビュー済みのバージョンを固定し、差分を確認し、自動更新を制限すべきだ。トップレベルのSKILL.mdだけをレビューするのではなく、参照ファイルや同梱スクリプトを検証する必要がある。簡潔なエントリーファイルが、重要な挙動を別の場所に委譲している場合がある。

リポジトリ自体も、個別インストールにおけるポータビリティのギャップを認めている。READMEは、一つのスキルをインストールすると共有参照ディレクトリが省かれ、補足チェックリストを利用できなくなる可能性があると警告している。リポジトリ全体をインストールするか、必要な参照資料をコピーすれば、この特定の問題は回避できる。

この警告は、より広範な課題を示している。スキルは、動作コンテキストの一部を欠いたままインストール済みに見える可能性がある。エージェントはそれでも実行されるため、静かな劣化は従来の依存関係欠落より気付きにくい。

評価が最後のギャップである。チームには主観的な印象だけでなく、期待される結果が既知のタスクが必要だ。同じエージェントをスキルあり・なしで比較し、正確性、不必要な変更、ツール呼び出し、所要時間、トークン消費を調べるべきである。

導入は、限定的な課題から始めるべきだ。大規模なパッチに悩むチームは、スコープ規律とレビュースキルを試験できる。回帰が繰り返し発生するチームは、過去のバグを対象にテストワークフローを評価できる。

その結果によって、ワークフローを共有ポリシーに組み込むかを決めるべきだ。人気は調査の理由にはなるが、ローカルでの証明の代わりにはならない。このプロジェクトの最も強い教訓は検証であり、その教訓はプロジェクト自体にも適用されるべきである。

エージェントスキルがインフラになるかを示す三つのシグナル

次の段階は、測定可能な結果、クロスプラットフォームの適合性、そしてモデル自身の推論の外側にある強制力にかかっている。

第一のシグナルは、信頼できる比較評価である。メンテナーや独立したチームが、実際のリポジトリで再現可能なテストを公開するかに注目したい。有用な評価では、不具合率、スコープ逸脱、レビュー品質、コスト、完了時間を測定すべきだ。

好ましい結果は、選択されたスキルが、過度な遅延やトークン使用を招かずに、複数のタスクで成果を改善することを示すだろう。弱い、または一貫しない結果は、成功がワークフローのテキストよりもモデル、リポジトリ、評価者に左右されることを示唆する。

第二のシグナルは、エージェントプラットフォーム間でのより強い適合性である。共通仕様は現在、ファイル構造とメタデータを定義しているが、ランタイムには有効化と実行に関する大きな裁量が残されている。

進展には、検出、補助ファイルの読み込み、ツール制限、失敗時の挙動に関する共通テストが含まれる。Claude Code、Codex、Gemini CLI、Cursor、Copilotで同じスキルが比較可能なトレースを生むなら、ポータビリティは単なるファイル互換性を超えたものになる。

分岐した拡張機能は、この約束を弱める。ベンダーは同じSKILL.mdコアをサポートしながら、互換性のないルーティングフィールド、権限セマンティクス、パッケージングシステムを追加できる。その場合、チームは一つのワークフローについて複数のバージョンを保守することになる。

第三のシグナルは、決定論的なポリシーとの統合である。スキルのチェックポイントが、アクションを検証またはブロックできるシステムに接続されるとき、スキルはインフラになる。例として、必須のCI証拠、署名付き承認、サンドボックスポリシー、機械可読な完了記録が挙げられる。

この統合は、モデルに自己監視を求めることなく、柔軟性を維持する。スキルはタスクに適した検証経路を判断でき、外部制御はマージやデプロイの前に必要な証拠が存在することを確認する。

Addyosmani agentプロジェクトは、フック、コマンド、ペルソナ、検証重視のワークフローを通じて、すでにこの階層化アーキテクチャを示している。次の課題は、慎重に準備された例の外でも、これらの層が確実に連携することを証明することだ。

開発者にとって、当面の行動は一括導入ではなく、検討である。繰り返し起きる失敗に最も近いワークフローを読む。そこでのチェックポイントを既存のエンジニアリング制御と比較する。そして、権限を制限した状態で代表的な作業に一つ適用してテストする。

エンジニアリングリーダーにとって、このプロジェクトは、文書化されていない判断を棚卸しするきっかけとなる。シニアエンジニアの頭の中にしかないレビューの習慣は何か。どのリリースチェックが記憶頼みになっているか。どの例外が繰り返しインシデントにつながっているか。

そうしたプロセスの一つを、短くレビュー可能なワークフローに落とし込もう。失敗が重大な意味を持つ場面では、外部のゲートと組み合わせる。エージェントがそれに従うか、そして変更の信頼性が高まるかを測定する。

addyosmani agent skills をめぐる再び高まった注目は、Markdown によってAIコーダーをシニアレベルにできることを証明するものではない。これは、開発者がコード生成だけでは仕事のすべてとは考えなくなったことを示している。次の問いは、持ち運び可能なワークフローが、チームが依拠するに足るほど強い証拠を生み出せるかどうかだ。