Half an hour before I started writing this, I noticed something about my own day. I was working on a little feature, writing code, listening to music and I noticed how nostalgically happy that made me feel. I barely write code anymore, but I sure do review a lot of it. I read other people’s pull requests, I comment, I approve, I unblock, I context-switch between six libraries and a dozen open threads, and at the end of a good day I have moved a lot of things forward without having made a single one of them.
And it’s fine. It’s part of the job. But it’s not the same kick.
Any engineer who has shipped something hard knows the kick I mean. You struggle with a problem for days, you go to bed with it, you wake up with it, you think about it in the shower, you try and try things that don’t work. And then one afternoon it compiles, the test goes green, and something lights up in your chest that has nothing to do with your manager or your bonus. You made a thing, and it works, and for a moment the world is slightly better than it was before.
In my role as a manager I consciously traded most of that away when I rode the pendulum (again) from an IC to a manager position. What’s new, and what I’ve been turning over in my head for the past few months, is that we are now asking every engineer on the team to make the same trade, whether they signed up for it or not. And I don’t think we’ve been honest, as an industry, about what that costs.
The death of deep work
The story we tell ourselves is that AI is a tool, and historically, in our trade, tools have made the work easier. But this time it’s different. We have an actual shift in the shape of the work. Engineers are expected to move quickly between many small tasks instead of deep diving into one. We scaffold several things at once with multiple agents and then spend our day steering, checking and correcting. The volume of code to review, both from teammates and from the community, keeps climbing and the felt sense of ownership over any single line goes down, because, yes, you did approve that line, but you didn’t fight the compiler for it and at the end of the day, you don’t feel like you own it.
So this is not a story about whether AI is good or bad. It’s a story about a workforce of people whose brains were shaped by one kind of work, being moved, disorientingly quickly, into a different kind. And brains, my friends, do not reshape on a product roadmap’s timeline.
The volume of code to review, both from teammates and from the community, keeps climbing and the felt sense of ownership over any single line goes down, because, yes, you did approve that line, but you didn't fight the compiler for it and at the end of the day, you don't feel like you own it.
Cal Newport drew the line years ago, before any of this. Deep work is what you do in a state of distraction-free concentration that pushes your cognitive limits; it creates new value, it builds skill, it’s incredibly fulfilling, and very hard to replicate. Shallow work is the logistical stuff you can do while distracted, the stuff that doesn’t create much and is easy to replicate.
For most of my career, engineering was mostly deep work. That was the meme, even: the developer with the headphones on, don’t-talk-to-me-I’m-in-the-zone, there were whole books written about protecting that focus. We defended it with everything we had because it was where the value we produced came from.
What managing a swarm of small tasks and a flood of PRs does is turn a deep-work job into a shallow-work job. And it does it through a mechanism Newport named precisely: attention residue. Every time you switch tasks, part of your mind stays stuck on the last one, so the next task gets a smaller, noisier slice of you. Do that thirty times a day and you never get a clean slice of your own attention. You are always operating at partial resolution.
And here’s the part that actually stings: deep work isn’t only more productive, it’s a kind of flow, and flow is rewarding in itself, because the reward is in the doing rather than in some prize at the end. So when you fragment the work into thirty shallow slices not only you lose output, you lose the very thing that made the work feel good from the inside.
The shock on our dopamine machinery
I’ve been chewing on this one for a long time, well before it showed up at work, partly as an engineer but honestly even more as the mother of a teenager. Most of what I understand about it I first picked up from the neuroscientist Andrew Huberman, who talks about training your dopamine system to attach to the effort itself rather than to the reward at the end (the Stoics knew this too, but putting studies and measurements behind it definitely helped drive the point home for me). So the feeling I’m describing isn’t nostalgia. It’s neurochemical, and there’s a well-mapped piece of machinery underneath it called reward prediction error. Our brains don’t fire dopamine for a reward so much as for the reward that exceeds what you expected; in a way, it’s tracking the gap between what you thought would happen and what actually did. When you’ve struggled for days and you’re no longer sure it’ll work, your expectations drop, so the moment it finally compiles the gap is huge, and so is the hit.
And it isn’t only about expectations. Researchers have found that dopamine neurons fire harder for a reward when you had to work harder to get it. The signal is amplified after a costly action compared to an easy one, and you actually learn faster under high cost; there’s a study (very creatively ;)) titled “The cost of obtaining rewards enhances the reward prediction error signal”. So effort works on the reward from both directions at once: it keeps you uncertain enough for success to land as a surprise, and it amplifies the signal on top of that. Which brings us right back to where Huberman started. Effort isn’t the price you pay for the reward, but it is, in fact, what makes the reward feel like a reward.
Effort isn't the price you pay for the reward, but it is, in fact, what makes the reward feel like a reward.
This is also, in passing, one of the most important things I try to hand to my kid: “Oh it’s hard? You’re frustrated? Good! There’s learning and acomplishment at the other side of that frustration, and there are no shortcuts to it. You can do this!”
Read that back against a software engineer’s career. We spent years, a decade, two or three training a reward system on exactly this pattern: struggle for days, hit the wall, break through, get the big hit, become a better engineer, build confidence in your own skill. We built brains that expect the payoff to be proportional to the fight. That isn’t a personality quirk, and it isn’t really even about software. The machinery is ancient and built into our DNA. The dopamine reward system is one of the most evolutionarily conserved things we have, shared with animals as distant from us as insects, and from ants to humans, creatures reliably prefer the reward they had to work harder to get. Evolution wired effort and reward together because, for almost all of life’s history, the things worth having were the things you had to struggle for. We just spent a whole career reinforcing that wiring and now we’re changing the input. The struggle is getting compressed or outsourced and the output arrives faster and cheaper, which sounds like a win, except the effort was never only a cost.
Evolution wired effort and reward together because, for almost all of life's history, the things worth having were the things you had to struggle for. We just spent a whole career reinforcing that wiring and now we're changing the input.
After analyzing nearly 12,000 daily diary entries in her research, Teresa Amabile found that the single most powerful thing for someone’s motivation and inner life on any given day is making progress on meaningful work. Now, you could push back here, and I have pushed back on myself: progress is progress. Shipping five agent-built features is more progress than hand-crafting one, so surely we should be more motivated, not less? There’s a version of that which is simply true. But Amabile’s finding has a specific shape. It’s progress on work that feels meaningful, work the person feels some ownership over. Clearing a review queue is throughput, and throughput is real and valuable, but it doesn’t always register to the person doing it as their progress. The open question, and I don’t think we’ve answered it yet, is whether agent-driven progress can be made to feel like your own small win, or whether it just feels like tending someone else’s conveyor belt of neverending Jira tasks. I suspect the answer depends almost entirely on how we frame and structure it, which is a big part of why I’m writing this. It’s worth adding that managers are famously blind to this: in Amabile’s survey, only a handful of several hundred ranked supporting progress as the top motivator. Most ranked it last.
From creativity to vigilance
If I had to compress everything I’ve been thinking into one sentence, it’s this: we are moving engineers from creators to PR validators, and that’s a serious identity shift that deserves an honest conversation and group support.
Creation has a shape. You start with nothing, you build, you finish, you feel it. There’s a beginning, a struggle, and a closure, and the closure is part of the reward in and of itself.
Validation, on the other side, has no shape. There’s no wall, no breakthrough, no “done and it’s mine.” You’re on high alert the whole time, because your job now is to catch what’s wrong. That’s vigilance, sustained, all day, with no closure at the end. Humans can create for a long time without feeling exhausted. Sustained vigilance, on the other side, is a very reliable recipe for burnout.
Humans can create for a long time without feeling exhausted. Sustained vigilance, like code review, on the other side, is a very reliable recipe for burnout.
And this isn’t a soft complaint about vibes. There’s a whole body of research on what sustained monitoring does to a person, and the classic paper, by Warm, Parasuraman and Matthews, is blunt right in its title: vigilance requires hard mental work and is stressful. Watching for the thing that might be wrong measurably drains engagement and raises distress, and it gets worse the longer you hold it. Being the person who supervises several agents and reviews large diffs and switches context all day is a different kind of cognitive strain, and a genuinely taxing one.
The future software engineers
All of this also affects junior engineers, but from the opposite side. Junior engineers don’t just need to produce code, they need aprenticeship which comes from senior engineers and the messy reps: debugging by hand, tracing how the architecture actually fits together, absorbing code-review norms, making mistakes under a senior’s eye. If AI removes all that friction, it also removes the journey that turns a junior into a senior. We risk a generation that becomes productive before it becomes formed, shipping fast on top of a thin internal model of why the system works.
Anthropic recently described this happening inside its own walls. Engineers said the model had become the first stop for questions that used to go to a colleague, and some reported fewer mentorship moments and less collaboration as a result. The line that stuck with me wasn’t “AI writes my code now.” It was closer to “I need people less now, and that feels strange.” If there’s a durable human advantage in this, I don’t think it’s raw problem-solving speed. It’s the socially grounded stuff: care, trust, taste, mentorship, and taking responsibility to and for other people. Those aren’t just some soft nice-to-haves around the edges of engineering. For me, they are the foundational human infrastructure that makes engineering feel good.
AI, creativity and neurodivergence
I want to be fair to the other side of this, because it’s not all one direction. For a whole category of work, this shift is a gift, plain and simple. Small greenfield projects, weekend hacks, the creative side-quests you’d otherwise never have the runway to finish: AI is genuinely wonderful for those. It collapses the distance between an idea and a working thing, and the tedious structural middle, the part that used to quietly kill projects before they ever shipped, can now be handled for you. I think this matters most for the people whose brains are wired more for ideas than for scaffolding. For a lot of neurodivergent people especially, the executive-function slog of carrying a project all the way to done was a bottleneck. Hand that part to an agent and suddenly the ideas actually reach the world. And that’s not a small thing!
For example, my son, who’s autistic (lightly, level 1) has so many amazing ideas of these wonderful universes he builds in his head, but he doesn’t have the executive capacity (or what my mum would call “patience”) to sit down and organise his thoughts on a piece of paper, much less write a whole book. So I’ve been trying to encourage him to co-write a short story with AI. If I manage to convince him that AI is not the devil we should boycot, he’ll be able to share his beautiful universe of geometrical energy beings and mycelium with amnesia with all of us.
Used deliberately, the model is a draft partner and a provocateur. Use it lazily, and it becomes a shortcut that narrows your thinking and quietly does your first thought and your last thought for you.
So none of this means AI kills creativity. I believe it relocates it. The creative frontier moves off line-by-line implementation and up a level, into framing the problem, setting the constraints, exercising taste, critiquing, and deciding what is even worth building. But that’s only an upgrade if you keep using the muscles. Used deliberately, the model is a draft partner and a provocateur. Use it lazily, and it becomes a shortcut that narrows your thinking and quietly does your first thought and your last thought for you. You can watch which one is happening: the people I see most energised by AI right now are the ones using it on things they chose and own, personal projects and greenfield ideas, where the creativity is still theirs. The drain shows up on the mandated, must-maintain-it-for-years work, where you’re accountable for code you didn’t originate.
So what do we actually do
I don’t think the answer is to romanticise the old way and refuse the new one. The work has changed and it’s not changing back. But if the shift is real and the cost is real, then part of my job, part of every engineering manager’s job right now, is to design the environment so the cost doesn’t land on people’s health.
A few things I’m trying, or planning to. I’d put talking about it first.
Name the neurochemistry, out loud, with the team
Half the relief, I think, comes from people understanding that “this doesn’t feel as good anymore” is not a personal failing or a sign they’re washed up. It’s a brain doing exactly what it was trained to do, meeting a job that stopped delivering the input it was trained on. That’s a sane reaction to a real change, and saying so out loud takes the shame out of it.
Protect deep work as a real, defended thing
Not all the work has to become shallow orchestration. I’ll be honest that I’m not sure how far I can push this inside my own org, because the maintenance load on six widely-used libraries doesn’t leave a lot of white space. But there’s a version I think is viable: carving out small greenfield projects in the ecosystem where an engineer can build something end to end and own it fully. Even a couple of protected blocks like that keep people from hollowing out. I want to be able to clearly say that this is allowed and valued, not something you sneak in around the review queue.
Treat the review load as real and bounded
The PR firehose is the most measurable stressor we have, so measure it. Cap it, rotate it, set triage rules so “keep up with all of it, forever” stops being the silent standard. If the day is going to be mostly review, prepare for it mentally and otherwise. Mark when the queue is genuinely clear. Celebrate when a hard review catches a real bug, because that’s a small win too, and small wins are the currency Amabile was talking about.
The first person on my team to name this out loud did it recently, and my honest first reaction was relief, because I’d been waiting for it, and because someone saying it is a gift, not a problem. It means they trust me enough to tell me the work feels different, and it means the rest of the team is watching how I respond. That response matters as much as any process I put in place afterward. It also reminded me that the developers arguing about all this online aren’t just complaining. We’re facing a collective identity crisis, trying to redefine what craft and value and dignity mean under new conditions. These conversations are part of how we adapt.
We spent years building brains that get their reward from the fight. We’re now handing those brains a job with a lot less fight in it. And yes, that’s not a reason to reject the tools, but it is a reason to be deliberate about where we still let people struggle, where we protect the deep work, and how we help each other find the kick again in a job that’s real work, just a different kind of it.
We're facing a collective identity crisis, trying to redefine what craft and value and dignity mean under new conditions. These conversations are part of how we adapt
Because the real question isn’t whether AI can write more code than we can. It’s whether we can redesign the work so that the speed doesn’t cost us the things that made us good in the first place: judgment, style, apprenticeship, and each other.
I don’t have the whole answer yet, but I’ll keep musing on this. If you’re a manager feeling the same thing, or an engineer who’s noticed the kick going quiet, I’d genuinely like to hear how you’re handling it. This one is too big to figure out alone and we’re in this together! 💜