ループ内の人間は疲れている
(pydantic.dev)- LLMプログラミングは生産性を高める一方で、開発者が意図と品質を継続的にコントロールしなければならない監督疲れを増大させ、満足感と持続可能性を揺るがす
- モデルはそれらしいコードを素早く生成するが、複雑な変更における一貫した意図を見落とすことがあり、人間は増えた成果物をレビューして修正する品質ゲートになる
- 着手できる作業は急増しても、慎重に完了できる作業量は人間の頭脳と注意力に縛られており、コーディングの小さな報酬は減り、レビューの認知負荷は増える
- 深く理解している領域ではLLMを効果的に導けるが、専門性が浅い領域では正確さよりもそれらしさに偏るため、センスとアーキテクチャ判断がより重要になる
- ソフトウェアエンジニアリングは消えるというより縮小・再編され、希少な資源はコードを書くこと自体ではなく、人間の注意力、工学的判断、システムの一貫したビジョンを維持する能力である
有用だが不安定なLLMプログラミング
- LLMプログラミングは実質的に有用であると同時に不安定であり、その不安定さを無視すると開発者がバーンアウトに陥り得る
- Pydanticチームも、データ検証、AIエージェント構築、本番環境の観測ツールを作る中で同じ混乱を経験している
- 核心は、AIがプログラマーを置き換えるかどうかではなく、現在の開発体験がどのように変わり、何によってそれを改善できるかにある
手で直接作っていた感覚
- プログラミングは、論理だけで何かを作り、深い抽象化レイヤーを直接扱う創造の感覚を提供してきた
- 正規のコンピュータサイエンス教育ではなく試行錯誤でソフトウェア工学を身につけた経験において、アーキテクチャやコード品質の原則は教科書的なルールというより、積み重なった傷に近い
- 2010年代のローコード・ノーコードツールやDreamweaverのような製品も、コードなしで何かを作れるという約束を掲げたが、内部でスパゲッティコードを生成し、期待を完全には満たせなかった
- 現在のAIツールは過去と違い、約束と現実の隔たりを意味のある水準まで縮めており、まさにその点がより不安に感じられる
「コードが自分で書かれる」という実体験
- コードはある程度自分で書かれるが、それをレビューし、指示し、方向を修正する人間の体験はむしろ悪化し得る
- Pydantic AIのメンテナーであるDouweは、他の人たちのAIが一晩で作った約30件のPRを毎朝レビューし、それぞれを即座に判断しなければならなかった
- レビューまでAIに任せたい誘惑は大きいが、そうすると人間は何をしているのかという疑問が残る
- LLMが実行する計画をほぼ2日かけて作成し、繰り返し明確化しても、モデルはReactフックをStorybookのストーリーファイルへ移したり、誤った計画を読んで存在しないコンポーネントを作ったりすることがある
- こうした失敗は単なる能力不足というより、一貫性の欠如に近い
- モデルはそれらしいコードを作れるほど賢いが、複雑な変更全体を通じて一つの意図を維持できないことがある
- 人間は頭の中に意図を保持したまま、大量の「ほとんど正しい」成果物を判断し続けなければならず、この過程で新しい形の監督疲れが生まれる
- オープンソースで実際の人と機能を作り、相手の能力向上を助けていた報酬も減る
- 作業がAIのブラックボックスに入ると、反対側で学ぶ人がいないため、協働の満足感が消える
作業強度を高める罠
- Simon Willisonが紹介したBerkeley Haasの研究は、AIの利用が仕事量を減らすのではなく仕事の強度を高めると見ている
- 一日の終わりに、プロンプトをもう一つ入力したり、機能をもう一つ完成させたりしようとする圧力が続く
- 計画がほぼ完成したという感覚のために、午前2時近くまでプロンプトを入力する状況も生じる
- PydanticのMarceloは、Claude Codeのセッションが止まったら5つセッションを開けばいいと冗談を言う
- 他のセッションへのフィードバックで忙しければ、1つのセッションが止まったことにすら気づかないという意味である
- 並列作業によって着手できることは大きく増えるが、慎重に完了できることの数は変わらない
- 完了には、並列化できない資源である人間の頭脳が必要である
人間の報酬関数の故障
- 機械学習の報酬関数がエージェントにとって良い結果を定義するように、手作業のコーディングにも、問題解決、複雑なロジックの理解、コンパイル成功、コントロール感といった小さな報酬があった
- LLM支援プログラミングは、こうしたドーパミン報酬を生んでいた作業を自動化し、その場所をレビューと監督の認知負荷で埋める
- 満足できる部分は減る
- 消耗する部分は増える
- 空白を埋める新しい報酬はまだない
- 生産性が上がると同時に満足感が下がる現象は個人の欠陥ではなく、フィードバックループの故障であり、別個の工学的問題として扱うべきである
孤立と変動報酬
- LLMプログラミングは、人間と機械がプロンプト、修正、レビューを繰り返す、非常に孤独な活動になり得る
- 同僚に質問したり、問題を一緒に言葉で解きほぐしたり、解決の小さな喜びを共有したりする瞬間が、また一つのプロンプトに置き換えられる
- 既存の協働文化が弱いチームでは、人同士のコミュニケーションがさらに萎縮し、他の人も苦労しているという事実を確認しにくくなる
- 結果が時には素晴らしく、時にはゴミのようだが事前には分からないという点は、Skinner Boxのような変動報酬構造を作る
- 必要なときは自分でコードを書いてもよいが、LLM支援作業と手作業では考え方が大きく異なり、切り替えが不便である
- 2つのやり方を行き来できるよう自分に許すには、成熟と自信が必要である
レスポンシブデザインへの移行との類似点
- 2009年頃、Webが固定幅のピクセル単位レイアウトから流動的なレスポンシブデザインへ移行したときも、デザイナーはコントロールの喪失を経験した
- 精密なレイアウトと完璧なグリッドにアイデンティティと専門性を築いていた人々にとって、任意の画面幅やデバイスに合わせてデザインが流れるという概念は根本的な変化だった
- 移行に適応したデザイナーは、既存のスキルを捨てるのではなく再構成した
- 比例感覚と階層構造の理解は引き続き重要だった
- ピクセル単位のコントロールへの執着は重要性が下がった
- システム、適応性、不確実性のための設計はより重要になった
- 現在のAIへの移行は、レスポンシブデザインよりはるかに速く、利害関係も異なる
- レスポンシブデザインの変化は数年にわたったが、現在の変化は数か月単位で進んでいる
- 当時も代理店は顧客を、デザイナーは仕事を失ったが、現在のような実存的不安を伴ってはいなかった
- それでも、技術が消えるのではなく進化し、コア能力がより重要になるというパターンは、LLMベースのコーディングにも当てはまる
- すべてのコードを自分で書かなくてもエンジニアの価値が下がるわけではないが、はるかに多くの成果物の品質ゲートになった分、良い結果を見分ける能力がさらに必要になる
生き残る専門性と新しい働き方
- 誰もがそれらしいUIとコンパイルできるコードを作れる環境では、センスとニュアンス、成熟したアーキテクチャ判断、実際の専門性に基づく非主流の判断が差別化要因になる
- コード、意思決定、トレードオフを深く理解している領域ほど、LLMをうまく導ける
- 専門性が浅い領域に向かうほど、成果物は本番投入できる水準から遠ざかり、実際に正しいというより、印象としてそれらしい状態に近づく
- モデルは自分が知らないことを知らないまま、隙間を自信たっぷりに埋める。これは人間にも見られる失敗の仕方である
- 複雑な計画には**事前検死（pre-mortem）**を活用できる
- 新しいLLMセッションに、計画が悲惨に失敗したと仮定させ、その原因を診断するよう求める
- 細部を2日間見続けた人が見落とした仕様の隙間を見つける助けになる
- Pydanticのあるエンジニアは、過去のコードレビューコメント数千件からルールを抽出し、
AGENTS.mdファイルの初期指示にするツールを開発した- 数年にわたり暗黙的に蓄積してきた工学的判断を、LLMが従える指示へ変える専門性の蒸留に当たる
- 変化に適応する人々は、実務で得た強い判断基準を持ち、今後も有効な原則と、過去の帯域制約から生まれた習慣を区別する
- 彼らは基準を捨てない一方で、ワークフローを変える意思を持っている
ループの中で明らかになった希少資源
- 現在のAIの流れはソフトウェアエンジニアリングという職業を終わらせるわけではないが、業界の深刻な縮小と根本的な再編をもたらし得る
- 淘汰、能力の退化、十分速く動かなければ取り残されるかもしれないという恐れは正当である
- 最後の懸念は誇張される場合もあるが、完全に根拠がないわけではない
- 真のボトルネックはコードではなく、人間の注意力、工学的判断、システムに対する一貫したビジョンを維持する能力だった
- コードを書くことが難しい部分のように感じられていたため、従来はこのボトルネックが見えにくかったが、作成プロセスが自動化されることで、人間の能力こそが実際の希少資源であることが鮮明になった
- 開発者はより生産的でありながら、より幸福度が低く不安定になり得る。ツールを作るチームも同じ問題を経験し、報酬関数をリアルタイムで調整している
- コードと開発のやり方は変わっているが、人間は依然としてループの中におり、現在の核心的な状態は人間参加者の疲労である
1件のコメント
Hacker Newsの意見
手作業でのコーディングは、難しければ難しいほど、問題解決、ロジックの理解、コンパイル成功、コントロール感といった小さな報酬が大きくなっていた。一方でエージェントによるコーディングは、機能の規模に関係なく似たような監督を求め続けるため、最初は生産性の波に乗っているようで楽しいが、満足できる部分は減り、レビューの認知負荷は増えて、すぐに疲れてしまう
Claudeを仕事や個人プロジェクトで楽しく使っており、核心はエージェントの誘惑を避け、コード生成器として扱うことにある。セッションを1つだけ開いて計画を十分に詰めたうえで、段階的な実行を見守り、各段階が終わるたびにレビューと軌道修正を行えば、最後までコードの状態をよく把握できる
ワンショットに近い使い方をするには、計画段階でアーキテクチャだけでなく、主要な意思決定を左右する実際のコードまで具体化する必要がある。リファクタリングのコストはこれまでになく低いので、理解しにくい部分はすぐにLLMと直せばよいが、一度に1つのLLMに1つの作業だけをさせ、継続してプロセスに関与し続ける必要がある
Claudeに全権を与えると必然的に生じる混乱や難所が、人を消耗させる。望むときは自分でコーディングし、疲れたときにClaudeへ渡せば、コードベースへのコントロール感も維持できる
同僚や部下のコードをレビューするときは、フィードバックの技術的妥当性だけでなく、プライド、アーキテクチャ観の違い、丁寧な口調、追加の作業量、チーム内の力学まで考慮するため、精神力の大半を使う。一方でLLMは感情的影響を気にする必要がないので、レビューや軌道修正がはるかに楽である
職場では human in the loop の代わりに Human on the hook と呼び始めた。うまくいけば功績は得られないが、失敗すれば責任者になる、つまり問題が起きたときだけ人間が重要になる構造を、より正確に表している
コードを書くこと自体は、自分にとって一度も難しい部分ではなかった。高速タイピング、Vimのモーダル編集、Unixコマンド、スクリプトとショートカット、Git、IDEのリファクタリング、Javaを習得し、何を作るべきか分かっているときは思考の速度で作業する
止まる瞬間は、タイピングや文法のせいではなく、コードの形や正しい変更を考えるときであり、難しくなれば、より良い抽象化やIDEツール、
sedを含むUnixパイプラインを作る。だからボトルネックはコードを書くことではなく、思考と判断だったAIコーディングが大きな飛躍のように感じられる理由は、優れたツールに触れたり習熟したりしていない開発者が、予想以上に多いからかもしれない。今20代だったなら、こうした技術を身につけることに割く時間は少なかっただろうが、自分にとってソフトウェア工学が魅力的だった瞬間は、そのどれも魔法ではないと理解したときだった
自分が絵が苦手なためAIの絵がすごく見えるのと同じように、AIプログラミングも同じ原理で評価され得る
多くの人が感じる疲労は、より速い推進力とより大きな混乱が組み合わさることで生じるコントロール喪失に由来する。LLMは天才と幼児のどこか中間にあり、後部座席から見守ることは刺激的である一方、恐ろしくもある
しばらく高速で走った後には、歩くのも悪くなかったし、むしろ望む目的地に到達する可能性が高かったのだと気づくことになりそうだ
LLMによるコーディングは、スロットマシンのレバーを引くように儀式をこなし、今度こそうまくいくことを願って繰り返す感覚がある。通常のプログラミングのエラーには一貫した原因があり、その原因を理解して、可能なら恒久的に取り除くよう設計されている。熟練した開発者は、ランダムに試して成功したからといって、理由の分からない出来事として片付けたりはしない。
システムが何なのかについてさえ合意できない複数のステークホルダーを相手にして、すでに疲弊しているのなら、人間の注意力と工学的判断こそがもともとボトルネックだったことを、とっくに知っていたのかもしれない。
Claudeでのコーディングは、その推測段階に戻るように感じるので望まない。ただし、複雑なAPIや複数のコンポーネントをつなぎ合わせるDevOps的な作業のように、もともと盲目的な推測が多い領域では、LLMとの対話が最も役に立つ。
計画はいつでも変わり、衝動的にすべて書き直される可能性もさらに高くなる。
記事の核心には共感するが、随所にClaude特有の文体がにじんでいて、誰かがAIで書いた文章を読むのはなおさら疲れる。
2021年の記事 The Animal is Tired を思い出す: https://www.robinhobb.com/blog/archives/2021-05
もっと体を大事にしていたとしても、結局同じ場所にたどり着き、その代わりに大切な思い出を逃していたかもしれない。体はいたわるべきだが、次の戦いで必要になるかもしれないからと最後まで使えないゲーム内のポーションのように扱ってはいけない。私たちの体の各部分は、より大きな目的のために一度だけ犠牲にできるか、まったく犠牲にしないかのどちらかでしかない。
こう考えるだけで泣いてしまうほど、今も感情的な危機の中にいる。
AIの利用が仕事の強度を高めるというBerkeley Haasの研究広報は印象的だが、HBRの記事 https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... と広報資料 https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo... が出てから5カ月以上たっても、実際の論文やプレプリントを見つけられない。
現時点で分かっているのは、単一業界のある1社で行われた約40件の定性インタビューがすべてであり、研究方法を確認しないまま結果の信頼性を評価するのは難しい。