I've been watching protocols quietly cut their engineering teams and replace them with AI tooling. Not replace the work. Replace the people. The engineers who remain get a new job title nobody asked for: senior prompt engineer with full-stack accountability.
This is not fine.
The pitch was that AI would give engineers their time back. More focus. Less busywork. Better output. What actually happened is that the same amount of work, or more, is now expected from fewer people in less time, because an AI can theoretically do it in an hour. The time AI saved didn't go back to engineers. It went to the roadmap.
The trap nobody warns you about
Here's a thing I've seen happen to good engineers. They spin up an agent, give it a prompt, the code compiles, the tests pass, the feature ships. Efficient. Repeatable. Fast enough to keep the CEO happy.
Then something breaks three weeks later.
Not a syntax error. Something architectural. A misunderstood state transition, a reentrancy edge case, a token approval flow that works until it doesn't. And when someone asks the engineer to walk them through what was built, they open their agent and start prompting for an explanation.
They don't actually know what they built. They know what the output looked like. That's a different thing.
I'm not blaming the engineer. The incentive structure did this to them. When the metric is speed and the validator is "does it work in demo conditions," of course you stop reading the code. Reading slows you down. And slowing down is now a performance problem.
Managing agents is still work
The multi-agent workflow sounds impressive until you're living it. Why wait for one agent to finish when you can run three in parallel? One on the feature, one on the R&D spike, one on the design system refactor. Ship everything at once.
What they don't tell you is that you're now a traffic controller. You're feeding prompts, scanning outputs for obvious failures, greenlighting builds you haven't fully read, and context-switching every twenty minutes between three separate threads of work that all need your attention.
That's not engineering flow. That's triage with extra steps.
And when the hallucinations come, and they do come, you're not catching them in a focused review. You're catching them at 11pm when a user reports something broken, or you're not catching them at all because you've been context-switching all day and your brain is done.
What AI burnout actually feels like
It doesn't announce itself. That's the thing.
You don't wake up one day and decide you're burned out. You just notice that you used to look forward to sitting down with a hard problem and now you dread opening your laptop. You notice that the work that used to feel like craft now feels like processing. You're moving, you're shipping, the Jira tickets are closing, but nothing feels real.
For engineers who got into this because they loved building things, that loss is significant. It's not just tired. It's a specific kind of hollow that comes from spending your days doing something that looks like your job but doesn't feel like it anymore.
The multi-agent workflow adds a particular flavor to it. You're never fully present in any one thing. You're skimming outputs, context-switching every twenty minutes, half-reading results before greenlighting the next build. Your brain never gets to go deep. And deep is where most engineers actually live. It's where the satisfaction comes from. Cut that out and you're left with the surface of the work and none of what made it worth doing.
Then the hours don't shrink. They expand. Because AI didn't reduce the scope, it inflated the expectations. And you're absorbing the difference.
I'm in this right now. I'm not writing from the other side of it. I'm writing from the middle of it, which is the only reason I can describe it accurately. Overwhelmed, under-resourced, watching things get built that I don't fully trust, and not always having the standing to slow it down. That's not a personal failure. That's a structural one. But it lands on the person anyway.
And I don't think I'm alone. I think a lot of engineers are sitting in the same place and not saying anything because productivity is the only metric anyone is measuring right now.
What CEOs are getting wrong
AI is a force multiplier. That's true. But a multiplier on what, exactly?
If you have a senior engineer who understands the system, has strong architectural judgment, and uses AI to accelerate implementation, that's a multiplier on real capability. The output is faster and the engineer still owns it.
If you have an engineer who's been reduced to prompting and greenlighting, you're multiplying volume. You are not multiplying quality, reliability, or understanding. You are shipping faster toward a technical debt wall you can't see yet because nobody's been allowed to look at the code.
The engineers who understand this are the ones getting quiet. Not quitting, just quieting. Doing what's asked. Keeping their head down. Watching the codebase accumulate decisions nobody made.
What I think needs to happen
Teams need to be sized for the actual work, not the theoretical output of AI tools. AI handles a lot, but every output still needs an engineer who can read it, question it, and own it. If your team is too small to do that, your AI is not helping you, it's giving you false confidence.
If you want prompt engineers, hire prompt engineers. But don't take a senior engineer who built their career on deep technical ownership and tell them their new job is reviewing AI output at speed. That's a waste of the human and a risk to the product.
And engineers need to feel like they're allowed to push back. Not on AI itself, I use it every day and I'm not going anywhere. Push back on the expectation that understanding is optional. Push back on roadmaps that assume AI removed the need for thinking time. Push back when something ships that nobody on the team can explain.
Speed matters. I've shipped millions in swap volume. I know what moving fast looks like. But I also know the difference between fast and reckless, and right now a lot of teams can't tell the difference because they're too busy managing agents to stop and look.
Slow down enough to know what you built. That's not a productivity problem. That's the job.