先月、小さな研究が話題になりました。開発者が AI 支援のあり／なしでどう働くかを測ろうとした研究ですが、壁にぶつかりました。参加者が集まらなかったのです。研究の一部として、しばらく道具なしでコーディングする必要があったからです。「できれば遠慮したい」ではなく、やろうとしませんでした。
そのくだりは、どんなベンチマークよりも記憶に残りました。数年のあいだに私たちは、「AI をワークフローに入れるべきか」で議論していた段階から、一部はそれなしでは席に着こうとしない段階まで来てしまいました。
先に正直に言うと、私もヘビーユーザーです。毎日コーディングエージェントと働いています。生産性は本物です。調査では導入率は 80% を超え、半分ほどは毎日この道具に手を伸ばします。私の一週間もその数字と変わりません。AI を使うかどうかという古い議論は終わりました。電卓のようなものです。証明のためにわざわざ筆算へ戻る人はいません。
ですからこれは、使うのを減らせという小言ではありません。もっと静かな違いについての話です。道具を使うことと、それなしでは働けなくなることは別です。前者はてこ、後者は依存。そして依存は、あとで利子を取り立てます。
守るべきはタイピングの速さではありません。思考です。ここで言う思考とは、何が「正しい」のかが分かるほど問題を理解することです。ドメインの形、つまりルールや状態、常に成り立つべきことを頭に入れておき、モデルがもっともらしい四十行を出してきたときに、それが正しいのか、ただ自信があるだけなのかを一目で見分けられること。私はフレームワークに触れる前にドメインをモデリングすると書いたことがあります。その習慣はいま、重要度が下がるどころか上がっています。エージェントは仕事の後半、つまり足場づくりや配線、ボイラープレート、そして意図を構文へ翻訳する作業を実に上手くこなします。何をなぜ作るかを決める前半は、いまもあなたの担当です。それを手放せば、もう運転しているのではなく、地図を読めない乗客になります。
誰も価格表に書かない項目、それが衰えです。使わない技能は鈍ります。道徳的な失敗ではなく、技能とはそういうものです。ループ全体がプロンプト、ざっと見る、受け入れる、再生成という流れになると、コードを評価する筋肉がいつのまにか弱ります。そして評価こそ、その答えを出した道具には任せられない仕事です。反対側にもコストがあります。コードはかつてないほど速く出てきますが、ある技術者の言うように、二倍速く書くなら保守も半分に減らせていることを祈るべきです。さもなければ、束の間の速さを長い義務と引き換えにしただけです。生成されたコードも、結局はあなたが引き受け、夜中の二時にデバッグし、次の人に説明するコードです。
いちばん気がかりなのは、始めたばかりの人たちです。スタンフォードのある分析では、22〜25 歳の開発者の雇用が 2022 年から 2025 年で 20% 近く減りました。雇用の数字はひとまず置くとして、より深い問題はこうです。かつてジュニアがシステムの形を学ぶ通り道だった足場が、いまではなぜその形なのかを理解する前に、代わりに済まされています。頭の中でモデルを一度も立てずに出荷できてしまう。そしてエージェントには見えない形で何かが壊れ、その場に地図を持つ人が誰もいない瞬間が来ます。
これは速度を落とせという話ではありません。片足は地につけておけという話です。私が守ろうとしていること、そして始めたばかりの人に伝えたいことをいくつか。
- 自分の手で作るものを一つは残しておく。仕事でなくてかまいません。サイドプロジェクトでも、手強いバグでも、最初から最後まで自分で回す何かであれば。
- diff は、レビューで弁護する前提で読む。実際そうなります。
- プロンプトを入れる前に、自分でドメインをモデリングする。渡すモデルが明確なほど、返ってくるコードも良くなります。あいまいに渡せば、自信満々の的外れが返ってきます。
- ルールは、あなたの記憶やモデルではなく、コンパイラとテストに持たせる。
- バイブ、それから検証。速く生成し、それから速度を落として実際に読む。
目標は AI を減らすことではありません。AI が正しいかどうかを見分けられるエンジニアであり続けることです。そして道具が止まった日も、モデルが大事な何かについて自信満々に間違えた日も、なおそういう人であること。てこは使ってください、すべて。ただ、あなたを聞くに値する人にしているその部分だけは、手放さないでください。