AIエージェント時代、エンジニアはなぜ疲弊するのか

(English is below)

コンピュータの前から離れるとき、絞り尽くされたような疲れを感じる日があります。

エンジニアという仕事をしていれば、そういう日があるのはある意味「いつものこと」です。私自身、思い出せる限り昔からありました。ただ、あくまで個人的な実感にすぎませんが、最近その頻度が増えている気がします。ちょうど、エージェント型エンジニアリング(agentic engineering)——エージェントに実装を任せる働き方——のコツをつかみ始めた頃からです。そして私に起きていることは、うちのエンジニアたちにもほぼ間違いなく起きているはずです。そこで最近ずっと考えているのが、この働き方の何が、ここまで人を消耗させるのかという問いです。

理由はこうだと思っています。以前は実装のコーディングの多くを自分でやっていましたが、今ではそのすべてをエージェントが引き受けてくれます。おかげでスピードはそれなりに上がりました。しかし、その時間を人間から取り上げたことで、仕事に自然に組み込まれていた「ダウンタイム」も一緒に失われてしまったのです。

私の仕事にはずっと「難しいパート」と「長いパート」がありました。難しいパートは、考えることです。顧客の課題にじっくり向き合い、それをどう表現すべきかを考え、本当の問題を探し、解決策を設計する。一方の長いパートは、ただ手を動かす日々でした。特に何も考えず、大理石の塊を少しずつ削っていくような時間です。エージェントが長いパートを引き受け、以前なら1週間かかっていたものを30分で仕上げてくれるようになった今、手元に残っているのは難しいパートだけです。

似たような話は、すでに聞いたことがあるかもしれません。エンジニアの間ではよく「AIが残してくれたのはコードレビューだけだ」と言われます。たいていは、楽しみだったコーディングを失ったことを惜しむ文脈です。それも一理あります(コーディングは本当に楽しいものですから)。ただ、失ったのは楽しさだけではない、と私は考えています。

より大きな損失は、あの長い、ほとんど瞑想のような時間がなくなったことで、一歩引いて「何も考えない」時間を持てないまま、仕事の難しい部分のプレッシャーをまともに浴び続けるようになったことです。問題が頭の中で自然に寝かされる機会が減り、その分、新しいアイデアや解決策も生まれにくくなっています。

スティーヴン・キングが『書くことについて』(On Writing)の中で、これにぴったりのたとえを書いています。物語に行き詰まったときは、机を離れて「地下室の少年たち(boys in the basement)」に任せるのがいい、というのです。意識が別のことをしている間に、無意識が問題を噛み砕いてくれる、という意味です。プログラミングという仕事は、これをタダで与えてくれていました。細かい機械的な作業がいくらでもあって、脳の前面が静かになり、脳の奥が働き始める。そういう時間が仕事の中に組み込まれていたのです。

エージェント型エンジニアリングのおかげで、ものを作ること自体はずっと簡単になりました。成果を出すという意味では、これは間違いなくプラスです。しかし、そのスピードと引き換えに常に問題解決モードで居続けることになるなら、そこにはメンタル面のコストが伴います。ワークライフバランスの意味でストレスが積み上がるだけではありません。もっと見えにくいところで、脳が裏側で問題に取り組むための静かな時間を失っている、というコストです。

エージェント型エンジニアリングが疲れるのは、私たちがこれを従来のエンジニアリングと同じ枠組みで扱っているからです。つまり、大きな問題を「解く段階」「作る段階」「レビューする段階」に分けるやり方です。従来のエンジニアリングには、コーディングという、いわば回復のための中間地帯がありました。エージェント型エンジニアリングはそこを自動化してしまい、残るのは計画とレビュー——最も燃え尽きやすい2つの段階だけです。

このバックグラウンド処理の時間が、永遠に失われたわけではありません。ただ、以前は仕事の中に焼き込まれていたものを、今は意識的に確保する必要があります。考えるための、静かに過ごすための、振り返るための時間としてです。以前、これからの学びの中核はコードを書くこと以外のところから来るはずだと書きましたが 、これも同じように、明示的に取り組むべきテーマになっていくと思います。

万能の解決策はないと思います。最終的には、エンジニア一人ひとりが自分なりのやり方を見つけるしかないのでしょう。それでも、問題に名前をつけることは良い出発点です。そしてこの問題は、今回の変化がこれまでの技術の変化とどれほど質が違うかも示しています。AIが結局のところツールだとしても、既存のワークフローを速く回すためのツールではありません。ワークフローそのものを変えてしまうツールなのです。

当面、私が自分のチームに勧めているのは次のようなことです。

• ダウンタイムを意識的に取る。 散歩、コーヒーを買いに行く時間、窓の外をぼんやり眺める時間。以前は「コンパイル待ち」や「ボイラープレート書き」という名目で仕事の中に紛れ込んでいたものを、今は自分でスケジュールに組み込む必要があります。散歩がまさに「地下室の少年たち」の求めるものだという裏づけもあります。スタンフォード大学の研究では、歩くことで創造的思考が目に見えて向上することが示されています。
• エージェントの待ち時間を、別のエージェントで埋めない。 実行に10分かかるとなると、つい2つ目のセッションを立ち上げて別の計画を始めたくなります。それが正解の場面もありますが、すべての隙間をそうやって埋めてしまうと、自分を消耗させる種類の仕事ばかりを増やすことになります。
• 自分の手で作るものを1つ残す。 小さなリファクタリング、社内ツール、個人プロジェクト。機械的な作業は、頭にとって意味のある働きをしていました。そのすべてをエージェントに渡さなければならないというルールは、どこにもありません。
• 「難しい考えごと」に予算を設ける。 本物のディープワークを1日8時間続けられる人はいません。この分野の代表的な本を書いたカル・ニューポートは、現実的な上限を1日4時間程度としています。1日の仕事が計画とレビューばかりになったのなら、その時間を予算として扱い、使い切ったらやめることです。
• バックグラウンド処理の仕組みを学ぶ。 バーバラ・オークレーの Learning How to Learn は、集中的な思考と拡散的な思考の相互作用を扱った講座です。仕組みを知っていれば、ダウンタイムを取ることを自分に対して(マネージャーであればチームに対しても)正当化しやすくなります。

何よりもまず、こうした「隙間」が存在していたこと自体を意識してほしいのです。もし疲れを感じているなら、それは、余分なダウンタイムのバッファをそっと与えてくれていた何かを、仕事から取り除いてしまったからかもしれません。8時間机に向かうことの意味は、ほんの1年前と比べてさえ、もう同じではないのです。

There are days I walk away from my computer feeling like I've been squeezed dry.

As an engineer there's a certain business-as-usual to that — I've had days like this for as long as I can remember. But, even if it's only anecdotal, I think they've been coming more often lately, since about the time I really started to find my way with agentic engineering. And if it's happening to me, it's almost certainly happening to my engineers too. So the question I've been sitting with is: what is it about this way of working that leaves me feeling completely exhausted?

I think the reason is that where before I did a lot of the implementation coding myself, now all of that is taken care of by the agent. Although this gives us a nice little speed boost, taking that time away from the humans has also removed a natural down time that used to be built into the job.

My work has always had a hard part and a long part. The hard part is the thinking: sitting with a customer's problem, working out the right way to express it, looking for the real issue, designing solutions. The long part was the days of just doing the work, chipping away at the block of marble without thinking much about anything at all. Now that agents have taken over the long part, and can deliver in thirty minutes what used to take me a week, all I'm left with is the hard part.

You've probably heard a version of this already. Engineers like to say "AI left us with nothing but code review," usually mourning the loss of the fun, the coding. They have a point (coding genuinely can be fun), but I don't think the fun is the only thing we lost.

The bigger loss is that without those long, almost meditative stretches, you feel the full pressure of the hard parts of the work without ever getting the chance to step back and not think about things for a while. Problems no longer get the chance to sit with us naturally, and that makes it harder to come up with new ideas or solutions to them.

Stephen King has a good metaphor for this in On Writing. When he's stuck on a story, he says the move is to get up from the desk and let the "boys in the basement" work on it: the subconscious mind chewing on a problem while the conscious mind does something else. Programming used to hand us that for free. The job was full of small mechanical actions that let the front of the brain go quiet while the back of the brain got to work.

Agentic engineering has made building far easier, and for getting things done that's a real win. But if the extra speed means living in a constant problem-solving state, it carries a mental cost. Not just in the work-life balance sense of ever-mounting stress, but in the more subtle sense of never giving our brains the quiet time to work on problems in the background.

Agentic engineering is exhausting because we're approaching it the same way we approached traditional engineering: a big problem with a solving stage, a building stage, and a review stage. But where traditional engineering gave us a kind of healing middle while we were coding, agentic engineering automates that part away, leaving us with only the planning and the review: the two stages most conducive to burnout.

That background-processing time hasn't vanished for good. But where it used to be baked into the work, now we have to take it deliberately — to think, to be quiet, to reflect. In the same way I've suggested before that a lot of our core learning is going to come from somewhere other than writing lines of code, this too is something we're going to have to become explicit about.

I don't think there's a universal fix; it feels like something each engineer will have to work out for themselves. But naming the problem is a good place to start. It also shows how different this shift is from the ones that came before: even if AI is, ultimately, still a tool, it isn't a tool that lets us carry out our existing workflow faster. It's a tool that changes the workflow itself.

In the meantime, here's what I'm suggesting to my own team:

• Take the down time on purpose. The walks, the coffee runs, the staring out the window: the job used to smuggle these in as "compiling" or "writing boilerplate," and now you have to schedule them yourself. There's decent evidence a walk does exactly what the boys in the basement need — a Stanford study found that walking measurably boosts creative thinking.
• Don't backfill every agent run with another agent. When a run takes ten minutes, the tempting move is to spin up a second session and start planning something else. Sometimes that's the right call, but if every gap gets filled that way, you're multiplying exactly the kind of work that burns you out.
• Keep one thing you build by hand. A small refactor, an internal tool, a personal project. The mechanical work was doing something for your head, and there's no rule that says you have to hand all of it to the agents.
• Budget the hard thinking. Nobody does eight hours of genuine deep work a day; Cal Newport, who wrote the book on it, puts the realistic ceiling at around four. If your whole day is now planning and review, treat those hours as a budget and stop spending when it runs out.
• Learn how the background processing actually works. Barbara Oakley's Learning How to Learn covers the interplay between focused and diffuse thinking. Knowing the mechanics makes it a lot easier to justify the down time to yourself (and, if you're the manager, to your team).

Above all, be consciously aware that these gaps exist. If you're feeling tired, it might be because you've removed something from your job that was quietly giving you an extra buffer of down time. Sitting down to work for eight hours does not mean the same thing now as it did even a year ago.