Something the Industry Isn’t Talking About
On what AI-generated code is doing to the people reviewing it.
Most of the writing I’m seeing about AI in engineering right now is about the upside, what it’s accelerating and what it’s letting smaller teams ship (more than likely written by AI). That’s the part the tech industry wants to talk about because it’s the part that justifies the investment. Fair enough.
There’s another side of it though and I think it’s the more important one right now. Engineers I coach across different companies are starting to describe a kind of weariness that doesn’t really come across as burnout or exhaustion. They can still do the work, they’re not in crisis but something has shifted in how the job feels to them (especially the ones who centre their purpose around the quality of code). I’m hearing it from people who don’t know each other and work in completely different companies, so it’s probably not just a them thing.
What they’re describing is something like this: AI agents are producing alot more code than anyone was a year or two ago and that code goes through pull requests like all other code, but the PRs are larger, more frequent and the people sending them haven’t always read them carefully before pressing the button. The reviewers on the other end are spending more time reviewing than they used to and the time feels.heavier because they can’t really extend the usual trust to a colleague’s code when the colleague might not have written it. So they read more carefully, find things, send it back, read again, find more things, send it back again. Each time it costs them attention they used to spend on their own work.
The companies they work for are measuring AI adoption in different ways. Sometimes it’s token spend, sometimes it’s PRs shipped with AI assistance, sometimes it’s a dashboard nobody really knows how to read but everyone knows is being looked at by someone higher up. The message that comes through though is basically the same. AI is supposed to make things faster and faster is supposed to be visible.
That message is obviously hard to push back on, AI is bringing a value to our daily lives we didn't have before. Slowing things down to review properly is the right thing to do, but it makes you the bottleneck on a dashboard somebody is watching or a new expectation a team may have. Holding the quality bar where it used to be is the right thing to do but it doesn’t really show up anywhere that anyone is measuring (and why should you care eventually?).
So the quality bar continues to lower, not because anyone decided it should, just because the system has quietly stopped accounting for it. The engineers who care about quality keep doing the work of caring, mostly alone. The ones who’ve adjusted to the new pace approve faster. Things ship, KPIs look right and the reviewers absorb the difference between what the dashboard says is happening and what’s actually going on.
This is what the tiredness is created from, as far as I can tell. Not exhaustion from the work itself, more the exhaustion of holding a standard the system has stopped appreciating. Of doing more reviewing than building, of catching things that shouldn’t have needed catching because the person who creates the code didn’t read their own change and of watching that bar move while you try to to still hold it to certain standard like before.
The thing that makes it apparent for me is that the usual response doesn’t really work. When a job stops feeling meaningful in the way it used to, the move people make is to look for a better one. That option isn’t really available right now. Hiring is tighter than it has been in years, layoffs are in the background of every conversation and the engineers I coach mostly know that walking is a bigger risk than staying. So they stay and something inside their day to day changes.
This is the human side of engineering that the AI conversation has barely touched. Most of the discussion treats engineers as productivity units that should now be more productive. The actual people doing the work are a more complicated story. They’re now owning a shift in what their job is, with less time to do their own work, less trust in what they’re approving and less ability to push back on either without paying for it. The dashboards don’t really catch any of this, but it is there in the conversations.
A few things that seem to help
I don’t think there’s a systemic fix any individual engineer can apply. The conditions producing this are above the level of one person’s choices. That said, the engineers I've noticed handling it best tend to share a few small habits and they’re worth sharing as things you can do at the level you actually control.
The first is reviewing your own AI-generated code before you push it. This sounds almost too obvious to say but it’s the discipline that’s quietly going missing in alot of teams. It could be to delivery pressure, a lack or care or something else. But, If you’re using an agent to write code, treat the output the way you’d treat a junior engineer’s PR. Read through it properly and push back on the bits that aren’t quite right (or fix them yourself) before sending it on. The amount of reviewer attention you cost when you skip this is significant and you’ll feel some of it coming back at you in worse code from other people doing the same thing.
The second is finding one person you can relate to this with. Not a manager necessarily, just a peer who’s seeing what you’re seeing. The thing that makes it corrosive is feeling like you’re the only one experiencing it, like maybe it’s a you problem. Saying it out loud to someone else is most of the relief. The work conditions don’t change but the experience of being in them does because most of what you lose when something is happening quietly is just the ability to identify what you’re feeling.
The third is being honest with yourself about what you’re trading. If you’re approving things you’d have pushed back on a year ago, just notice that. You don’t have to fix it overnight, you don’t have to be the hero who slows everything down, you just need to see what’s actually happening. The bit that hurts most is when the quality bar drops without you noticing and one day you realise you’ve stopped caring about something you used to care about and you don’t really know when that happened. Keeping it in front of you, even quietly, is what protects you from drifting further than you meant to. You don’t have to act on it, you just have to see it.
None of these fix the industry condition and they’re not really meant to. The metrics aren’t going away. But, the engineers who are handling this best aren’t doing it with better techniques. They’re the ones who can name what’s happening without making it about them (and have the confidence to tell me in private). They know they’re not the problem and they know they’re not failing at their jobs. That knowledge is most of what keeps the tiredness from turning into something worse.