Cursorのガイドを読んで、Claude Codeのデモを見て、頭の中で採算を計算して、やると決めました。チームに指示を下す―次のスプリントで試してくれと。2週間後、数字を見ると、lead timeは短くなるどころか伸びてしまった。トラッカーに奇妙なインシデントが次々と上がってきた。最高のエンジニア2人は「言ったでしょ」という顔で歩き回っている。レトロスペクティブでは「効果を評価するにはもっと時間が必要」という抑えた発言が聞こえてくる。実のところ、これは「その機能を削除してくれ」という意味だ。

Claude Codeのガイドとコンテンツ、ニュース配信（リミットが10倍カットされた時など）、およびClaudeを使って実装するプロジェクト用ツールに関するチャンネル：https://t.me/claudedevolper

見覚えがありますか？これはシステム管理を通じてエンジニアリングチームにAIを導入する典型的な風景です。問題はツールにはなく、モデルにもなく、懐疑派にもありません。問題は、プッシュモデル（強制）による導入がハイグレードの開発者に対してシステム的に機能しないということです―そしてあなたのチームが強いほど、うまくいきません。

このガイドではプルモデル（引き込み、エンゲージメント）について説明します。シニアエンジニアが自発的にエージェントとの作業を選択し、3ヶ月後には推進者になるような仕組みをどう構築するか。これはモチベーションスピーチでもなく、AIによるコードの割合に対するボーナスでもありません。これはエンジニアリングソリューション：ワークフロー、インフラストラクチャ、経験豊富な開発者のフィルターを通す導入段階について説明します。

なぜ強制モデルは失敗するのか

その誘惑は理解できます。トピックは熱く、ボードは質問を投げかけ、チームにはキラキラした目をした何人かのジュニアがいて、「生産性が3倍になった」というテーゼを掲げています。論理的なステップは標準化することです。全員にツールを配置し、メトリクスを導入し、四半期ごとに報告します。

その先に、誰もが予期しなかったことが始まります。

レビュープロセスが立ちふさがる。 PR量が増加し、レビュアーの負荷が天井に達します。生成されたコードは尤もらしく見えますが、「重く」、手で書かれたコードより読むのが遅い：多層構造、慣例との不一致、予期しない場所での明らかでない副作用。シニアがレビューに使う時間が、ジュニアが執筆で節約した時間より多い。純粋なマイナスバランス。

リリースサイクルが長くなる。 コードベースのアプローチの多様性が増加する―あちこちで異なるスタイルが混在し、すべてが同じリポジトリにある。アーキテクチャの決定は横断的な見通しなしに行われます。なぜなら、各自が独自のエージェントと独自のコンテキストを持っているから。数回の反復後、誰も明示的に投じなかった技術債が蓄積される―単に現れるだけ。並行して、インシデント数が増える：いくつかのバグは過負荷のレビューをすり抜けた。

最高の人材が静かに破壊活動を行う。 露骨ではなく―単に手でコード書き続ける、会議では「試してみましたが、私には合いませんでした」と言い、チャットではジュニアの熱狂に懐疑的に反応する。これは頑固さでもラッダイトでもない。その下には4つの具体的な恐れがあり、それぞれが合理的な防御反応です：

  • 職業的アイデンティティとの葛藤。 シニアエンジニアは、その価値が意思決定の質に基づいている人です。「タスクを説明し、生成されたものを受け入れる」というモードを提案されると、彼は技術ライター兼レビュアーとしての役割を与えられ、著者の役割はモデルに与えられます。スライドでどんなに素晴らしくパッケージ化されていても、これは役割の向上ではありません。これは低下です。
  • デスキリングの恐れ。 想像ではなく、現実です。3年間、主に生成を通じてコードを書き続けたら、アーキテクチャを頭の中に保つスキル、コードスメルを感じるスキル、正しいソリューションと似ているソリューションを区別するスキルはどうなるでしょう？
  • 自律性の喪失。 決定はトップダウンで下されたもの、ツールは押し付けられたもの、「AIからのコード割合」というメトリクスが頭上に浮かぶ。強いエンジニアが歴史的に働いてきたモードの完全な反転―そして実のところ、彼らの専門知識がそこから育ったモード。
  • 雇用保障への脅威。 「モデルに置き換わられる」ではなく―それはジュニアの恐れです。シニアのものはもっと微妙です：「もし私の価値が生成内容のレビューに縮小されるなら、私は相互交換可能だ」。シニアが足がかり強いほど、これを強く感じます。

プッシュモデルはこれら4つのポイントすべてを無視し、KPIを通じて押し切ろうとします。プルモデルは―設計要件としてそれらに頼ります。これがすべての違いです。

シニアが本当にAIに望んでいるもの

前のセクションの4つの恐れを180度反転させると、要件リストが得られます。ツールへのものではなく―作業モードへのもの。これはサブスクリプションで購入できる「機能」ではありません。これはワークフローのプロパティで、あるか、ないかのどちらかです。

シニアは解決策の著者であり続けたい。 レビュアーではなく、モデルのオペレーターではなく、生成されたものの受信者ではなく。著者。これは、エージェントがアーキテクチャの意思決定が下される前に含まれ、それを採択するのを手助けし、既に採択されたものを実装するのではなく、という意味です。パラドックスですが、エージェントの初期段階での投入―調査とブレインストーミングの段階で―「私はレビューに縮小された」という恐れを払拭します。なぜなら、このような状況では著者の役割は人間に残るから。調査では、エージェントは会話相手です。実装では―手です。反対ではなく。

シニアは、自分の専門知識が衰えるのではなく、強化されることを望んでいます。 ここは微妙な点です。強いエンジニアなら誰でも知っています：スキルは考える必要がある場所で成長し、考えるのをやめる場所で衰える。エージェントが「考える」を引き受けると、スキルは失われます。エージェントが「検索、確認、ルーチンの合成」を引き受け、考えることは人間に残る―スキルはエージェントなしより速く成長します。ワークフローはこれら2つのモードを明確に分離する必要があります。「エージェントがすべてをしたので、私はOKをクリックしただけ」ではなく、「私はエージェントを自分の思考を通して進めたので、結果としてコードで得られた」。

シニアはプロセスの個人的なコントロールを望んでいます。 「月曜日までに新しいツールを試してみてください」ではなく、「ここに可能性があります、あなたのペースで理解してください」。ここでのオプション性は―丁寧さではなく、設計要件です。エージェントが強制されれば、その欠陥は「言ったでしょ」という記録に入ります。選ばれたなら―同じ欠陥は自分自身の決定のコスト、システムの失敗ではなく、と認識されます。

シニアは、自分の役割がより置き換えやすいのではなく、置き換えられにくくなることを望んでいます。 これが最も反直感的な部分です。プッシュモデルは暗黙に伝えます：「あなたはすべてAIのオペレーターであり、あなたの間の違いは曖昧になりました」。プルモデルは逆を伝えるべきです：「導入後、あなたはさらに価値が高くなりました。なぜなら、エージェントとの質の高い作業は別のスキルだから、そしてあなたはそれを持っているが、ジュニアは持っていません」。パラドックスですが、現実は正にそうです：強いエンジニアのエージェント作業効率は弱いエンジニアより1桁高い。強いエンジニアは正しい質問をし、出力の欠陥を見つけ、スコープの境界を保つ、エージェントに根拠のない方向に連れ去られることはさせません。弱いエンジニアは―以前より速くゴミを生成する。

これら4つのポイントはマーケティングではありません。これは記事の残り部分のための技術仕様書です。次に、原則、ワークフロー、インフラストラクチャ、および展開段階を説明します―そして各セクションで、どのポイントがどのメカニズムで解決されるかを明確に示します。将来の導入で4つの1つが解決されなければ―それはシニアのフィルターを通過しません、残りがどんなに素晴らしくパッケージ化されていても。

主な原則：従属的プロアクティブポジションのエージェント

この公式を常に繰り返していますが、毎回、人々の目に疑問が浮かぶのを見ます：「つまりどうやって？プロアクティブということは自分でやるってこと？」。いいえ。これが―すべての鍵です。

ほとんどのデモとエージェント開発に関するブログポストは反対のモデルに基づいて構築されています：エージェントにタスクが与えられ、それを自分で分解し、自分で実装し、自分でPRを開きます。人は入口で定義し、出口で受け入れる。これを自律的ポジションと呼びましょう。これはTwitterではよく見えますが、実際のコードベースではうまく機能しません。シニアのフィルターを絶対に通りません。なぜなら、それはシニアが持たない信頼を必要とするから―そしてそれをどこから得るか、見当たりません。

従属的プロアクティブ―は別のモードです。2つの軸に沿って個別に分解します。

従属的―は、エージェントが決定を下さないということです。決定を下さない。アーキテクチャを選択しない、スコープを承認しない、隣接するモジュールをリファクタリングする必要があるかどうかを決定しない、明示的なコマンドなしでPRを開かない。すべての決定―人間のもの。これはシニアに自律モードにはない個人的なコントロールを与えます。そしてより重要なことに―彼にオーサーシップを保持させます。コード内のすべての決定は実際には彼のもの、モデルのものではなく。

プロアクティブ―は、エージェントが頼みを待たないということです。彼はコードベースを自分でまわり、自分で仮説をチェックし、自分で矛盾を提起し、自分で代替案を提案し、自分であなたが見落とした事に気付かせる。「プロンプトを待つ」ではなく―「ここにリスクが生じているのが見えるので、どうします？」

実生活での実践例―これは、シニア開発者が強いジュニアトレーニーと一緒に働く方法です。トレーニーは膨大な知識、瞬間的な速度、ゼロの責任を持っています。トレーニーは主導的―質問し、バリエーションを提案し、求められた以上に深掘りする。しかし決定は先輩が下します。トレーニーはレビュー承認なしでmainにプッシュしない、「ついでに」隣接するモジュールを書き直さない、自分がより良く知っていると考えない。彼は強化するリーダーの思考プロセス、置き換えるのではなく。

この類推は理解のためだけに機能するのではなく。それはワークフロー設計の基礎として機能し、他の何かの宇宙からアプローチを発明することなく。

ここで、デスキリングの主な恐れが払拭されます。エージェントが従属的ポジションにあるとき、人間が考え続ける。エージェントはコードベースの検索、仮説の検証、バリアント合成を引き受けます―つまり、スキルが成長しないルーチンです。そして考える―スコープ境界をどこに置くか、どのトレードオフが受け入れられるか、どの抽象化が正しいか―はエンジニアに残る。そのようなモードで半年後、スキルは衰えず、エンジニアが同じ時間でより多くのタスクを処理し、各タスクが彼に正に思考を要求するため、検索をいじることではないため、より速く成長します。

従属的プロアクティビティから、しばしば見落とされる2番目のプロパティが生じます：エージェントはプロセスに早期に含まれるべき。最初のコード行が書かれる前に。あなた自身が正確な答えを知る前に。「一般的には何をする必要があるか理解していますが、詳細には確信が持てない」というステージで。ここがエージェントが最大の価値を与える場所です―なぜなら、コードベースをあなたより速くまわり、同時にもっと多くのコンテキストを保持でき、20番目の説明質問にも疲れないから。

後からエージェントを含める場合―「XをするファンクションをI me書いてください」段階で―ジェネレーターとして使用しています。これがシニアの反発を引き起こすモードです。なぜなら、そこではエージェントは本当に著者を置き換えるからであり、強化ではなく。

従属的プロアクティブポジション―は設定ではありません。これは3つのもので組み立てられる構造です：ワークフロー、指示（コンテキストレイヤー）、および開発者の習慣。ワークフローはリズムを設定―エージェントがどこに入ってどこで停止するか。指示は境界を設定―何ができて何をすべきでないか。習慣は品質を設定―どの程度うまく彼と会話できるか。次に、3つすべてを1つずつ分解します。

ワークフロー

従属的プロアクティブポジション自体は―概念です。プロセスなしでは実現しません。ワークフロー―これが概念が日常的な実践に変わる場所であり、テックリードとして作成または既成のものを採用して適応させる必要がある主なアーティファクトです。

プロセスのアイデアは簡単です：宣言的コマンド（「ファンクションを書く」「バグを見つける」「テストを生成する」）の代わりに、エージェントとエンジニアはインタラクティブサイクルで移動する―タスクを調査し、仮説をテストし、バリアントを議論し、仕様とアクセプタンス基準を確定し、分解し、プロセスを破壊せずに干渉する機会を持ちながら部分実装し、中間レビューのチェックポイントを実施し、テストをカバーし、最後にPR前に最終レビューを実施する。

これは単なる美しい流れではない。これは各フェーズでエージェントの役割が異なる3つのフェーズだ。

Brainstorming. 最も重要なフェーズだ。ここでエージェントは対話者であり、実行者ではない。「フィーチャーXに取り組んでいる、ユーザーストーリーがある、受け入れ基準がある」という形で意図を受け取る。その後は質問と回答のモード。エージェントはコードベースをリサーチし、矛盾を指摘し、明確化の質問をし、代替案を提案する。出力はデザインドキュメントで、固定構造を持つ：目的、スコープ、non-goals、アーキテクチャ原則、コントラクト、リスク、decision log。

ここで「私はレビューだけに追い込まれた」という恐怖が払拭される。デザインドキュメントのすべての決定の著者は人間だ。エージェントは彼の思考を構造化するツールであり、代替品ではない。

Planning. デザインが固定されたら、「どうやるか」に切り替える。目的はタスクをスプリントに分割し、各スプリントに独自のスコープ、受け入れ基準、blast radiusの評価を持たせることだ。スプリント＝コードを動作しない状態に放置しない原子的な作業単位だ。このフェーズでは、エージェントが再度コードを走査するが、焦点は「何を構築するか」から「どこに置いて何に影響するか」へシフトする。この段階で、ブレインストーミングで見落とされた細かい点が頻繁に浮き上がる。

ここでシニアは実装のアーキテクトのままだ。計画を単独で書くわけではないが、すべてのターニングポイントを承認する。これこそが真の自律性であり、専門知識と意思決定権を通じて自らの価値を保つことだ。

Work cycle. plan → implement → review → fix → review → commitのサイクルをスプリントごとに繰り返す。各スプリント内では別々のセッション。スプリント間ではコミットが必須だ。以下が図だ。

spec‑driven development with ai workflow

レビューについては別だ。レビューは必ず別のセッションで行う。実装が行われたセッションと同じではない。1つのセッションでは、モデルは自分の結果に偏りがある。正直なところ、私たちと同じだ。別のセッションでは、偏りのあるセッションで見落とされたものを捉える。個人的には、目視によるレビュー以外に、異なるモデルを使って2つのセッションを並行して実行する。例えば、ClaudeとCodexだ。異なる問題を見つけ、これは客観的に品質を向上させる。

ちなみに、ここでエージェント時代のエンジニアの主要な新しいスキルが結晶化する。正確さ、明確な思考、体系性、そして忍耐力だ。「人間がレビュー→エージェントが修正」というサイクルは、何が悪いかを説明する能力があればあるほど機能する。木のような話をしたら、エージェントは藪に入る。雑で見当はずれな回答をすれば、杖をもらう。すべて生身の人間と同じだが、こいつはクビにできない。

スキル—これなしには何も機能しない

説明されたワークフローは素のモデルでは不可能だ。各フェーズは、どのフロンティアモデルも単独で示さない特定の振る舞いをエージェントに要求する。通常のインストラクション下では、それはコードを書くだろう。しかし、私たちが必要なのは、まず質問をして、次にコードベースを調査して、次に決定をファイルに固定して、初めてその後でコードを書くことだ。

これはスキルで解決される。エージェントが特定のモードに入るべき時点でロードされるコンテキスト命令を含む個別ファイルだ。技術的には修正されたシステムプロンプトだが、効果としては役割の変更のようなものだ。スキルの下では、モデルは通常の命令では通常行わない奇跡を起こす。

最小限の実用的なセット—3つのスキルだ：

  • brainstorm — エージェントを対話者モードに切り替える。意図を受け取り、リサーチし、チャレンジし、決定を固定し、出力はデザインドキュメント。
  • planner — 実装アーキテクトモードに切り替える。デザインドキュメントを受け取り、実際のコードに対して確認し、スプリントに分割し、出力は開発計画。
  • code‑review — レビュアーモードに切り替える。新しいセッションでスプリント実装の結果を受け取り、レポートを出力。

スキルはオープンアクセスで公開した：github.com/pridees/skillforce。互いに連動するように調整され、Claude Code、Codex、Gemini、Open Codeおよび他のいくつかのハーネス、AnthropicのモデルからOpenAI、Kimi、GLMまでテストされている。同じように機能する保証はない。モデルが異なり、ハーネスが異なり、コードベースが異なるからだ。しかし、出発点としては十分だ。その後、独自の仕様に適応させる。

インストール（インストールされたnodejsが必要な場合があります）：

npx skills add pridees/skillforceОбъяснить с
チームリードとして、各シニアにこれを一から組み立てるよう強制してはならない。主要な貢献の1つは、スキルとコンテキストレイヤーを集中的に準備し、リポジトリへの接続に便利な形式で準備することだ。これにより、シニアにとって大きな「参入税」が軽減される。別の方法では決してセットアップに到達しなかったであろう者たちのためだ。同時に、pushシナリオで見た、チーム内のアプローチの不一致を軽減する。

リポジトリに表示されるべきもの

チームリードは各プロンプトを知る必要はない。必ず知るべきは各フェーズの出力に何が表示されるべきかということだ。これがワークフローが機能していることを確認する主要なツールであり、模倣されているわけではないことを確認するツールだ。

Design document（brainstorm後）。構造：Understanding Summary、Non-Goals、Assumptions、Design Principles、Data Model / Contract、Runtime Behavior、Testing Strategy、Decision Log、Acceptance Criteria。

Development plan（planning後）。構造：Overview、Prerequisites、Sprint 1...N（各スプリントに目的、タスク、受け入れ基準、バリデーション）、Testing Strategy、Risks & Rollback。

リポに保存できるが、通常はリリースから数週間後に削除する。コードにバグが見つかった場合、コミットハッシュ、スペック、計画はデバッグのコンテキストをより迅速に復元するのに役立つ。

インフラストラクチャの準備

スキルは仕事の半分だ。もう半分は、リポジトリに存在し、エージェントが作業するたびにロードされるものだ。すべてが回転するハーネスと、エージェントがプロジェクトをどのように理解するかを決定するコンテキストレイヤーだ。

ハーネス

ハーネスは「インテリジェンス」（モデル）と「実行」（コードとテスト）の間のレイヤーだ。本質的に、これが「エージェント」を日常的な意味で言うもの—Claude Code、Codex CLI、Cursor agent mode、Open Code。その任務は「開発者に代わってコードを書く」ことではなく、制御されたSWEサイクルを閉じることだ。タスクの取得、コードベースの調査、計画、変更の実装、命令の同期化、ツールとMCP呼び出し。

主な要件は自分自身をチェックできる能力だ。エージェントサイクル内には、批判と自己チェックの段階が必要だ。コンパイラ、リンター、テストの実行。またはフックを通じて手動で設定する可能性。これなしでは、ハーネスはSWEツールではなく、単にオートコンプリート機能を持つ美しいチャットだ。

選択肢はあまりない。主流のオプションはClaude CodeとCodex CLI。どちらも第三者プロバイダーのモデルに切り替えることができる（会社で政治的に受け入れ可能な場合）。受け入れられない場合は、私の個人的なおすすめはPi。非常に拡張可能で、必要なすべてをセットアップできる。モデルについては、利用可能な最高のものを選んでください。フロンティアが利用できない場合、オープンウェイトでは、GLM/Kimi/MiniMaxレベルのモデルが現在かなり良く機能している。

チームリードとして、チーム全体に1回ハーネスを選択し、標準に固定する。異質性はここで悪だ。異なるハーネスは異なる命令フォーマットを読み、1つに合わせたコンテキストレイヤーは他のものでは機能しない。

コンテキストレイヤー

これはインフラストラクチャの心臓だ。ここに、コードベースを他のものと区別するすべての協定、規約、ガイドライン、スキル、パターンが存在する。最初の2ヶ月間で新しい開発者に渡すもの、それをエージェントにファイルを通じて渡す必要がある。

このレイヤーを次のように構築する：

/
├── .agents/
│   ├── rules/
│   │   ├── coding-guidelines.md
│   │   └── conventions.md
│   ├── skills/
│   │   ├── brainstorm/SKILL.md
│   │   └── code-review/SKILL.md
│   └── AGENTS.md
Объяснить с

次に、特定のハーネスのシムリンク：.agents/AGENTS.md → .claude/CLAUDE.mdまたは.agents/AGENTS.md → .codex/AGENTS.md。OSSエージェントは.agentsをそのまま理解するか、設定で名前を指定できる。

AGENTS.md — メインのエージェント命令。基本構造：プロジェクト定義、開発ルール（rules/への参照付き）、リポジトリ構造、スペック基準、コミット規約、赤フラグ（決してしないこと）、ビルドとテストコマンド、ドキュメントへのリンク。最小限の汎用テンプレート。開始できるものを個別のgistとして投稿した—gist.github.com/pridees/82eef0e1710196188492695baef20ee6。使ってください。スタックに適応させてください。

実質的には、AGENTS.mdは最初から手動で埋められない。もっと簡単な方法がある。エージェントにリポジトリとそのルールについてイントロスペクションを行い、@.agents/AGENTS.mdを更新し、構造を保持するように依頼する。その後、レビューして修正する。一度、チーム全体のために。

主要原則：「モデルは自分でそれを理解するだろう」

これは直感に反する事柄で、通常は数回のイテレーション後にのみ理解される。

セットアップの際のさそいは、すべてのケースをあらゆる状況で説明することだ。すべてのルール、すべての規約、すべての例外。そうしないでください。その理由は：

  • 膨大なAGENTS.mdはコンテキストウィンドウを占有する。各命令トークンは、タスクから奪われたトークンだ。ルールが多いほど、エージェントの解決能力は低下する。
  • 命令は実際のコードと矛盾する。現実は常に書かれた説明より豊かだ。エージェントはコードを見て、予測可能に見たように書く。そしてあなたは「ルールに従わない」ことに不満を感じる。
  • 命令的ルールは壊れやすい。「コントローラーはこのように書く」—しかし、コントローラーが違う場合は？「Xを使用しないでください」—しかし、1つの場所で実際に必要な場合は？各例外には命令の更新が必要だ。

はるかに強力なアプローチが機能する：エージェントとの作業の過程で詳細を明確にする、そして例の情報源として自分のコードを作成する。良好に設計されたモジュールまたは成功したフィーチャー実装がある場合は、ケースを説明し、これらのファイルを参照するだけだ。「ドメインレイヤーで作業するときは、src/domain/orderを例として見る」。指示ページの代わりに1行+実際のコードベースから実際の例を示す。

ルールについても同様だ。rules/の各ファイルにYou MUST readを書かないでください。REST-コントローラーに関する命令はドメインレイヤーでの作業には不要であり、その逆も同様だ。命令が関連するときの条件を説明するだけだ。モデルはそれ自体で理解するだろう。

繰り返されるパターンとプロンプト。あなたや開発者が何度も何度も発生し始めるものは、別のスキルに分離する。コンテキストレイヤーは生きている。チームと一緒に成長する。

チームリードとして、完璧なAGENTS.mdを一度書くことではなく、その進化のプロセスを作成することが仕事だ。誰かが（あなたか指定されたメンテナー）コンテキストレイヤーを最新の状態に保ち、チームからのルールとスキルのPRを受け入れ、繰り返し始めたものを追跡する。これは一度だけの活動ではなく、リポジトリの新しい儀式だ。CODEOWNERSのように、コンテキスト用だ。

チームへの展開方法

ハーネスが選択され、コンテキストレイヤーが組み立てられ、スキルがリポにある。次は最も難しい部分だ。インフラストラクチャをプラクティスに変え、先ほど説明したpushモデルに逆戻りしないようにする。

展開を3つのフェーズに分割する。各フェーズに独自のロジック、独自のメトリクス、すべてを台無しにする独自の方法がある。

フェーズ1。初期導入者（early adopters）

チームの中から、自分たちでこれで働きたいと思っている1～2人を見つける。説得しないでください。「チャンスを与えてください」ではなく。彼らが望んでいる—それは彼らが既に外で試し、素朴なアプローチに失望し、適切なワークフローに力を費やす準備ができていることを意味する。理想的な候補者は、成熟したスケプティシズムを持つシニア。情熱的な目を持つジュニアではない。

このフェーズでのタスクは「チームをAIに移行する」ことではありません。タスクは実際のタスクでワークフローを実践することであり、目に見える成果物を生み出すことです：design documents、development plans、素早くレビューでき、書き直しが必要ないクリーンなPR。本番に持ち込まれたいくつかの機能。これがあなたの証拠になります。

期限を設定しないでください。メトリクスを導入しないでください。このフェーズについてボードに報告しないでください。公開性はそれを必ず壊します — ボランティアは質ではなく報告のために働き始めます。

フェーズ2. 拡張

チームが信頼できる成果を出したら — 招待を開きます。「今度は誰もが試します」ではなく、「これが私たちが試したこと — 今は誰もが利用できます」です。リポジトリ内のスキルとコンテキストレイヤー、ドキュメント、おそらく1つの内部ミートアップ。同僚が経験から自分たちのやり方を示します。プレッシャーなしで。

その後 — 観察します。誰かはすぐに参加し、誰かは1ヶ月後に、誰かは3ヶ月後に。これは正常です。プルモデルは全員が1日で来ることではありません。プルは、自分自身で来ることです。

懐疑的な人たちに触れないでください。彼らのうち誰かは同僚の成果を見て参加するでしょう。誰かは — ワークフローが解決する壁に自分で当たった後に。誰かは — 決して。最後のシナリオにも対応する必要があります：すべての開発者がエージェントで働く必要があるわけではなく、全員にワークフローを無理やり適用しようとすることは — 新しい包装のプッシュモデルそのものです。

フェーズ3. 標準化

チームの70～80％がワークフローを安定して使用しているとき — 形式化します。それより前ではなく。AGENTS.mdはリポジトリに必須です。harnessは標準化され、スキルは集中管理されサポートされます。このフェーズでは — はい、要求できます。しかし要求は「AIを使用する」ではなく「リポジトリの規約を守る」という音になります。手で書く人 — もちろんです。重要なのは規約です。

決して「AIが書いたコードの割合」というKPIを導入しないでください。これは私が見たすべてのプッシュ実装における最も人気があり、最も破壊的なメトリクスです。それは正確に最適化する必要のないものを最適化し、ワークフローが保護することになっている行動を正確に奨励します。

メトリクスについて：

  • タスク開始からPRマージまでのリードタイム。 成長してはいけません。すぐに速度アップが見えた場合 — チームがAIに頼りすぎています。これも良くありません。このメトリクスの改善は、下記のメトリクスと一緒に考慮される必要があります。
  • レビュアーあたりのレビュースループット — レビュアーあたり1週間に何個のPRがあり、どのくらい時間を費やすか。プッシュモデルへの隠された逆戻りに対するあなたのカナリアです。チーム内の誰かが「やった — 送った」モードで生成し始めた場合（私たちが去った同じ行動）— レビュアーの負荷は他のメトリクスがこれを検出する前に天井に達するでしょう。
  • PR Rework Rate — 最初のレビュー後に実質的な変更が必要なPRの割合（化粧品ではなく、コメントではなく、ロジックの書き直し）。成長してはいけません。成長する場合 — ブレーンストーム/計画がスキップされており、ワークフローが「オンデマンド生成」に劣化していることを意味します。
  • Mean Time to Recovery — インシデントから復旧までの時間。チームが生成するコードをどの程度理解しているかを間接的に示します。ここはAI実装の最も狡猾なリスクです：コードはより速く書かれますが、著者がそれを完全に理解していない場合（自分が考えるより多くを委譲したため）— インシデントでそれが現れます。MTTRが成長する = デスキリングが実現された。ブレーンストーム/計画段階での人間の関与を増やす方向へワークフローを見直す必要があります。
  • スプリントごと2回、チーム内で簡単なポーリングを実施してください。 1つの質問：「ワークフローはどの程度仕事を助けたり妨害したりしますか？」。NPS形式。数字は重要ではありません — ダイナミクスが重要です。

測定しないこと：

  • AIが書いたコードの割合。無意味なメトリクス。自明に最適化でき、害を奨励します。
  • 生成速度。ツールを測定するもので、生産性ではありません。
  • PRのコード行数。エージェントはソリューションを膨らませる傾向があり、このメトリクスはまさにそれを奨励します。

有害なアンチパターン

プルモデルを1ステップで壊すものの簡潔なチェックリスト：

  • 実装の期限。 「四半期末までに全員が使用する」= プッシュ。
  • KPI「AIが書いたコードの割合」。 既に説明しました。
  • 公開比較。 「VasyaはエージェントのためにVasyaを2倍速くしました」— Vasyaが追放者になり、残りが意識的にサボタージュを始めることの保証。
  • 手書きを禁止する。 タスクが小さいか明らかな場合 — ワークフローは過剰です。禁止 = 無意味なフラストレーション。
  • 初期採用者に他の人を教えるよう強制する。 彼らのタスクは結果を生成することであり、伝道者ではありません。伝道は有機的でなければならず、そうでなければ反発します。
  • 外部からメトリクスを受け入れる。 実装の標準がチームの上のレベルから来る場合 — チームがない場合、ワークショップがあります。自律性を保護してください。
チームリーダーとしてのあなたの貢献はここでは実装の速度ではありません。3～6ヶ月後、チーム内に成熟したエンジニアリング慣行が成長する必要があります。焦げた集団がイタリア人のストライキ状態になっていてはいけません。

フィナーレ

実装から数ヶ月後、あなたは振り返り、奇妙なことを理解します。最も価値のある結果は、増加したタスク数ではなく、短縮されたリードタイムでもなく、満足したシニアでもありませんでした。最も価値のある結果は、チーム内の思考がどのように変わったかでした。

エージェントが従属的な主体的な立場で正しいものを提供するために — 私たちは以前よりも正確に意図を定式化することを学ぶ必要がありました。「何を」構築しているのかについてより深く掘り下げ、「どのように」から目を離さない。最初の行が書かれる前にタスクを分解する。スコープを参照して、言葉で固定する。次の反復で杖を得ないようにレビュー内の議論を定式化する。「今すぐ自分で速くやります」の代わりに忍耐強くサイクルを通す。

これらのスキル — 正確さ、思考の明確さ、体系性、忍耐 — が主な獲得です。それらはツールからの贈り物ではありませんでした。ワークフローが毎日それらを要求したため成長しました。人工知能は既に私たちの日常的なタスクを解決するのに十分優れていますが、鮮やかに強調表示するのは、私たちが床の下に掃き込んでいたこと — 私たちが互いに思考と意図をどのように伝えるか。

そして、だからこそ、いくつKPIを導入しても、プッシュモデルはこのような結果を与えることはありません。強制は工学者から著作権を奪い、思考を生成で置き換えます。関与 — エージェントなしで機能するより厳しく思考を機能させます。違いは速度ではありません。違いは1年後にチームに何が起こるかです。

チームリーダーとしてのあなたの役割は、これが可能なスペースを作成することです。スキル、コンテキストレイヤー、デプロイメントフェーズ、外部メトリクスからのチーム自律性の保護。シニアが自分で対処します。だからこそ彼らはシニアです。

Claude Codeに関するガイドとコンテンツを含むチャネル。ニュース（制限が10倍削減される場合）とClaudeを介してプロジェクトで実装するツールをアップロードします。チャネル：https://t.me/claudedevolper