Siddhant Khareの「AI Fatigue Is Real」を読んで、ここ数ヶ月のモヤモヤに輪郭がついた。
AIのおかげで手は止まらなくなった。そのはずなのに、一日の終わりにはぐったりしている。以前より多くのことをこなしているのに、充実感より消耗感のほうが大きい。自分の使い方が悪いのだろうと思っていた。でもどうやら、使いこなしている人ほど疲れているらしい。
AI tools increase productivity on individual tasks but create systemic exhaustion.
特に刺さったのが2つある。
頭の切り替えが追いつかない
AIがコードを生成する。速い。確認する。次のタスクに移る。また生成する。速い。次へ。気がつくと、午前中だけで5つのタスクを行き来している。
以前なら、ひとつのタスクに半日かけていた。コードを書いている時間そのものが考える時間だった。タイピングしながら設計を練り、手を動かしながら方針を固めていく。遅かったけれど、頭はそのタスクに没入できていた。
今は処理速度だけが上がって、脳のほうは古いままだ。
しかも厄介なのは、ひとつのタスクの中でも思考モードが切り替わることだ。自分でコードを書いていたときは「考える」と「書く」が一体だった。今は「指示する→読む→評価する→修正を指示する→また読む」と、創造と検証を高速に往復している。タスク間の切り替えに加えて、タスク内でも頭の使い方が目まぐるしく変わる。脳にかかる負荷の種類が根本から違う。
毎回「初めまして」のコードを読む疲れ
だが、私がいちばん疲れの正体を感じるのは、コンテキストスイッチよりもむしろ、AIが書いたコードのレビューだ。
人間が書いたコードには、癖がある。長く一緒に仕事をしていると、「この人はガード句を多用するな」「メソッドを細かく分割するタイプだな」というパターンが見えてくる。その癖を知っていれば、レビューのとき、ある程度の予測が利く。「ここはたぶんこういう構造だろう」という見通しが立つ。だからレビューは確認作業に近かった。
AIのコードには、その予測が利かない。
正確に言えば、AIにも癖はある。過剰に丁寧なコメントをつけたがるし、変数名が冗長になりがちだし、教科書的に正しいが文脈を無視した構造を作る。しかしその癖は、チームメンバーの癖とは質が違う。プロジェクト固有の「方言」を話さないのだ。同じ指示を出しても、出てくるコードの構造が毎回微妙に違う。命名規則が揺れる。抽象化の粒度が変わる。昨日はガード句で書いていたのに、今日はネストしたif文で返してくる。
毎回、初めて会う人のコードを読んでいる感覚になる。
人間同士のペアプログラミングなら、初対面でも、しばらく一緒に書いていれば相手のスタイルが見えてくる。次第に「こう書くだろうな」と予測が立つようになる。AIとのやりとりにはそれがない。人間の側に「この相手はこういう書き方をする」というメンタルモデルが形成されない。
毎回初見。毎回フルスキャン。これが地味に消耗する。
It increases the cost of coordination, review, and decision-making. And those costs fall entirely on the human.
生産のコストは下がった。でも判断のコストが全部こちらに来ている。
ここまで書いてみて、少し整理がついた気がする。
疲れの原因は「AIが速い」ことそのものではないのだと思う。速くなったのは処理であって、認知ではない。作る疲れから、読み解く疲れへ。予測できる疲れから、予測できない疲れへ。認知負荷の質が変わったのに、自分の中の「疲れ」の語彙が昔のままだと、「楽になったはずなのに、なぜこんなに疲れるんだろう」という問いが自分を責める方向にしか作用しない。
Khareの記事にはいくつかの対処法が紹介されている。AIセッションに時間制限を設ける、思考と実行の時間を分ける、70%の品質を受け入れる——どれも実践的だと思う。ただ、対処法の前に、まずこの疲れに名前をつけたかった。名前がつけば、少しだけ付き合い方が見えてくる。
少なくとも、「使いこなせていない自分が悪い」という漠然とした後ろめたさからは、自由になれる気がしている。
