思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析
(tabulamag.com)要点:
- AIツール（Claude Code、Cursor）の利用で開発速度は向上したが、速い作業テンポが脳の処理限界を超え、疲労感を引き起こす
- 頻繁なコンテキストスイッチとドーパミン過剰、管理者役割への転換が認知負荷を増大させる
- AIの速度に人間が引きずられる「機械時間」現象が起きており、主体的な速度調整の必要性が高まっている
序論
- AIツールの効用と副作用: 40年のキャリアを持つ開発者がClaude CodeとCursorを活用してパッケージマネージャー（Marvai）を開発し、生産性向上を経験した一方で、同時に前例のない疲労感を覚えた。
- 問題提起: 機能実装とバグ修正の速度は速くなった一方で、AIの速度に脳が追いつけず、短時間（1時間前後）の作業後でも消耗しきってしまう現象が発生している。
本論
1. 認知負荷の急増と「機械時間」の圧力
- 認知負荷理論の適用: Team Topologies理論によれば、過度な責任とトピックの切り替えは認知負荷を高める。AIコーディングはこの負荷を限界まで押し上げる。
- 機械主導のリズム: かつて工場労働者が機械の速度に合わせなければならなかったストレスと同様に、AIが主導する高速コーディングの速度に開発者が追い立てられる現象（「機械時間」）を経験する。
- 思考過程の消失: 従来のコーディングでは作業速度と思考速度が一致しており、脳が処理する余裕（Baking time）があったが、AIコーディングは複雑なアーキテクチャや意思決定の過程を一瞬で処理し、脳の同期を妨げる。
2. ドーパミン過剰とストレスホルモンの共存
- ドーパミンループの加速: 「コーディング→エラー→解決→成功」へと続くドーパミン報酬サイクルが、AIによって極端に速くなる。
- 感情的な消耗: 頻繁なドーパミン分泌と、速度に伴うストレスホルモンが同時に作用し、コーディングの楽しさではなく疲労と圧倒感を引き起こす。
3. コンテキストスイッチ（Context Switching）コストの増加
- 脳内キャッシュの過負荷: コンテキストスイッチは、脳のキャッシュを空にして再び満たす高エネルギー作業である。
- マイクロ・コンテキストスイッチ（Micro-Context Switching）: AIは複数モジュールを同時に修正したり、単純なタブ補完機能（
Tabキー）を使う場合でも、「記述モード」から「レビュー・モード」への頻繁な微細切り替えを強いることで、脳のエネルギーを急速に消耗させる。
4. 開発者の役割の本質的変化
- 書き手から管理者へ: 要件をコードとして実装する役割から、AIという「速いチームメンバー」の成果物を管理・レビューする「チームリーダー」あるいは「交通整理役」へと役割が変質している。
- 責任の非対称性: AIが5人分の作業を吐き出す一方で、開発者は依然としてコード品質に対する最終責任を負うため、管理負担が増している。
結論
持続可能なAIコーディングに向けた提言
- 意図的なペーシング（Pacing）: AIの速度に飲み込まれず、開発者が主体的に作業テンポを調整する必要がある。
- 新しいレトロスペクティブ手法の導入: AIと脳の同期を取るため、日次レトロスペクティブ（Retrospective）など新たな作業ルーティンが必要である。
- 役割認識の転換: AI出力を細かく統制しようとするマイクロマネジメントを減らし、AIをより信頼する方向へ作業スタイルを変える必要がある。
- 今後の展望: コーディングの未来は無条件の速度向上ではなく、人間の認知限界を考慮した「意図された遅さ」と新しい境界設定になる可能性がある。
14件のコメント
私も似たような経験があるので、こうしています。
例えば、リファクタリングをするなら、
「既存コードを分析したうえで代案を提示するよう指示」
「代案と既存コードの違い、長所と短所を要約して説明するよう指示」
「その代案が本当により良いのか検証できる方法を提案するよう指示」
「自分で代案を検証」
「代案の適用とドキュメント、テストの作成を指示」
問題は、トークン使用量が多くなりすぎて、コストがかなりかかることです...
単純な雑務でも、いっそマクロを作るほうが気が楽なんですよね……
人と人の間でも同じことがある。
人と人の間でもこうした問題はよく起こる。
考えるのが遅い人がマネージャーなら、
「仕事の進みが速すぎて大変で、一緒に働くのが難しい」と言い、
その人が部下なら
「話の飲み込みが悪くて、一緒に働くのが難しい」と言う。
結局、一緒に働くためにはお互いのケミが合っていなければならない。
コーディングを奪われ、コードレビューとテストだけをしなければならない苦痛…
私は個人プロジェクトを除いて、バイブコーディングは限定的に使っています。Cursorの自動補完に加えて、アイデア出しや同一パターンの反復コーディング程度にしか使いません。長期プロジェクトでバイブコーディングですべてを解決しようとするのは、開発者として無責任な行為だと思います。
プロンプトだけを書いて結果だけを出す人より、作業された結果のコードを理解して確認・レビューする人のほうが、より疲労感を覚えるようですね。
原文にもそう書かれています。
私は「AIのおかげで自分のやることが減って助かる」という感覚しかないので、こういう疲労感は一度も感じたことがありません。私は zed + claude を使っていますが、たまに途中で文脈が変わって妙な動きをするときもあります。そういうときは git でコードを戻して、「上の内容を総合して書き直して」と言えば、むしろもっときれいにしてくれるんですよね。自分でキーを打ちながらコードを書くわけではないだけで、頭の中にあった考えをコードにする過程が変わっただけではないでしょうか。むしろプロンプトを入力しながら考えが整理されることもあります。
コードで作る過程がブラックボックス化することで、コードと頭の中にあった考えを同期させる時間が必要になるのではありませんか?
従来のコード作成では、コードと頭の中にあった考えが一致していることが保証されますが、LLMを通じたコーディングではそれが保証されないのですから。
頭の中にはロジックだけあって、AIが書いたコードがきちんとできているかだけ確認すればよく、頭の中でコードを組み立てる必要はないのではありませんか？ プロンプトにどれだけ正確なデータを渡すかだけ考えればいいので、むしろ作業処理はかなり速くなりました。
どれだけ具体的にプロンプトを書くかによっても違ってくる気がしますね。擬似コードレベルでLLMに渡すのであれば、おっしゃっていることは理解できます。
以前は一日中コードを書いて仕事を終えると達成感があったのに、今では一日の業務のほとんどを会話でこなし、ほとんどの日はコードを1行も自分で書かないことが多いのに、燃え尽きてしまいました…。完全に共感します
私もまさにこの理由で疲労が増えました。そうなるだろうと予想はしていたので、疲れること自体は大丈夫なのですが、それよりも外から見ると、コーディングしながらキーボードを激しく叩いている時間がないので、ものすごく余裕を持って働いているように見えるみたいです。私が以前よりずっと疲れていると言っても、なかなか理解してもらえないんですよね……
ああ、私が疲れている理由をはっきり代わりに説明してもらった感じですね。
1. 「スピード感は活力になる」（肯定派）
2. 「バイブコーディングの定義論争」（用語の混乱）
3. 「検証のない速度は技術的負債だ」（慎重派）
4. 「コンテキストスイッチの疲労感」（共感派）
5. 「コーディングの楽しさの喪失」（ドーパミン不足）
6. 「初心者には毒、熟練者には薬」（習熟度による違い）
7. 「管理者役への強制的な転換」（役割の変化）
8. 「ビジネスロジック理解の欠如」（限界の指摘）
9. 「休息と余裕の消失」（機械の時間）
10. 「ツールの過渡期的な問題」（今後の見通し）