AI Didn't Kill the Job; Context Switching Did

I caught up with an old client last week, someone I used to build with before he left the last engagement, partly over budget, partly because AI was starting to change what "having a dev team" even meant. We hadn't talked in a while, so naturally the conversation went straight to how we're both actually using AI now, not the pitch-deck version.

He opened with the question a lot of technical founders are quietly sitting with: is software shipping now a "vibe-code it and let an adversarial AI review the PR" world, or a "everyone still reads every line, ships slower, sleeps better" world? He couldn't picture much in between.

I don't think there is much in between. Not yet. But the more interesting thing we landed on wasn't AI capability at all. It was context switching.

The engineer who quit over two tickets

A friend of mine works at a shop that restructured hard around AI: the usual story, dedicated front-end/back-end/PM roles collapsed into one person doing most of it, QA delegated to end-to-end test generation, review delegated to another agent. Standard playbook right now.

He was handed two projects to work on in parallel. He resigned the next day.

His reasoning stuck with me: "I cannot compete with the AI context switching. It's impossible." One agent pings for permission, another flags a security issue, a third can't authenticate against Vercel, a fourth has an MCP credential mismatch, and a human is supposed to sit in the middle of all four streams, holding the thread on each one. The product he was working on still isn't finished. Not because AI failed. Because the team got hasty and mistook agent throughput for human bandwidth.

That's the pattern I keep seeing when AI-driven teams stall: the tools were built to look like they can run ten things at once, so people try to run ten things at once, without anyone pricing in the cost of context-awareness. You don't get ten times the output. You get one exhausted person and ten half-finished threads.

What actually works: one thing at a time, on purpose

The shops I've seen handle this well didn't chase speed first. They kept only mid-to-senior engineers, whose job shifted to reviewing what AI produces rather than producing it themselves. An 8-hour ticket became a 4-hour ticket, not because they doubled up on tickets immediately, but because they started with 2 people on 2 tickets, let the AI setup mature against their feedback, and only then scaled up. Speed came from the tool learning their judgment over time, not from parallelizing humans past their limit.

The practical version of this, from the engineer who quit's replacement pattern (and from how I run my own days now): build context on one task while a second task works quietly in the background: a research agent, a test run, something that doesn't need your attention yet. Finish task one, verify it, ship the PR. Then go collect what the background task produced. Context stays intact. You're not typing more; the agent is. You're spending your attention on decisions, not context reconstruction.

If you want raw speed instead, the honest answer is still: hire another engineer and give them a separate module. One well-orchestrated person can now do more than one person's job used to take, but "more than one" is not "unlimited," and pretending otherwise is where teams break.

The client who chased every shiny feature

The clearest cautionary tale I have isn't about engineering process at all: it's about a founder who never let a process stabilize long enough to matter.

A client (call the company Tryps) had a genuinely good idea: an AI in a group chat that notices two friends planning a ski trip and quietly helps book it. Trip-Advisor-style booking, but seamless and conversational. Well-funded too: free credits and coupons from half a dozen tools, real budget, a paying US client at $20/hr rates that felt like a win for the team.

The problem was never the idea. It was that every single day brought a new mandate. Claude Code mentions tagging is trending: stop everything, add a tag system. Someone launches a Figma competitor: stop everything, build a design system. The team started at ten people. It shrank to five, then two, then the client concluded even that was too expensive, having decided the reason things felt slow was the people, not the constant redirection. Meanwhile a competitor with a stable roadmap shipped a working product and the client folded the project.

Nobody there had a chance to build real context on the product, because the product's definition changed daily. That's the same failure as the two-ticket engineer, just at the founder level instead of the IC level: you cannot automate (or delegate, or orchestrate) a thing you haven't let yourself understand first.

Be a chameleon, not a specialist

The other half of this conversation was less about process and more about what's actually safe to specialize in anymore. My take: hyper-specialization is exactly what's automatable. A "I only review PRs" role or "I only write front-end" role is a narrow, well-defined function, which is precisely the shape AI is best at absorbing.

What doesn't automate as easily is someone who can move: specialize when it's useful, but step sideways into a different part of the system with confidence when the work demands it. Founders are already living this by necessity: coding, support, infra, and taste all landing on one person, at least until there's a team again to hand pieces back to. The technical hires worth keeping are the ones who can do the same instead of retreating into a single lane and hoping the lane survives the reorg.

The tools are part of the problem, too

One more thing worth saying plainly: some of this isn't a discipline problem, it's a tooling problem. Multi-project dashboards that surface every thread, every error, every pending permission across every workstream look like control, but they function as a context-switching machine: you're pulled toward whatever's loudest, not whatever matters. The fix isn't more visibility into everything at once. It's tooling that deliberately narrows your field of view to the one thing you're actually building context on right now, and holds the rest until you're ready for it.

AI didn't remove the need for engineering judgment. It just moved where the bottleneck is: from typing speed to attention, from "can you write this" to "can you hold this in your head." The teams and founders doing well right now aren't the ones with the most agents running. They're the ones who figured out how many threads a human can actually hold before the thread breaks, and built their process around that number instead of ignoring it.