以前、小さな機能リクエストで最も高かったコストはコードを書くことでした。今は通常「そのコードを書くかどうかを議論するミーティング」です。

これは本当の変化であり、多くのエンジニアリングの本能を静かに壊します。エンジニアは早くから「小さな依頼」の多くは小さくないことを学びます。テスト、ロールアウト計画、エッジケースを考える人、リリース後の振る舞いを所有する誰かが必要です。2時間の変更でも、システムの間違った部分に触れれば2週間の混乱になる可能性があります。だから私たちは抵抗します。本当に必要なのか？このリリースに入れるべきなのか？すでに合意した契約を変えるのか？その本能は手放しません。

しかしそれは、静かに崩れつつある前提の上に成り立っています。つまり「コードの初版を書くことが高価なステップである」という前提です。特定の種類の変更については、もはやそうではありません。そのような変更とそうでない変更を見分けられれば、「これはスコープか？」という問いを、2日間の議論ではなく30分で答えられる質問に置き換えられます。

議論はパッチより高くつくことが多い

私がよく見るパターンがあります。誰かが小さな変更を依頼します。たとえば、バックエンドにすでに存在する last_active_at タイムスタンプを、設定ページに表示するといったものです。チームはスレッドで40分を費やします。一人はリスクが高いと言う。もう一人は2年前の関連マイグレーションを思い出す。誰かが締め切りを指摘します。結局「1〜2日かかるかもしれない、もっとかかる可能性もある」という、低い確信度の結論に落ち着きます。主な理由は、誰も実際に試していないからです。

そのプロセスは、「試す」ことが高価だった時代には理にかなっていました。やっていた作業を止め、コンテキストを頭に読み込み、手作業で変更し、テストを書き、2次・3次の影響を発見する必要があったからです。最初の試みが安価になった今、境界を守るコストが越えるコストを上回ることがあります。

エージェントは、スレッドが温まるのにかかる時間で初回のパッチを生成できます。無料ではなく、自動的に正しいわけでもありません。しかし「実際にdiffを見てみる」というのが賢明な選択になるほどには安価です。

初回のパッチは価格確認であり、製品ではない

よくある間違いは、生成されたパッチを成果物として扱うことです。そうではありません。それは探針（プローブ）です。抽象的なスコープ議論を、吟味できる具体的な成果物に変えます。

  • 想定通りのファイルに触れているか、それとも5つのパッケージに広がっているか？
  • テストは明白か、それとも変更はテストしにくいか？
  • 既存の抽象化を維持しているか？
  • 静かに新しいプロダクト判断を必要としていないか？
  • 6ヶ月後、この振る舞いを所有することに抵抗がないか？

これらは「これはスコープクリープのように感じるか？」という問いより優れています。なぜなら、感覚ではなく証拠に基づいて議論できるからです。last_active_at フィールドが4行のdiffと通過したテストとして返ってきたら、出荷しましょう。議論こそが高価だった部分です。一方、同じ依頼がauthミドルウェアに触れる形で返ってきたら、その依頼は最初から小さくなかったことがわかります。そして、それを2日ではなく30分で知ることができたのです。

これはAIに決定を任せることではありません。AIを使って人間の判断をより安価で、より十分な情報に基づいたものにするのです。

書くのが安いことと、所有するのが安いことは同じではない

ここに罠があります。そしてこれがAI時代で最も重要な区別です。変更が安いのは、コードの生成が安かったからではありません。人間が自信を持ってレビューし、所有できる場合にのみ安いのです。

技術的には通過するが誰も所有したくない1000行のdiffは、安い変更ではありません。それは先送りされたコストです。したがって、その場合の分水嶺は「エージェントがこれを書けるか？」ではなく、「人がこれを検証できるか？」です。

  • バックエンドにすでに存在する表示フィールドを追加するのは、通常安い。
  • 認可の振る舞いを変更するのは、diffがきれいでも安くない。
  • よくテストされたヘルパーをリファクタリングするのは、通常安い。
  • データ保持のセマンティクスを変更するのは安くない。

コードが些細であっても、依然として「ノー」とすべき変更はたくさんあります。製品契約を動かすもの、サポート負担を生むもの、プライバシー、請求、コンプライアンスに触れるものなどです。AIは候補を生成するコストを下げますが、候補を所有するコストは下げません。

スコープ規律を証拠に近づける

従来、スコープ規律は実装の前に置かれていました。なぜなら、実装こそが高価に守るべきものだったからです。今、一部の規律はレビューに移せます。それは計画を省くということではありません。実際に価値のある計画を正確にするということです。

小さな変更を再議論する前に、制約付きの試行を依頼してください。制約こそがすべてです。

可能な限り最小のパッチを生成する。既存のフィーチャーフラグの背後に留める。公開契約は変更しない。テストを追加または更新する。触れたすべてのファイルを列挙し、リスクのあるものを明示する。

エージェントがその制約の下でクリーンなパッチを生成できない場合、依頼は思っていたより大きかったのであり、誰かがコミットする前に、実際の所有コストを伴うことがわかります。生成できた場合も、何かを教えてくれます。いずれにせよ、「これはスコープか？」という問いを「これがコストです。払いますか？」に置き換えられたのです。

新しいスキルは不確実性の価格付けである

AI支援の世界で最高のエンジニアは、すべてに「はい」と言う人でも、反射的に「いいえ」と言う人でもありません。不確実性を素早く価格付けできる人です。ある依頼が「実装の衣をまとったプロダクト判断」であるとき、レビューが書くことより難しいとき、そして「試す」ことが最も責任ある早い答えになるほど小さな変更であるときを見極められます。

最後のものは本当に新しいものです。「試してみる」は、かつては他の作業から開発者を引き離すことを意味しました。今は、正しい種類のタスクであれば、エージェントに制約付きの作業を与え、その結果を使ってより良い判断を下すことを意味します。推測に費やす時間を減らし、監督に費やす時間を増やす。実装をブラックボックスとして扱う時間を減らし、具体的な成果物を評価する時間を増やす。

スコープクリープは依然として現実です。しかし「新しいコードはどれも高すぎるからノー」という主張は、2年前よりずっと弱くなりました。コードを生成するコストは下がりました。理解し、レビューし、所有するコストは下がっていません。だから問うべき質問は「これはもっと仕事か？」から「本当のコストはどこにあるか？」に移りました。そして時には、小さく制約された変更の場合、本当のコストは「試してみること」だけなのです。

「はい」と言うコストは変わりました。「いいえ」と言うコストも、それに合わせて変わるべきです。