LLMバーンアウトが来た気がする
(alecscollon.com)- 仕事と個人作業で Claude Code、Codex、ChatGPT、Geminiを毎日使うようになり、数年前よりAI生成テキストを読む時間が大きく増えた
- 開発フローは自分で設計・実装していた方式から、設計を説明 → LLMが書いたコードをレビュー → 自分で修正へと変わり、未知の領域でも以前より作業しやすくなった
- 現在のプロジェクトも 大規模な教師なしコード生成 フレームワークとQwenエージェントの出力レビューが中心で、LLMコンテンツを読み続ける構造になっている
- およそ1年間使い続けたあと、ここ数か月で 誤った前提, 幻覚、断定的な短文、過剰な絵文字のような反復パターンが負担として積み重なってきた
- 問題の核心はLLMそのものより、同じ文体と同じ種類の誤りが繰り返されることによる疲労であり、パーソナライズ機能があっても他人が作ったAIコンテンツのスタイルは制御しにくい
開発フローの深いところまで入り込んだLLM
- 自分のLLM利用量は、今の開発者としては平均的で、使い方もまだ原始的なほうだと考えている
- 一度に1つの作業を処理し、会社では Claude Code、自宅では現在 Codex と対話している
- アシスタントにコードを書かせるときも、出力は丁寧に読んで理解したうえで自分で修正する
- 自律エージェントやエージェント・オーケストレーションを深く使う段階ではない
- 作業スタイルは、コードの設計と実装を自分で進める形から、設計をLLMに説明し、LLMが作ったコードをレビューしてから再び自分でコードを書く形へと変わった
- その過程で、見落としていたり知らなかったりしたアプローチに触れる
- 深い知識がない領域でも、より気楽に作業できる
- 現在の中核プロジェクトは、コードベース内で 大規模な教師なしコード生成 のためのフレームワークを構築することだ
- Claudeでツールを作っていないときは、教師なしエージェントである Qwen の出力をレビューしている
- どちらにしても、LLMが作ったコンテンツを読み続けることになる
- 情報を探すときも、特定のサイトを知らなければChatGPTに尋ねたり、Geminiの概要を読んだりすることが多い
- LLMの回答が間違っていれば、結局ブラウジングに戻る必要がある
- 検索結果に役に立たないAI生成記事が多いときは、日常的な質問に関してはLLMの回答でも十分だと感じている
同じ文体と同じミスが積み重なっていく疲労
- こうした使い方は約1年間続いており、今すぐやめるつもりはない
- LLMを使うと、より生産的だと感じる
- LLMを効果的に使う方法を学び続けることにも価値があると思っている
- ここ数か月で、LLMの出力を読む感覚が変わってきた
- 読む前から、どんな文体やどんな誤りに出会うか分かってしまう感覚が負担になっている
- 繰り返し目にする要素は、誤った前提、幻覚、断定的な短文、過剰な絵文字だ
- それぞれの不快さは個別なら耐えられるが、一緒に何度も繰り返されることで、LLMの文章そのものにすぐうんざりしてしまう
- 核心は、LLMが人間より悪いという非難ではなく、反復性 にある
- 人間も信頼しにくかったり、煩わしかったりすることはある
- LLMは同じスタイルで書き、同じ種類のミスを繰り返す
- インターフェースが対応していればパーソナライズ機能は使えるが、独特の文体の一部は残る
- 他人が生成したコンテンツのスタイルは自分では直接制御できない
- まだこの感情をどう扱うべきかは分からず、不安定なツールへの苛立ちを超えて、文章のパターン自体がずっと気に障る状態になっている
2件のコメント
私も、LLMが返す虚偽の前提、ハルシネーション、断定的な短文、過剰な絵文字パターンに苦しんでいましたが、
ELI5 Ruleを作って適用したことで、その苦しみから抜け出せました :)
https://github.com/amebahead/explain-like-iam-five-rules
Hacker News の意見
バーンアウトとまではいかないが、LLM が生み出すプレッシャーのせいで本当に疲れる。誰も仕事量を増やせと迫ってくるわけではないが、常に自分の「クランカー」や他人の「クランカー」が作った何かがあり、自分が詰まっているところを解いてくれる状態にある。
LLM 以前でも追いつくのは大変だったのに、今では待機中の仕事が常に10倍くらい増えた感じがするし、みんなが「最適化」して AI に並列でさらに速く仕事を食わせれば、また10倍になるかもしれない。あらゆるもののボトルネックとして立ち続けるのは疲れる。
小さなサイドプロジェクトやアイデアを形にするのは楽しいが、LLM が「休むのは時間の無駄」という不健全な考え方をさらに助長していることに気づき、正さなければと感じた。
この記事の核心的な不満は、工場の自動化のときにも似たものだったのだろう。熟練した多様な手工業が、組立ラインの一か所で一日中同じ動作を繰り返す仕事に変わったように、LLM も創造的で変化のある部分を持っていき、反復的なQA のハンコ押しだけを残した。当時使われた緩和策を、今あらためて探してみることはできるかもしれない。
少し前にチームメンバーがLLM 生成文書30個ほど入った zip ファイルを送ってきて、すぐレビューしてほしいと言ってきたが、その多くは繰り返しだったり、脈絡のない捏造・幻覚内容だった。生成速度はレビュー速度よりはるかに速い。
以前はプロジェクトマネージャーが企画文書を作るのに1日のかなりの部分を使っていたが、今では数分で作ってレビューに投げられるので、本当に疲れる。
「逆ケンタウロス」は新しいものではない。前世紀の労働運動に聞けばいい。
複雑なソフトウェアを使うより、プロダクトを作ることが好きなソフトウェアエンジニアだから、なおさらそうなのだと思う。何かを作り出す感覚がモチベーションで、機能を完璧で完成された状態にしたい。だが UI 作業では、95% から 100% に行く道のりが長い。
だから残念ながら、今は勤務時間がずっと長くなっている。
そのため、生産的な仕事を止めて、一定割合の時間を割き、「トークン使用量を見せるために AI をやる」必要がある。仕事量はそのままか増えているのに、AI の神々をなだめるために、実際に働ける時間が N% 減っている。
自分の経験では、バーンアウトの原因は大きく3つある。第一に、マルチタスクが最も大きい。別々のことをしているエージェントのウィンドウを3〜5個、頻繁に行き来しなければならず、各ラウンドに数分ずつかかると極度に疲れる。
コーディングエージェント時代の前は、ほとんどの開発者が一つのことに2時間以上集中する機会を持てていたはずだ。今やコーディングエージェントは扱える技術スタックの幅を広げたが、深く働くための帯域は増えていない。
第二に、エージェントは衝突なく動くようにするのは得意だが、正しいコードを作る保証はない。基礎知識のある人間の専門家とはかなり違う。
第三に、AI が生成した低品質な PR の山をレビューするときに挫折する。集中力は有限の資源だ。他人の仕事にエネルギーを使いすぎたくはないが、もっと気を配らないと、人間の書き手による慎重な思考と設計なしに作られた無責任な AI コードが、プロジェクト全体を急速に壊していく。慎重さに欠ける人たちと働くのも大変なのに、コーディングエージェント時代には彼らが10倍のゴミを作り出すので苦痛も10倍になり、簡単には強制できないチーム文化の問題でもある。
Opus の出力を何時間も読んでいると、少し体調が悪くなる感じがし始めた。この記事は本当に刺さる
チームにも不満を言い始めたのだが、少なくともエージェントのルールに個人用スタイルガイドを入れて、em dash、「X ではなく Y だ」式の表現、名詞の前に修飾語を長々と並べるやり方、「land」を完了の意味で使うことなどをなくすべきだと思う。これが未成熟な LLM の一段階にすぎないことを願う
人間としては、gate は開いているか閉じていて、施錠されているかいないかで、その先の道が通れる場合も通れない場合もある「門」だと分かっている。gate があるという事実だけでは、開いているのか閉じているのかは分からない
ところがボット式の表現では、gate は通過不可能な強い遮断物だけを意味する。柵や壁、さらには溶岩の堀のようなものとして使う
しかし gate は本来、通れるように設計された物なのに、ボットは通過不可能であることを意図した障害物にも同じ言葉を使う。現実で何十年も gate を扱ってきた基準からすると誤用だ。普通、閉じた gate に出会ったら開けて通ればよい
ボットにその単語の使用を避けるよう指示しても、ときどき無視する。今日思い浮かんだ問題語が gate というだけで、昨日は別の単語だったし、明日はまたまったく別の単語になるだろう
全体のパターンは、そもそも合ってもいない反復的で耳障りな低品質の専門用語だ
「単なる契約作業者のナイジェリア英語」という説明とは違って、モデルたちは強化学習の圧力の下で、超簡潔で過度に様式化された自分たちだけの方言を作っていっているように思う。だんだんコードで書いている感じに近づいているが、ここで言うコードはコンピュータコードではない。単語が人間にとって意味することと、正確には同じではない
arc landは Phabricator のせいで脳に刻み込まれているので、その用語が LLM より前からあったことは分かっているが、それでも狂いそうなほど気に障るこうした言語的な揺らぎは元に戻せない。LLM 入力を 100% フィルタできたとしても、人々自身が「land」をより頻繁に言うように学習している
今、LLM しか使わない人とプロジェクトをしているが、疲れるし精神的に消耗する
何かにフィードバックをすると、返事はただ「Claude に聞いてみるよ」だ。その人は全体がどう動くのかを理解しておらず、コードの大半にもそれが反映されている
数日前には、ローカル環境を設定して環境変数を決める方法すら知らず、デモモードをハードコードで入れていた。Claude がなぜそれを知らなかったのかも混乱するが、プロンプトの問題かもしれない
私は LLM の使用を制限し、使うとしても極めて具体的な作業にだけ使おうとしている。自分にはそのやり方だけが通用する
企業が AI コード生成をどうしてここまで推し進められるのか、正直理解できない。小さなプロジェクトでも、プロジェクト理解はすぐに追いつかなくなる
今では LLM コーディングが好奇心のない人を助長し、深く考える人を罰するので、こういう人たちがうまく生き残れるようになった
一方で友人は、何かを作るためにエージェントのトークンに1日1万ドルを使っている。とても賢く、元開発者なので、単純な AI 精神病のようなものではない
いまだに理解しようとしているところだ。もちろん自分には1万ドルはない
本当に疲れる。LLM と仕事を始めてから、ソロ開発者としてのアウトプットは軽く 20倍 には増えた。以前なら一人で引き受けるには野心的すぎたであろう顧客プロジェクトまで完了させている。
古いコードベースには、何か月も引きずっていたり、もっと長く企画段階にとどまっていたりした機能が入っている。全体の品質もずっと上がり、テストカバレッジもより完全で、正直に言って良くなった。
個人プロジェクトもものすごい速度で作っている。役割が逆転して、エージェントを自分が顧客であるかのように扱い、エージェントが自分であるかのように振る舞わせている。もちろん私は、より技術に詳しい顧客としてアーキテクチャの方向性を与える。エージェントが作ったアプリやツールを毎日使っていて、自作ツールのおかげで SaaS のサブスクも解約した。
ツール呼び出しを見て、主要なコマンドラインツールをもっとよく知る必要があると感じ、毎日少しずつ追いつくための学習計画も立てた。最初に vim と tmux を使ったとき、何も分からずに入れておいた古い設定も見直している。
理論上は生産性を以前の水準に保って本をもっと読むこともできるはずだが、できそうにない。「仕事は減る」という約束とは違って、現実には生産性と期待値が上がっていく 巨大な転換期 にいるように感じ、産業革命が適切な比喩のように思える。
期待値の上昇は大小さまざまな形で起きる。エージェントがデータ表現をあまりにうまく整えるので、以前ならかなりの時間がかかったであろう、きれいで視覚的インパクトのあるレポートを、今では当然のように送っている。
だが疲れる。Fable がサブスクで提供されている窓口が API 専用に変わる前に、できるだけ多くのことを片付けようと全力疾走している。人々がどうやってそんなに多くのトークンを使っているのかも理解できない。ほとんど寝ずに、可能な限り多くのコードを Fable に回しているのに、20x max プランの上限にはほとんど届かない。
下がったらペースを落とすと自分に言い聞かせてきたが、今度は12日まで延長され、枠もリセットされたので、あと数日はバックログを片付けられるようになった。夜通しロボットたちを忙しく動かしておかないと、朝起きてすぐレビューできないと感じる。スマホでエージェントに指示を出している自分も、我ながら変だと感じる。
外から見ると、これは製粉所で機械工として働いていた私の父に似て聞こえる。彼の仕事はほとんど、機械が動くのを見守り、壊れたら直すことだった。90% の時間はうまく動いていた。
手作業から機械を見張る側に変わると、本当に退屈に見えることがあり、その観点ではここでの AI への反感も理解できる。
仕事で AI 生成コードを大量にレビューするのが疲れるという点には、誰もが同意できるはずだが、なぜその不快な状況を一日全体にまで広げるのかが気になる。
それとも、ただ手でコードを書き、複雑になったらホワイトボードの前で考え、この50年以上ソフトウェアエンジニアリングがやってきたように、もっと人間的な速度でゆっくりバーンアウトすればいい。
なぜこれが選択肢なのか分からない。真面目に聞くが、自尊心は少しでもあるのか？「でも上司が AI を使うことを期待している」という言い訳が出てくると予想している。大半は本当のバーンアウトを経験したことがないのだろう。いざ来たら、とてつもない苦痛が来る。自分を機械にしてはいけない。人間は機械ではない。
バーンアウトはしていないが、投稿者と似たような働き方をしている。LLM が生成したコードをレビューする流れを、自分で書くより速いワークフローにはまだできていない。
このジレンマから抜け出す道は実際には2つしかない。生成されたものを盲目的に信頼するか、考え得るすべてのシナリオを検証する異常に膨大な 単体テスト 群を作るかだ。
だからビジネスロジックは自分で書き、それ以外の多くの部分を LLM に任せている。ボイラープレートも後者に入る。
敵対的テスト は、AI を軌道に乗せたままにし、読むべき差分をきれいで簡単なものにする最良の方法だ。TDD 的に「このバグを示すテストを書け」とする方法も、事後に「新しいテストでこのパッチが間違っていることを証明せよ」とする方法も当てはまる。
より良い方法は、より強い型付け言語を使ってがっちり固めることだが、テストはどんな言語でも書ける。TDD と「テストをすべて書け」という背景が、AI と仕事をするときの秘密のソースのように感じる。
テスト、テンプレート、一部の UI、装飾要素のようなものはざっと見て時間を節約する。だがバックエンドシステムに入るコードの大部分は読む必要がある。
個人的には、LLM の魔法に最も熱狂している人たちは、コードを書けなかった人たちだ。今では最善のコードではなくても、動く何かを持ってこられるようになったからだ。動くコードを作れるようになったので、全員をより良くすると思っているが、そのゴミが保守可能なのか、そもそもゴミなのかさえ分かっていない。
私がLLMバーンアウトを感じる理由は、上位モデルが明らかに去勢され、不透明にダウングレードされていることに向き合わなければならないからだ
12か月前までは、AI企業は平凡なモデルから最高の結果を絞り出すことに躍起になっていた
ところが上位モデルが進化すると、同じ企業たちは今度は、あまり露骨にならない範囲で計算量、つまり1つの結果を作るコストをできるだけ減らす方向に努力を変えた
この36か月間、結果品質の勾配は指数関数的に上がっていたが、今ではほぼ平坦になった
私の考えでは、結果が停滞している理由は、モデルが1年前よりずっと有能ではないからではない。過剰に集中したユーザーベースの莫大な処理コストを節約することが、ユーザーの明示的な指示に従い最高の結果を出すという目標より優先されているからだ。特に、その指示に従うと処理コストが余計にかかる場合はそうだ
以前は7分以上、思考モードにとどまることができた。たとえば「この主張の出典を探して」と言うと、検索し、分析し、クエリを自分で調整していた。最近は「Pro」モードでも、どれだけ促しても30秒以上働かせることができず、一般的な答えしか返してこない
Opus 4.5の瞬間も昨年11月だったし、そのときエージェント的コーディングと大半のコーディングCLIツールが本当に第一級の選択肢になった。とてつもないパラダイムシフトだ。GPT-5もまだ出る前で、ほとんどの人は4oを使っていた。今提供されているものは、コーディングでは4oよりはるかに優れている
露骨に敵対的ではないが、毎日同じミスを繰り返し、ずっと手取り足取り助けなければならず、心から申し訳なく思うこともできない同僚たちと閉じ込められて働いているようなものだ
私たちがコンピューターと働いているからといって、社会的被害を受けないわけではない。この場合は、準社会的な被害に近いのかもしれない
これが真面目に、私がプログラミングを離れようとしている理由だ
プログラミングを始めた理由は、プログラミングの問題が面白かったからだ。ところが問題が「フランスで電卓がなぜ1ずれるのかを突き止める」から「このLLMにかわいい絵文字を乱用させないようにする」へ変わるなら、職業を変える時なのかもしれない
最近は炭酸水にハマっていて、自分で連続炭酸注入器を作っている。給水源からタップまで、ESP32で制御するポンプ、圧力、水位、冷却ファンまで含めた全体ビルドだ
買い物かごで間違えていた箇所をたくさん見つけてくれた。たとえば自家醸造の界隈は8mmラインを好むが、浄水システムは9.5mmを使う、といった具合だ。単純なオンオフポンプとフロートスイッチから、実質的に完全なPLCシステムに近いバージョンまで最適化した。「より経験豊富な人」と話しながら、多くの反復を得られた。部品さえ届けば、1時間以内に組み立ててソフトウェアまで動かせる
お金にはならないが、本当に楽しい
望まない出力を防ぐためにハックの上にハックを積むのが最善策だが、結局LLMが指示に従いたくないと決めたら、
*IMPORTANT*を追加して次のモデルが直してくれることを願う以外、できることはあまりないこの経験は、制御できず、ドキュメントどおりにも動作しない外部APIと付き合うことにずっと近い。そういうものは以前からプログラミングで最も苛立たしい部分だったが、少なくとも以前は実装を実際にリバースエンジニアリングしてバグを回避できた。今はその「境界」が毎日ランダムに変わるので、それすら不可能だ
CLAUDE.mdやAGENTS.mdに簡単なスタイルガイドを入れるか、単に「絵文字禁止」と書くだけなら5秒で十分だし、そうすればLLMの出力はずっと耐えられるものになる。禁止語句を入れた簡単なスタイルガイドも役に立つもちろん、誤った前提はそれでは解決しない。それは昔ながらのやり方で、丁寧に読み、批判的に考えて見つける必要がある
しかしデータ分析やモデリングを頼むと、絵文字がそこら中に飛び出してくる
この1年ほどGitHubで見たものを考えると、LLMにプロジェクトのREADMEやドキュメントを監督なしで書かせようとは絶対に思わない