GitHub Copilot、ChatGPT、またはCursorを使い始めた開発者は、皆同じ「ハネムーン期間」について語ることが多い。かつては

GitHub Copilot、ChatGPT、あるいはCursorを使い始めた開発者は、皆同じ「ハネムーン期間」を経験するとよく言います。かつて2時間かかっていたタスクが、今では20分で終わる。Tabキー一つでボイラープレートが消え去る。しかし、すぐにフォーラムやSlackチャンネルでは、静かな不満が上がり始めます。それは「疲労」です。ツールはコードを書いてくれますが、そのプロセスにおいて、何かがあなたを消耗させているのです。問題はコードそのものではありません。コードを「消費する」作業にあります。

誰も想定していなかったボトルネック

何十年もの間、ソフトウェアエンジニアリングにおける制約はタイピング速度でした。どれほど思考が速くても、指の動きと構文の知識が上限を決めていました。AIアシスタントはその上限を打ち破りました。最初のブロックを読み終える前に、複数のファイルにわたって数百行ものコードを生成できるのです。その速度は一見すると自由のように思えますが、予期せぬ交通渋滞を引き起こします。突然、パイプラインの中で最も遅い部分は、画面に現れたものを読み、理解し、検証するあなたの能力になってしまうのです。あなたは自分のプロジェクトのフルタイムのコードレビュアーになったのです。ただし、その著者は、眠ることも疲れを知ることもないアルゴリズムです。

この労働の逆転は、コーディングセッションの質を変えてしまいます。作成と軽い検証を交互に行う代わりに、あなたは長時間の「検証モード」に釘付けになります。そして、検証とは受動的な読解ではありません。それは、疑念を孕んだ能動的な分析です。AIには当事者意識がないため、変数名、境界条件、インポート文のすべてが、精神的なフィルターを通過しなければなりません。本番環境のジョブが失敗したとき、AIが午前3時に叩き起こされることはないのです。

なぜ脳は限界に達するのか

この疲労は怠慢ではありません。激流のようなアウトプットと、限られた人間の帯域幅（bandwidth）との間で起こる、予測可能な衝突なのです。

ボリュームの過負荷。 AIの提案は、一つの流れでReactコンポーネント全体、スタイリングロジック、ユーティリティ関数、そしてユニットテストまで含んでしまうことがあります。ワーキングメモリが一度に保持できる量には限りがあります。画面が数十行の新しいコードで埋め尽くされると、脳はそれらを抽象的なパターンへと圧縮するか、あるいは逐次的にスキャンするかのどちらかを迫られます。どちらの戦略も注意力を激しく消耗させます。こうしたブロックをいくつかレビューしていると、精神的な筋肉痛のようなものが現れます。読んではいるものの、もはや真に理解できていない状態です。

信頼のギャップ。 AIが生成したコードは、いかにも正しそうに見えます。インデントは完璧で、変数名は理にかなっており、コメントさえ適切な場所に配置されています。しかし、「もっともらしく見えること」と「正確であること」は別物です。そのコードは、非推奨のAPIを使用していたり、null入力に関するエッジケースを見逃していたり、あるいは巧妙なSQLインジェクションの脆弱性を持ち込んでいるかもしれません。こうしたことが起こり得ることを知っているため、飛ばし読みはできません。セキュリティ監査のような警戒心を持って、すべてのreturn文や論理分岐を検査しなければなりません。このような精査を何時間も維持することは、認知的なコストが非常に高いのです。空港の保安検査員が短い交代制で働くのと同じ理由です。持続的な警戒心はすぐに低下してしまうのです。

ワークフローの不一致。 ほとんどの開発環境やチームのプロセスは、依然として「人間が書いてからテストする」というリズムを前提としています。コードベースは人間のペースで成長し、コードレビューは予定されたバッチで行われます。AIがそのパイプラインに割り込むと、フローが断片化します。20行を生成し、検証のために手を止め、修正を依頼し、再び検証し、次の関数へと進むうちに、より広範なアーキテクチャの文脈を見失ってしまうのです。創造的な生成と懐疑的な検証の間で絶えずコンテキストスイッチングを行うことは、摩擦を生みます。あなたのIDEは「著者」のために設計されたものであり、絶え間ない締め切りの中で働く「編集者」のために設計されたものではないのです。

消耗のループ

これらの要因は、一日の進行とともに悪化していくサイクルを生み出します。

アシスタントは数秒で機能の実装を吐き出します。その後、あなたはインポートを辿り、型の互換性をチェックし、頭の中でのエッジケースのシミュレーションを行うために15分を費やします。3、4回目ともなると、集中力が鈍ります。「だいたい合っていそう」なスニペットを、つい受け入れてしまい始めます。エラーが紛れ込みます。それを補おうとして作業速度を落とすと、最初に得たはずのスピードが相殺されてしまいます。一日の終わりには、いつもより多くの生コードが手元にあるものの、それに対する自信は失われ、スマートに働いたのではなく、ただハードに働きすぎたことを示す頭痛とともに一日が終わるのです。

スピードが危険に変わる時

もしこのパターンが日常として定着してしまうと、そのダメージは単なる「嫌な午後」では済みません。

バーンアウト（燃え尽き症候群）は静かにやってきます。それは、プロジェクトを開くときの恐怖感や、パステルカラーでハイライトされたコードブロックをこれ以上見ることさえ苛立ちを感じる状態として現れます。助けてくれるはずの主要なツールが、疲労の主要な原因になったとき、恨みが生まれるのです。

次に、スキルの退化（アトロフィー）の問題があります。意図を構文へと変換する「筋肉」は、その作業を止めてしまうと弱まってしまいます。システムの設計は依然として巧みに行えるかもしれませんが、細かな習熟度——なぜ特定のループ構造に違和感があるのかを理解していたり、特定のライブラリが負荷のかかる状況でどのように振る舞うかを想起できたりといった能力は、オートコンプリート層が細部を処理するようになると衰えていきます。時間が経つにつれ、能動的なエンジニアではなく、受動的なキュレーターになってしまうリスクがあります。

しかし、最も差し迫った危険は、杜撰なデプロイです。開発速度を維持しなければならないというプレッシャーや、何時間も機械の出力を読み続けることによる疲労から、開発者が十分に検証していないコードをデプロイしてしまうことがあります。