You can replace 190 engineers on a spreadsheet. You can't download 190 brains into the 10 people left behind.
Everyone is talking about AI replacing developers. Far fewer people are talking about what happens to the developers who are left. I've started calling it context burnout, and if you still work in tech right now there's a decent chance you're living it.
So here's a story. The company is made up. The feeling isn't.
09:00. The happy engineering department
Nobody here knows everything. That's the point. The playback team knows why the DRM licence server retries three times and not four. Infra knows which box is load bearing despite being called test-do-not-use. Somebody on the payments team understands the billing system, and everybody else has agreed never to ask them to explain it. That spread of knowledge isn't inefficiency. It's the company's memory.
10:14. AI has arrived!
The slide deck says 10X PRODUCTIVITY. It says DO MORE WITH LESS. It says THE FUTURE IS HERE in a font that costs extra. And somewhere around slide 14, the engineers stop being people and start being a line item.
11:30. The Great AI Restructuring
"Congratulations! You're our most valuable people!" says management. One developer at the back, very quietly: "Does that mean a pay rise?" And management, beaming: "Even better. You get AI!"
15:00. The knowledge doesn't disappear
This is the bit the spreadsheet doesn't have a column for. Those 190 engineers weren't just typing. They were holding context: architecture decisions, undocumented systems, the reasons behind the weird bits, the scars from every production incident. That knowledge doesn't get made redundant. It gets reassigned.
Every surviving engineer now owns systems that used to have a whole team. The frontend dev is on call for the database. The QA engineer is reviewing Kubernetes YAML. Someone who has never touched video playback is now the video playback team, and has been told to "just get Claude to look at it".
17:45. Context burnout
Here's the thing about AI. It can generate code in seconds. Genuinely, it's brilliant at it. But somebody still has to understand that code, review it, debug it, integrate it with the system it's landing in and take responsibility when it breaks at 2am. Generating code was never the slow part. Understanding it was.
So one engineer running nine agents in parallel isn't doing the work of nine engineers. They're doing the context switching of nine engineers, which is a completely different job and a much more tiring one. There's a reason research on interruptions keeps finding the same thing: Gloria Mark's work at UC Irvine found people who are constantly interrupted do work faster to compensate, and pay for it in stress, frustration and effort. Faster isn't free.
How to tell if you've got it
You review more than you write
Your agents opened 14 pull requests before lunch. You read three of them properly. You approved eleven. You feel fine about this. You do not feel fine about this.
You are the documentation
Every question in Slack ends with your name. The wiki hasn't been updated since the restructure, mostly because the people who updated it were the restructure.
You half know everything
You used to know one service inside out. Now you half know six of them and you're on call for all of them. Half knowing is the most stressful amount of knowing.
Your bus factor is one
If you get hit by a bus, the company loses a decade of decisions. If you burn out, same result, just slower and with more Jira tickets.
Six months later
My take: AI teams, not AI heroes
Let's be honest about one thing. We probably don't need 200 engineers to do what 200 engineers used to do. AI really does change the maths, and pretending otherwise isn't going to age well. But the answer isn't ten exhausted people holding the entire company in their heads with a chatbot for company. The answer is AI teams: smaller teams, each owning one part of the system, each with its own AI agents that work on that part and nothing else.
Take video streaming, the world I've spent my career in. Broken down by the parts of the video pipeline I've worked on, from encoding through to playback, ads and analytics, it splits naturally into six areas. Give each one a small team and its own agent:
Encoding & Processing
Owns transcoding, bitrate ladders and packaging. Its agent knows the encoding profiles, the codec quirks and why the ladder looks the way it does, and it never touches anything else.
Cloud & Infrastructure
Owns the cloud estate, infrastructure as code, scaling and the bill. Its agent works in the Terraform and the runbooks, and gets nowhere near the player.
Delivery & Security
Owns the CDN, manifests, DRM and tokens. Its agent knows the licence servers, the key rotation and exactly why CBCS doesn't work on that one 2017 TV.
Ads & Monetisation
Owns SSAI, VAST and VMAP, SCTE-35 markers and the paywall. Its agent knows the ad server contracts and the stitcher, which is the only way anyone should be allowed near a stitcher.
Playback
Owns the players on web, mobile and TV. Its agent knows the player APIs, the device quirks and the full, tragic history of the Safari bug.
Quality & Analytics
Owns QoE, monitoring, test devices and metrics. Its agent watches the dashboards, writes the regression tests and tells the other five teams when they've broken something.
Here's why I think this works. Context stays bounded. Each engineer holds one domain properly instead of six domains badly, and each agent gets a small, focused context too: its own skills, its own AGENTS.md, its own corner of the codebase. Focused agents make fewer confident mistakes, and focused people can actually spot the ones they do make.
Ownership stays real. When the ad stitcher breaks at 2am, there's a team who understands the code their agent wrote, not one person frantically asking an AI to explain an AI. The teams agree the contracts between them, like the manifest format, the ad markers and the player events, and the agents work inside those boundaries. That's just good architecture, and it was good architecture long before anyone said agentic.
And knowledge lives in two places instead of one exhausted head: the team, and the skills and docs their agent runs on. Nobody becomes a bus factor of one. Six teams of three is 18 engineers instead of 200, so yes, it's still a big change. But it's 18 people doing focused work they can sustain, instead of 10 people burning out with everyone else's job.
Don't give ten people everyone's job and an AI. Give every part of the system a team, and an agent that knows it.
This is not an anti AI post
I use agents every day and I'd never go back. AI can genuinely make good engineers faster. But generating code faster is not the same thing as understanding a complex system, and the industry keeps confusing the two. Engineering is institutional knowledge, architecture, accountability, collaboration, debugging and a thousand small decisions about why things are the way they are. You can't prompt your way back to a decision nobody remembers making.
When a company removes experienced engineers it doesn't just remove salaries. It removes the people who know why the system was built the way it was, and then asks the people who are left to absorb all of that missing context while shipping more than ever. That's context burnout. Not too much work, exactly. Too much understanding, held by too few people.
If you're making the cuts: you're deleting backup copies of how your business works. If you're one of the 10: write things down. Put the context somewhere other than your head, into docs, tests that explain why, skills and AGENTS.md files your agents can actually read. And drink some water.
AI didn't eliminate the complexity. It just eliminated the people who understood it.