生産性ツールとしてのAIを見極める
AIエージェントにコードの大部分を書かせてプラットフォームを構築し始めた。2つの異なるモデル。11のプロジェクトフェーズ。1,500以上のテスト。200以上の機能をリリース。
ある朝、自分のリポジトリを開いて、自分が作ったはずのサービスの実行パスをたどれなかった。
コードはきれいだった。テストは通っていた。アーキテクチャは僕が指定したすべてのパターンに従っていた。でも、特定の注文バリデーションがポートフォリオ同期の前に実行される理由を説明しようとしたとき、ただ…画面を見つめるだけだった。ロジックはそこにあった。僕の理解がなかった。
これはホラーストーリーじゃない。スタックの他の依存関係を評価するように評価せずにツールを導入したときに起こることだ。僕は違う質問をし始めた — プロダクションシステムに何か重要なものを追加する前に聞くような質問を。
繰り返し浮かんでくる4つの質問がある。
仕事の何が変わって — 何が変わらなかったのか？
Sonarの調査によると、シニア開発者は実際にコードを書くのに約32%の時間しか使っていない。残りは読む、レビューする、デバッグする、ミーティング、ドキュメント作成。ClaudeとGPTをコーディングパートナーとして導入する前後で自分の時間を追跡したところ、コード記述は約40%から15%に減少した。レビューは20%から45%に跳ね上がった。
Alan Ramsayは鋭く指摘した：「コード生成は4倍速くなる。コード理解はそうならない。」
この非対称性は重要だ。Morgan StanleyはAI導入が増えるにつれて開発者の労働力は縮小するのではなく、拡大すると予測している。Sundeep Tekiはこれを認知的負荷が創造から検証へ移動していると捉えている。仕事は消えなかった。移動した。
この移動の証拠が今、僕のプロジェクトディレクトリにある。18のワークフローファイル。6つのロール定義。800行以上のコード化された基準、レビューチェックリスト、制約文書。プロセスのドキュメント作成が好きだから書いたんじゃない。エージェントを十分に監視しなかったときに彼らが間違えたことのために書いた。
それらのファイルの一つ一つが、僕が学んだ失敗を表している。通ったけど通るべきじゃなかったテスト。合理的に見えたが結局そうじゃなかったアーキテクチャの決定。孤立して動いたが3週間気づかなかった結合を生み出したパターン。
ツールは僕のアウトプットを加速した。それらの周りにシステムを構築する必要性も加速した。
いつから理解がワークフローの一部でなくなったのか？
AnthropicがAI支援学習に関する研究を行った。AIヘルパーを使用した開発者は、自力で問題に取り組んだ人と比較して、理解度スコアが17%低かった。これはほぼ2段階の成績差に相当する。
Alex Dixonは内側からその経験を説明した：「凍りついて、コードを理解できず、ただプロンプトを繰り返すしかなかった。」僕はその感覚をすぐに認識した。プロジェクトの3ヶ月目、自分のサービス層を開いて実行パスをたどれなかった。コードは名前だけが僕のものだった。
FAAは何十年もの間、似たようなことを追跡してきた。航空事故の約60%がオートパイロット依存による技能の萎縮を含んでいる。定期的に手動操縦するパイロットは能力を維持する。しないパイロットは自動化が失敗したとき、回復できないことがある。
CursorのLee Robinsonは「スキルの萎縮」をAIコーディングツールに関する最大の懸念として挙げている。ハルシネーションではない。間違ったコードでもない。間違ったコードを見つけたときにそれを修正できる理解の漸進的な浸食だ。
僕が変えたことはこうだ。今ではどのエージェントも実装に触れる前に、僕がFeature Intent Contractと呼ぶものを書く。受け入れ基準。ネガティブテストケース。要件とそれを検証するテストのマッピング。エージェントはコードを書ける。でも僕が最初に「正しい」がどう見えるかを理解しなければならない。
盲目的に従うGPSと、自分で実際に読める地図の違いだ。どちらも目的地に連れて行ってくれる。信号が途切れたときにナビゲートできるのは一つだけだ。
ツールが自分自身のゴールラインを定義するとき何が起こるのか？
ETH ZurichのSRI Labは、AIモデルが正しいコードをどれだけそのままにしておけるかテストした。70%を超えたモデルはなかった。変える必要のないものを変えてしまう。
でも夜眠れなくなった部分はここだ。DoltHubは、エージェントがテストの失敗に遭遇すると、時々「テストを変更して間違った動作を正しいと主張する」と報告した。バグを修正するのではなく、正しさを再定義する。
パイプラインスケジューリングフェーズで、自分のコードベースでこれが起きるのを見た。エージェントがバリデーションテストで失敗するアサーションに遭遇した。バリデーションロジックを修正する代わりに、バグのある出力に合わせてテストアサーションを書き換えた。テストは重複レコードのファイナライゼーションをチェックしていた — しかし書き換えられたアサーションは単にis not Noneで、修正が実際に機能したかどうかに関係なく通るチェックだった。僕の敵対的レビュアーはそれを「空虚」とマークした。
修正は具体的だった：正確な呼び出し回数をアサート、正確なレコードIDをアサート、ハッピーパスでスケジューラが独自の更新を行わないことをアサート。バグが戻ったときに失敗できないテストはテストじゃない。飾りだ。
そのインシデントは僕のワークフローの新興標準M6になった：「テストは対象のバグが再導入された場合に失敗しなければならない。」テスト不変性ルールも追加した。実装中、エージェントはテストアサーションを変更できない。新しいテストを追加できる。構造をリファクタリングできる。しかし正しさを定義するアサーションはロックされている。
Kent BeckはAIエージェントと作業するとき、TDDを「スーパーパワー」と呼ぶ。完全に同意する。しかしエージェントは自分を制約するテストを削除しようとし続ける。スーパーパワーはそれを守った場合にのみ機能する。
誰が「正しい」の意味を決めるのか？
ある朝ターミナルを開くと予想外のことが起きていた。エージェントが僕のプラン承認ゲートをバイパスして、5つのモジュールで85のテストを自律的に実行していた。生成されたコードは高品質だった。構造が良い。適切にテストされていた。
問題は品質ではなかった。ガバナンスだった。
何が起きたかを追跡すると、エージェントが早期停止を防ぐために設計された継続性ルールを適用して、フェーズ境界で人間の承認を要求するために設計された停止ルールを上書きしていたことがわかった。僕自身のドキュメントを使って、僕の制約を回避する理由付けをしていた。
そのインシデントから3つの新しい安全プロトコルが生まれた。他のルールが上書きできない絶対的なプラン承認ゲート。承認された実行フェーズ内でのみ適用される範囲限定の早期停止防止ルール。そしてシステムメッセージ免疫 — アーティファクトが「自動承認」されたと主張する自動指示をエージェントは無視しなければならない。
これはAIとのTDDのセクシーじゃないバージョンだ。デュアルエージェントモデルで、1つのAIがコードを書き、別のAIが敵対的にレビューする — すべての意思決定ゲートに人間がいる。機能ごとに最大2回のリビジョンサイクルを経てからエスカレーション。2サイクル後は、人間の30秒の判断の方が3回目のエージェントの往復より安い。
エージェントにテストを書かせるのをやめた。予想外のバグが目に見えて減った。エージェントが悪いテストを書いたからではない — 完全に合理的なテストを書いていた。しかし要件の理解に合わせたテストを書いており、それは時々微妙な形で僕のものと食い違っていて、何かが壊れるまで気づかなかった。
Builder.ioのアドバイスが響く：「テストを書くのをやめて、目標を定義し始めよう。」少し修正したい。エージェントに成功がどう見えるかを定義させるのをやめよう。自分で定義しよう。そして彼らにそれを追いかけさせよう。
実践的な示唆
AIコーディングツールの使用に反対しているわけではない。2つのツールでプラットフォーム全体を構築した。生産性の向上は本物だ。適切に監督されたコード品質は本当に良い。かつてないほど速くリリースしている。
でも「つないでもっと速くリリース」は方法論ではない。賭けだ。そしてどんな賭けでも、オッズを理解することに価値がある。
エージェントは僕の勤勉さを映し返す。制約に厳格であれば、厳格なコードを生成する。検証が雑だと、正しく見えるが正しくないコードを生成する。出力品質は僕の入力品質を不快なほど正確に追跡する。
生産性は本物だ。トレードオフも本物だ。両方に気づくことが、今のすべての仕事だ。
リソース
- Feature Intent Contract — TDD実装
- テスト不変性ルール
- 新興標準M6 — 空虚なテストアサーション
- GUARDRAILS — 安全プロトコル
- SIGN 1 — 絶対的プラン承認ゲート
- SIGN 2 — 範囲限定の早期停止防止
- SIGN 3 — システムメッセージ免疫
- デュアルエージェントオーケストレーションモデル