"Using coding agents well is taking every inch of my 25 years of experience as a software engineer, and it is mentally exhausting. I can fire up four agents in parallel and have them work on four different problems, and by 11am I am wiped out for the day.... There is a limit on human cognition. Even if you're not reviewing everything they're doing, how much you can hold in your head at one time. There's a sort of personal skill that we have to learn, which is finding our new limits. What is a responsible way for us to not burn out, and for us to use the time that we have?" Simon Willisonshow more

Our full conversation

the context switching is really taxing and he's correct. I've been coding for 25+ years. I found that just working on one feature, one session at a time is more productive than the "4 parallel agent" thing. Yes, it takes a bit longer to ship features, but the burnout juggling those agents is worse imho

Why are you firing up four agents and having them work on four different problems in parallel if that burns you out? That's like drinking 5 litres of water in one go and wondering why you need a piss. Just work on one thing at a time, like a normal person.

Im surprised at how many people have not been talking about this. Agentic coding at the limits is extremely difficult to assess how to be the best at it and what the best practices are that are not just some form of build a harness for the agents to work better.

25 years of experience is exactly why it works. you're not writing code, you're making judgment calls at speed. knowing which outputs to trust and when to intervene is pure senior engineering running at 4x throughput.

People with ADD finally have an advantage here. thank god.

This was a really good episode with many helpful insights. Thanks @simonw!

yeah, I feel this.

This is the way

been using git worktrees + worktrunk for this. you basically stop coding and become a tech lead for a team of hyperactive juniors. the job has completely changed:

the mental exhaustion from parallel agents is real. i found the bottleneck is context switching between their outputs, not running them. started batching review into one pass instead of checking each agent as it finishes. what does your review cadence look like with four running?

Yes this tracks with my experience 💯

You're not writing code anymore, you're doing code review at 4x throughput. Every output looks plausible but could have subtle architectural choices baked in that compound fast. The skill ceiling for agent-assisted development is higher than writing it yourself, not lower.

the exhaustion is context switching between agent outputs, not running them. batching review into one pass instead of checking each live helped. how do you decide when to jump in vs let them finish?

the exhaustion makes complete sense once you map what's actually happening. running 4 agents in parallel doesn't reduce cognitive load. it transforms the nature of the load from generating solutions to evaluating them. evaluation at that rate is harder than generation. the 25 years of experience is exactly what makes it exhausting. a junior dev looking at 4 agent outputs would just ship them all. Simon knows what's wrong with each one and can't let it go.

strong agree. learned this the hard way after launching a product in the coding agent space! now i'm more a fan of parallelizing vertically (one orchestrator agent working on a larger body of work) vs horizontally (lots of agents working on unrelated things)

this is very real. AI multiplies output, but it multiplies decisions even more. what wipes you out is not the coding, it's the nonstop context switching

"Finding our new limits" is a mantra I picked up from @simonw on @lennysan's show. Two things that stayed with me: - There's a real difference between "vibe coding" (hands-off, blast radius is you) and "agentic engineering" (tests, templates, real validation for anything you ship). Most teams blur the line early on, and pay for it in tech debt later. - The near-term danger with LLMs isn't capability, it's prompt injection slipping past us unnoticed, until a Challenger-style failure makes it undeniable. When great conversations like these pile up on your "watch later" list, uListen gives you the key takeaways to absorb in 2 min, so you know upfront that episodes like this are worth the full 2 hours. uListen is a free Chrome extension for YouTube podcasts. Great ideas stay with you. We make sure of it.

the cognitive overhead is real. you're not just writing code anymore — you're managing 4 parallel contexts, reviewing divergent implementations, merging decisions, catching hallucinations before they propagate. it's like being a senior engineer reviewing 4 PRs simultaneously while also being the PM. no wonder it's exhausting by 11am. the skill isn't prompting, it's context management at scale

As a consumer I'm excited to see what happen over the year when 100,000 brilliant SW engineers are running 5 projects at once, not sleeping, working 100x , I presume there's going to be a lot of good stuff produced from all this productivity.

yeah this hit. running 3-4 agents in parallel feels productive until you realize you're the bottleneck. the agents aren't tired. you are. the skill isn't agent management — it's knowing when to stop spawning and just think

the bottleneck moved but it didn't disappear. it used to be writing code, now it's holding enough context to direct four agents without losing your mind. that's a different kind of tired, and nobody's talking about how to train for it...

This is reshaping what founders ask me to look for in engineering hires. Six months ago it was "strong coder." Now it's "can they manage the cognitive load of orchestrating AI agents while maintaining code quality?" It's becoming a leadership skill, not just a technical one. The best engineers I'm placing right now are basically AI project managers who also happen to code.

100% @lennysan I had a whopped of a day with 5 agents in parallel for 4 hours and at the end of it Claude was asking me if my CW (Context Window) was okay? LOL!

Very true. I code 10-12 hours a day. I need to vary wildly between projects to keep my sanity, so I work on 4-5 different things at the same time. Being wiped out is one thing, the feeling that time and subscription tokens are being wasted on an idle coding agent is another.

ALL of my burnout is a result of meetings and dealing with other humans who can't understand shit or care about stupid things. Working with coding AI usually energizes me. It's almost restoring my will to live.

the real skill isn't using the agents. it's knowing when the agent is confidently wrong and about to burn 3 hours of your time. 25 years of experience isn't being replaced. it's being repackaged as "knowing which output to throw away"

the bottleneck shifts from coding to reviewing. 4 agents means 4 diffs to sanity check, 4 directions that might be wrong. different kind of tired tbh

Context switching hits machines and humans differently, so there's always a trade-off between parallel efficiency and the depth of focused work. So it's worth asking ourselves: does this task need speed, depth, or a hybrid. Or should be done at all.

@steipete Millennial to Gen Z ADD gamers were built for this.

the cognitive load problem is real and underrated. running four agents in parallel isn't 4x productive, it's 4x context switching overhead. the engineers who figure out how to batch, delegate cleanly, and review asynchronously are going to have a big edge.

Simon nailed something I keep seeing with B2B companies deploying agents: the cognitive load of directing four parallel workstreams is genuinely harder than the coding itself. Companies are buying execution capacity without asking whether they have direction capacity. Wrote about what this means for engineering teams and CTOs in our blog here

🤣🤣

I’m doing around 8 in parallel on a single codebase, my brain is rewiring in real time, at first it was linearly, then 2, 4 and now I’m up to 8

the exhaustion might also be from decision fatigue, like you're still making the calls even if agents do the work