My Best Senior Engineer Quit Last Month

A senior engineer quit after spending eight months reviewing AI-generated code instead of building systems, revealing how coding agents shifted work from creation to verification and burned out the most skilled team members. The engineer's exit interview highlighted that AI tools increased review burden by 200% and left senior engineers as mere verification layers, a pattern the manager failed to see because velocity metrics improved.

My Best Senior Engineer Quit Last Month. Her Exit Interview Was Scheduled for Forty Minutes. The Last Five Changed How I Run My Team. She was not burned out from writing code. She had barely written any in eight months. She was burned out from reading it. From being the last human standing between an agent’s confident output and our production systems. I did not understand what that did to her until she told me, on her way out the door. Before you read this story, ask yourself: If AI wrote every line of code you produced tomorrow, would you still be the person people call when production is on fire? If the answer is uncertain, this story may matter more than you expect. Priya gave notice on a Tuesday. She had been with us almost five years. She owned our payments path, the part of the system nobody else fully understood and nobody wanted to. She was the engineer I called first when something was on fire and the one I called last when I needed someone to tell me a deadline was a bad idea. When she said she was leaving, my stomach dropped in the specific way it does when you realize a load-bearing wall just announced it is leaving the building. The exit interview was on the calendar for forty minutes. I ran the standard playbook. Compensation, was it competitive. Growth path, did she feel stuck. Management, was there something I did. Team, culture, the usual. For thirty-five minutes she gave me reasonable, professional, slightly generous answers. Comp was fine. She liked the team. I was a decent manager, she said, which was kind and probably half true. Nothing actionable. Nothing I could take to my own boss and point to. Then, in the last five minutes, with her laptop already half closed, I asked the off-the-record version. What is the actual reason. And she said something I have been writing down in different forms ever since. She said: “I haven’t built anything in eight months. I’ve spent eight months reading things a machine wrote, trying to find the bug it was too confident to see. I’m not an engineer here anymore. I’m a verification layer for an agent. I didn’t spend ten years getting good at this to become the thing that stands between a model and the incident it’s about to cause. I’m tired in a way that has nothing to do with hours.” I wrote it down word for word in my phone after she left. I have read it more times than I want to admit. The job I did not notice I had changed Here is the part I am not proud of. I did not see it happening, because from where I sat, everything looked better than it ever had. When we rolled out coding agents across the team, the metrics went vertical. Velocity up. PRs merging faster. Cycle time down. Throughput up and to the right on every dashboard I showed leadership. I genuinely believed I was watching my team get more powerful. I told them so. I put it in a deck. What I could not see from the dashboard was where the work had gone. It had not disappeared. It had moved. The agents took over the generation, the part that used to be most of the job, and all of that work flowed downstream and pooled in one place. The review queue. And the review queue had a name on it, over and over again, because she was the only one senior enough to catch what the agent missed. Priya’s day had quietly transformed. A year earlier she spent it designing systems, writing the hard parts, owning the architecture. By the end she spent it reading. Reading PRs she did not write. Reading agent output that looked clean and was sometimes, in small, vicious, hard-to-spot ways, wrong. Reading more of it every week, because the agents got faster and the volume kept climbing, while her hours stayed exactly the same as they had always been. The industry has numbers for this now. Review time under heavy AI adoption has climbed nearly 200 percent. Eighty-six percent of engineering leaders report their senior engineers spending more time fixing code. The agents generate at the bottom of the org and the debt collects at the top, on the desk of the one person experienced enough to be trusted with it. I had built that exact funnel without ever deciding to, and Priya was standing at the narrow end of it. Then the review came in. “I’ve botched a number of tech interviews not because I’m not smart, but because there really is a flow that should be handled that is a lot easier once you realize what it is.” Or you can read this interview article Why reading is so much heavier than writing I used to think reading code was the easy half. You write the hard half and reviewing is the cooldown. After Priya left I understood I had it backwards, at least now. Writing code, even hard code, has a rhythm to it. You are building. There is a thing in your head and you are making it real, and there is a quiet satisfaction in watching it take shape, and at the end there is something that is yours. The work is generative and it gives something back. Reading code that a machine wrote, hunting for the failure it could not see, is the opposite of generative. You produce nothing. You build nothing that is yours. You are scanning, all day, for the one missing retry, the one unhandled null, the one auth check that exists on three endpoints and not the fourth, knowing that if you miss it, it is your name on the incident, not the agent’s. You carry all of the responsibility and none of the creation. And the volume never stops, because the thing producing the work does not get tired, take lunch, or sleep, and you do. That is not a lighter job. It is a heavier one, stripped of the part that made the weight bearable. Priya was not exhausted from overwork in the hours sense. She was exhausted from doing the least rewarding version of her job, all day, as the only safety net, for eight months, while her dashboard told me she was thriving. The signal that does not show up on any dashboard This is the part that should bother every manager reading this, because I lived it and I still almost missed it. There is no metric for what happened to Priya. Her velocity was fine. Her review throughput was high, that was the whole problem. She did not miss deadlines. She did not complain in one-on-ones, because “I am tired in a way that has nothing to do with hours” is not a sentence that fits in a status update, and because senior engineers are, almost by definition, people who absorb load quietly until they cannot. By the time the signal reaches you, it is not a warning. It is a resignation. The dashboards that told me my team was thriving were measuring the exact activity that was burning out my best person, and there was no instrument anywhere in my stack pointed at the thing that actually mattered, which was whether the human carrying the verification load could keep carrying it. And the cost of being wrong about that is brutal in a way leadership underestimates. The replacement cost of a senior engineer in 2026 runs 150,000 to 300,000 dollars when you count recruiting, ramp, and lost institutional knowledge. But that number undersells it, because when Priya left I did not just lose a headcount. I lost the only person who understood the payments path, the verification capacity that was already my bottleneck, and the years of scar tissue that let her catch the agent’s mistakes in the first place. I lost the debt and the only person who could pay it down, in one Tuesday. What I changed I am not going to pretend I have this solved. I am six months into figuring it out. But here is what I changed, because someone reading this still has their Priya, and still has time. I stopped treating review as free. It is not free. It is the most cognitively expensive work on the team now, and it is concentrated on the fewest people. I started measuring review load as deliberately as I measure velocity, and I started spreading it instead of letting it pool on whoever was most senior. I capped the volume. A 400-line agent PR reviewed by an exhausted senior in eleven minutes is not review, it is a rubber stamp on a future incident. Smaller PRs, fewer of them, real scrutiny on each. The velocity dashboard looks slightly worse. The team is in better shape underneath it. I gave my seniors back the generative work on purpose. Not because the agent cannot do it, but because a senior engineer who spends one hundred percent of their time reading machine output will leave, and a senior engineer who still gets to build the hard parts will stay. The building was never just output. It was the thing that made the rest of the weight survivable. I had let the agents take it without noticing it was load-bearing for the human, not just the codebase. And I started asking the off-the-record question in one-on-ones, months before the exit interview, when there is still time to do something with the answer. “Is the work still the work you want to be doing.” Most of the time the answer is fine. The one time it is not, I would rather hear it across a desk in March than in a resignation letter in October. What I wish I had known If you manage engineers in 2026 and your velocity dashboards have never looked better, I am not telling you the dashboards are lying. They are telling the truth about throughput. They are simply silent about the thing that will actually cost you your best people, which is what the new shape of the work is doing to the humans carrying its heaviest, least rewarding part. Priya was not failing. She was the strongest engineer I had, doing the hardest version of the job, with no instrument anywhere pointed at the strain, until the strain became a Tuesday. The agents did not burn her out. The way I let the agents reshape her job did. That one is on me, and it was preventable, and I did not see it because I was looking at the wrong numbers the entire time. If you have a Priya, and you almost certainly do, the last five minutes of her exit interview are already written. You just get to choose whether you hear them now, while you can still change the ending, or in October, when all you can do is write down what she says and read it too many times afterward. After Priya left, I started writing down the patterns I kept seeing. The incident mistakes that repeated. The architecture decisions that looked different on the surface but shared the same underlying tradeoffs. The review habits that turned some senior engineers into bottlenecks and helped others scale their influence. Mostly for myself at first. Three months after Priya left, I tried what half the comments told me to do: I let AI review the AI. It looked like the answer, until the night it nearly shipped a completely broken system with every test green. I wrote about what happened, and what I understand now, here: Three Months After Priya Left, We Let AI Review the AI . The next outage is coming whether you’re ready or not. Grab the free field kit and keep it open before the page arrives: Priya wasn’t the first senior engineer I’ve seen become a review bottleneck. After enough incidents, architecture mistakes, and production failures, I started documenting the patterns that kept repeating. After Priya left, I started writing things down. Not to publish. Not to sell. Because the patterns were repeating and I needed somewhere to put them so I could actually see them. The incident that looked unique but was the same connection pool failure we had eighteen months earlier. The architecture debate that ran for two weeks and would have ended in thirty minutes if someone had asked the right constraint question first. The senior engineer in the interview who knew everything and still did not get the offer, for a reason nobody told them. I had seen all of it before. Most of it more than once. And every time I watched someone pay for a lesson that already existed somewhere, in someone else’s scar tissue, I wrote it down. Three years of notes. Thirty-seven of them eventually became a library. It is called The Senior Backend Engineer Handbook. It covers the failure modes behind most production outages, the architecture tradeoffs that compound for years, the production references you actually need at 3 AM, and the communication layer that separates two engineers with identical depth in an interview room. It is not about Priya. But it is the thing I wish she had had access to, not because it would have saved her from the job I let become something else, but because the judgment it builds is exactly what made her irreplaceable in the first place. If you are the engineer carrying the load right now, or the manager watching someone carry it, it is here: The Senior Backend Engineer Handbook: From 3 AM Outages to Senior Offers And thank you to everyone who took the time to read, think, disagree, agree, and leave a thoughtful comment. The discussion has been far more interesting than I expected. Every Page In This Library Cost Someone Something. Nobody pays senior engineers for what they know. They pay them for what they notice. The deadlock before it becomes an outage. The tradeoff before it becomes technical debt. The interview signal before it becomes a rejection. Most of the material in this library was written after something went wrong. A production incident. A bad decision. A missed opportunity. Experience is a brutal teacher. This is what the lessons looked like after the scars healed. Best, Devrim