The Assembly Line Judge

"I shipped more code last quarter than any quarter in my career. I also felt more drained than any quarter in my career." That's Siddhant Khare, an infrastructure developer, writing about a paradox that thousands of engineers are quietly living through.¹

Khare isn't burned out in the traditional sense. He's not working longer hours. He's not fighting impossible deadlines. His code is shipping. His metrics look great. But something has changed about the kind of work he does, and it's hollowing him out.

"We used to call it an engineer," he writes. "Now it is like a reviewer. Every time it feels like you are a judge at an assembly line and that assembly line is never-ending, you just keep stamping those pull requests."

This is the new developer experience: the tools got better, the output got bigger, and the humans got emptier. The data says it's happening everywhere. The science says it was always going to. And almost nobody in a position to fix it is talking about it honestly.

The Paradox in Numbers

In March 2026, BCG published a study of 1,488 US workers and gave the phenomenon a name: "AI brain fry." Workers with high AI oversight demands expended 14% more mental effort, reported 12% more mental fatigue, and experienced 19% greater information overload than their peers. Fourteen percent of AI-using workers reported experiencing it. Those who did made 39% more major errors and reported 33% more decision fatigue.²

They described a "buzzing" feeling. Mental fog. Slower decision-making. Headaches. Productivity, BCG found, peaks at three simultaneous AI tools and degrades beyond four.

The Stack Overflow 2025 Developer Survey — over 49,000 respondents, the largest dataset we have — tells a complementary story. AI tool usage climbed to 84%, up from 76% the year before. But trust collapsed: down to 29% from 40% the prior year, with only 3% reporting high trust. Nearly half — 46% — actively distrust AI accuracy. Positive sentiment about AI tools fell from 72% to 60%.³

Read those numbers again. Four out of five developers are using tools that seven out of ten don't trust. Forty-five percent say debugging "almost-right" AI code is time-consuming. Three-quarters would still rather ask a human for help.

And then there's the METR randomized controlled trial. Sixteen experienced open-source developers were given AI tools and tracked carefully. They were 19% slower with AI assistance. They believed they were 20% faster.⁴

That perception gap — feeling faster while actually being slower — is not a rounding error. It is a 39-percentage-point disconnect between experience and reality. It suggests that AI coding tools are doing something to the developer's subjective experience that has nothing to do with productivity.

The Assembly Line

The code review data explains where the time goes. According to Faros AI's analysis of engineering metrics, teams using AI coding tools saw a 98% increase in PR volume, with review time up 91%.⁵ CodeRabbit's research found that AI-generated code surfaces 1.7 times more issues than human-written code.⁶ Average PR sizes increased 154%, leading to a 9% rise in bug counts.⁷

As LogRocket's analysis put it: "Code review in the age of AI is a different job. You're not validating correctness. You're judging necessity."⁵

The numbers are disorienting because they point in opposite directions. More code. More bugs. More PRs. More review time. More output. More exhaustion. The AI made everything faster except the part that requires a human brain, and then it made that part worse.

CodeRabbit's research puts a fine point on it: "Reading unfamiliar code is exhausting, requiring developers to reverse-engineer someone else's thought process. With AI-generated code, reviewing 'your own code' has become reviewing someone else's code."⁶

This is the crux. When you write code, you hold the mental model — you know why every line exists, what each function is trying to do, where the edge cases hide. When you review AI-generated code, that model doesn't exist in your head. You have to reconstruct it from output you didn't produce, line by line, in a codebase the AI touched in ways you didn't expect. LinearB's analysis of 8.1 million pull requests found that AI-generated PRs wait 4.6 times longer before a reviewer even picks them up — and once review starts, the acceptance rate is just 32.7%, compared to 84.4% for human-written code.²³ Reviewers aren't just slower. They're rejecting two-thirds of what the machine produces. The code is faster to produce and slower to trust.

And you do this all day. Every day. PR after PR, file after file, one more diff to read, one more "looks right... I think?" decision to make.

The assembly line never stops.

The Science Already Knew

In 1983, a British computer scientist named Lisanne Bainbridge published a paper called "Ironies of Automation." It is nine pages long and it predicted everything that is happening to software developers right now.⁸

Bainbridge's central argument was deceptively simple: the more reliable automation becomes, the worse humans get at supervising it. Automation changes the human role from active operator to passive monitor — but humans are fundamentally terrible at passive monitoring. We can't sustain vigilant attention for more than about thirty minutes before our defect detection starts to degrade.

This was not a theoretical concern. Norman Mackworth demonstrated it in 1948 with a lab experiment designed to simulate RAF radar monitoring conditions, finding a 10-15% decline in detection accuracy within the first half hour.⁹ Drew, Vo, and Wolfe showed it again in 2013 when 83% of expert radiologists failed to notice a gorilla — an image 48 times larger than a lung nodule — embedded in a CT scan they were examining. Eye-tracking confirmed most of them looked directly at it.¹⁰

The phenomenon has a name: vigilance decrement. The longer you monitor a mostly-correct stream of information for occasional errors, the worse you get at finding them. This is not a character flaw. It is not laziness. It is a fundamental property of human cognition — well-established across seventy-five years of research — and it describes exactly what AI coding tools are now asking millions of developers to do for eight hours a day.

Parasuraman and Manzey published the definitive review in 2010, integrating decades of automation complacency research. Their finding is bleak: complacency affects both naive and expert operators, and it cannot be overcome with practice.¹¹ You cannot train yourself out of it. The architecture of human attention won't allow it.

The NTSB cited "automation complacency" as a causal factor in the 2018 Uber self-driving car crash that killed pedestrian Elaine Herzberg.¹² Tesla users have been documented exhibiting "passenger-like viewing behaviours" while ostensibly supervising Autopilot — sleeping, scrolling phones, staring blankly. The automation was reliable enough that the human stopped paying attention, and then the automation encountered something it couldn't handle, and there was nobody home.

Nobody has died because a developer rubber-stamped a bad PR. But the pattern is identical. The AI is right often enough that you relax. You skim. You approve. And then it's wrong in a way you would have caught at 9am but can't see at 4pm because you've been judging an assembly line for seven hours.

The Flow You Lost

There is another cost, harder to measure but possibly more important.

Mihaly Csikszentmihalyi spent decades studying the psychology of optimal experience — what he called "flow." The state where you lose track of time, where action and awareness merge, where the work is the reward. His research identified specific conditions: the challenge must match your skill level, the goals must be clear, and the feedback must be immediate. When these conditions align, the dorsolateral prefrontal cortex — the part of the brain responsible for self-monitoring and self-criticism — quiets down, and you enter a state of unselfconscious absorption.

Writing code can produce deep flow. Reviewing code almost never does.

Flow requires what Csikszentmihalyi called "action-awareness merging" — the feeling that you are the work, not observing it. When you write code, your decisions create the system. When you review AI-generated code, you are reacting to someone else's decisions — or something else's decisions — after the fact. The feedback loop is indirect. The sense of control is gone. The challenge is inconsistent: sometimes the AI produces exactly what you would have written, sometimes it produces something baffling, and you have no way to predict which.

Gloria Mark at UC Irvine has found through her broader body of research on workplace interruptions that it takes an average of 23 minutes and 15 seconds to return to a task after an interruption, with roughly two intervening tasks before returning.¹³ Her CHI 2008 paper with Gudith and Klocke further showed that interrupted workers complete tasks faster but with significantly more stress — the speed comes at a cognitive cost. Research by O'Conaill and Frohlich found that 40% of interrupted tasks in the workplace are never resumed at all.¹⁴

AI tools are interruption machines. As Khare puts it: "I might touch six different problems in a day. Each one 'only takes an hour with AI.' But context-switching between six problems is brutally expensive for the human brain."¹

The Cisco/SmartBear code review study found that defect detection rates plummet after 60-90 minutes of continuous review, and that the optimal review size is 200-400 lines of code.¹⁵ AI coding tools routinely generate hundreds of lines per interaction. The math doesn't work. The human's cognitive window is fixed. The machine's output is not.

What developers have lost is not just efficiency or accuracy. They have lost the thing that made programming feel good. The craft. The flow. The quiet satisfaction of building something from nothing. The state that made it possible to code for fourteen hours on a weekend and feel energized instead of drained.

Now they sit in front of a screen, watching code appear that they didn't write, making judgments about code they don't fully understand, and wondering why they're exhausted by 2pm even though they "barely wrote anything."

Am I Still a Developer?

In October 2025, Simon Hojberg published "The Programmer Identity Crisis." It got 460 upvotes on Hacker News — a strong signal that it hit a nerve.¹⁶

Hojberg argued that prompt engineering erodes the deep engagement, creative problem-solving, and theory-building that define quality software work. "Code reviewers are losing their minds," he wrote, "realizing they're now the first layer of quality control instead of one of the last."

In January 2026, an "Ask HN" thread appeared with the title "Identity crisis as a software engineer because of AI."¹⁷ Experienced engineers — people with years or decades of expertise — shared their struggles with a question that shouldn't be hard but suddenly is: what is my job now?

On DEV Community, a post titled "Am I still a real developer if AI writes half my code?" described the experience as "a confession, a small identity crisis, and the weird guilt nobody warned us about."¹⁸

GitHub's own Octoverse 2025 report tried to reframe this positively, suggesting that developers furthest along with AI describe their role as "creative director of code" — focused on orchestration and verification rather than implementation.¹⁹

"Creative director of code" is a nice phrase. It also describes a person who doesn't write code. For many developers, writing code is not an obstacle to be automated away — it is the point. It is why they chose this career. It is the source of their flow, their identity, their professional satisfaction. Telling them they're now "creative directors" is like telling a chef they're now a "creative director of meals" who supervises a robot kitchen. The meals might be fine. The chef is not.

Marco Kotrotsos captured the broader dynamic: "Organizations would treat every minute saved as a minute available for more work. The result is not less burnout. It is a different kind of burnout, and it is hitting the people who embraced AI the hardest."²⁰

This is the cruelest part. The developers most affected are not the resisters — they're the early adopters. The ones who leaned in, learned the tools, rebuilt their workflows. They did everything right. And their reward is a job they no longer recognize.

The GPS Problem

Khare uses an analogy that's worth sitting with:

"Before GPS, you built mental maps. You knew your city. After years of GPS, you can't navigate without it. The skill atrophied because you stopped using it."¹

Research backs him up. Studies on GPS use have shown measurable declines in spatial memory and navigation ability among heavy users. The cognitive capability doesn't just go unused — it deteriorates. The brain, like any other system, follows a use-it-or-lose-it principle.

What are developers offloading to AI right now? Debugging intuition. Architecture sense. The ability to hold a complex system in your head. Pattern recognition built from thousands of hours of writing code — not reading it, writing it. The kind of knowledge that only comes from getting things wrong, staring at a stack trace for forty minutes, and finally understanding why.

You don't build that knowledge by approving pull requests.

The academic study "From Gains to Strains" surveyed 442 developers and found that GenAI adoption heightens burnout by increasing job demands. One respondent summarized it precisely: "Although AI is helpful, it's not that helpful that it would make that big of a difference. At the end, I am doing more work than before."²¹

More work. Different work. Worse work — in the sense that it's work that grinds against the grain of human cognition rather than flowing with it. The assembly line judge, stamping approvals on code they didn't write, fighting vigilance decrement, losing flow, questioning their identity, and wondering why a job that should be easier than ever feels harder than it's ever been.

What Now?

We don't have good answers yet. That's worth saying honestly.

The BCG study found that productivity degrades past three simultaneous AI tools, which suggests that restraint — using fewer tools more deliberately — may help more than optimization.² The Cisco code review research suggests hard limits on review sessions: 200-400 lines, under an hour, with real breaks between.¹⁵ The flow state literature says you need at least 23 uninterrupted minutes to get into deep work — which means the six-problems-in-a-day workflow that AI enables is the six-interruptions-in-a-day workflow that flow research says will destroy you.

Some developers have found their own solutions. One senior engineer, after 150,000 lines of AI-generated code, stopped using AI tools entirely — not because they didn't work, but because the work they produced wasn't worth the cognitive cost of verifying it.²² Others have described deliberately choosing to write certain modules by hand, not for speed but for understanding. For feel.

These are individual adaptations. They don't address the structural problem: organizations are setting expectations based on AI-augmented output, and developers who slow down to protect their cognition look, on paper, like they're underperforming.

Bainbridge saw this coming too, forty-three years ago. The irony of automation, she wrote, is not just that humans get worse at supervising machines. It's that the humans who designed the system assumed the human role would be trivial — just watch the machine and intervene when it breaks. They didn't account for the fact that watching is one of the hardest things a brain can do.

The developers stamping pull requests at 4pm know this. They feel it in their foggy heads and their aching eyes and their drifting attention. They feel it in the weird guilt of being exhausted by a job that was supposed to get easier. They feel it in the question they don't ask out loud because they're afraid of the answer:

If the machine writes the code and I just approve it, what am I?

Nobody has a good answer yet. But the first step is admitting the question exists.