They stopped building and started approving
The cognitive job nobody scoped when they automated the old one
Spotify’s best developers haven’t written a line of code since December. Anthropic’s head of Claude Code hasn’t written code in over two months. OpenAI says GPT-5.3-Codex was instrumental in creating itself. The Fortune headline calls it a coding revolution.
It is. But not the one the headline describes.
The revolution isn’t that engineers stopped typing. It’s that the cognitive profile of the job changed overnight, and nobody scoped the replacement. We took a role that was roughly 70% production and 30% judgment, and we flipped the ratio. What used to be a maker’s job is now a reviewer’s job. What used to burn calories through creative construction now burns them through continuous evaluation.
That’s not a productivity story. That’s a job redesign that happened without a job description.
The decision load nobody measured
Here is what an engineer’s Tuesday looked like eighteen months ago: write code, run tests, debug, commit, review a PR or two, write more code. The cognitive rhythm was build-review-build. Deep production work punctuated by evaluation. The ratio was weighted toward making things.
Here’s what Tuesday looks like now for the engineers Fortune describes: read AI-generated code, assess whether it does what you intended, check for subtle misunderstandings in the spec, evaluate whether the test coverage is meaningful or just structurally present, catch the architectural choice the model made that’s locally correct but globally wrong, approve or redirect, then repeat. All day.
That second Tuesday has a name in the psychology literature. It’s called monitoring work. And research on decision fatigue has been telling us for years what monitoring work does to people: it depletes the same prefrontal resources you need for the judgment calls you’re being paid to make. The engineer isn’t producing less value. They’re producing a different kind of value, one that draws down cognitive reserves faster than the old kind did, with fewer of the regenerative rewards that sustained craft provides.
Steve Yegge named the feeling in his AI Vampire piece last week. He described falling asleep suddenly after coding sessions, colleagues considering nap pods, the addictive intensity followed by collapse. He framed it as a value-capture problem: who gets the 10x surplus? Fair question. But the mechanism underneath is simpler and more dangerous. The work changed from making to judging, and human brains are not designed to judge at production speed for eight hours a day.
I’ve written before about how organizations treat intensity as a personality trait rather than a resource with a burn rate. The AI coding revolution is about to test that failure mode at industry scale.
Craft was the recovery. They automated the recovery.
This is the part that nobody in the productivity narrative seems to notice.
Writing code is hard. But it is also satisfying in a way that reviewing code is not. There’s a rhythm to construction: you think, you type, you run it, it fails, you adjust, it works. That cycle is a feedback loop with a built-in reward signal. The brain registers progress. Dopamine does its thing. You look up and three hours have passed. That’s flow.
Reviewing AI-generated code has no flow. You’re scanning for errors you don’t expect in output you didn’t produce. The cognitive mode is vigilance, not creation. Vigilance is expensive. Military research on monitoring tasks figured this out decades ago: sustained attention to a stream of mostly-correct output degrades performance within 20 to 30 minutes. The errors you’re supposed to catch are rare, which makes them harder to detect over time, not easier. This is the vigilance decrement, and it applies directly to the new engineering workflow.
When Fortune reports that developers have “become directors of AI systems that do the typing for them,” that framing makes it sound like a promotion. Directors sit above the work. They make strategic calls. That’s not what’s happening. What’s happening is closer to quality assurance at machine speed, and QA has always been one of the most cognitively draining roles in software because it requires sustained attention without the generative satisfaction that sustains it.
The engineers who were doing their best work in the old model had a built-in cognitive recovery mechanism. The making was the recovery. The act of writing code replenished something that reviewing code only spends. And we just automated the replenishment.
The identity problem arrives on a six-month delay
There’s a second cost, quieter than the fatigue, that won’t show up in this quarter’s feature velocity.
I’ve written about what happens to people after a promotion changes their role: the proof system that used to tell them they were good stops compiling. Their error bars widen. They start performing competence instead of exercising it.
The AI coding shift is doing that to an entire profession at once. An engineer who built their identity around writing elegant, efficient code now spends their day evaluating someone else’s output. Their skill is still needed. Their judgment matters more than ever. But the daily experience of the job no longer reinforces the identity that got them there.
At the companies Fortune profiles, the ones shipping 50 features a quarter with AI workflows, the individual engineers are producing measurably more. They are also, I’d bet, running a low-grade identity crisis that won’t surface for another six months. Because the thing they were good at, the thing that made them feel like engineers, is now done by a model. And “approving the model’s work” doesn’t carry the same psychic weight, even when it’s objectively harder.
This is the impostor dynamic at scale. Not because the engineers aren’t competent. Because the feedback loop that used to prove their competence has been replaced by one that doesn’t. They went from being makers who occasionally review to being reviewers who occasionally intervene. The title didn’t change. The calendar didn’t change. The felt experience of the work changed completely.
The Spotify problem
Spotify’s co-CEO said their best developers fix bugs and add features via Slack on their phones during their commute, then merge to production before reaching the office.
Read that sentence again from the engineer’s perspective.
You are on a train. You get a Slack notification. You read a description of what the AI did. You approve it. The code ships to production. You haven’t opened your laptop. You did this between stations.
That is an extraordinary productivity achievement. It is also a description of a job with zero deep work, zero craft satisfaction, and zero recovery time between decisions. The engineer on that train is doing pure approval work, the most cognitively expensive, least psychically rewarding form of engineering, in the interstices of their commute.
When I wrote about how vibes-based evaluation systems create invisible exhaustion, the mechanism was ambiguous success criteria forcing people into constant self-monitoring. The AI coding workflow creates a different version of the same problem. The criteria are clear, the code works or it doesn’t, but the work provides no signal that you personally are good at anything. You approved correct code. The model wrote correct code. Who did the work? The throughput metric says the team. The engineer’s nervous system says nobody.
What this means if you’re running a team
The Fortune article frames this as a technology story. Engineers adopted new tools. Productivity increased. That’s true and incomplete. The complete version is: the cognitive profile of software engineering changed faster than any job redesign in the history of knowledge work, and the organizations celebrating the productivity gains have not yet scoped the human cost of the new role.
If you’re a technical leader watching your team’s throughput climb on AI workflows, here’s what to look for.
Monitor for decision fatigue, not just velocity. Your team is shipping more and reviewing more. Track not just what got done but how many approval decisions each person made in a day. If an engineer is making 40 to 60 review-and-approve decisions daily, their judgment quality is degrading by afternoon whether they know it or not. Decision fatigue research shows this is a neurological constraint, not a motivation problem.
Preserve maker time, deliberately. If AI handles 70% of code generation, your engineers still need blocks of time where they are producing, not evaluating. Let people write some code by hand. Not because it’s efficient, because it’s cognitively regenerative. A senior engineer who spends two hours a week on a side project they build themselves will make better judgment calls during the other 38 hours. Treat craft like a recovery protocol, not a nostalgic indulgence.
Name the identity shift out loud. If your team went from writing code to reviewing AI output, say so explicitly. Acknowledge that the job changed. Define what the new version of “good” looks like. Otherwise you’re running the same measurement vacuum I’ve described in vibes-based cultures: people performing the old role’s signals because nobody defined the new role’s criteria.
Watch for the six-month attrition spike. The engineers most at risk are your best ones. The people who derived the most identity from craft will feel the loss of craft most acutely. They won’t leave in the first quarter. They’ll leave after the novelty wears off and the daily experience of the work settles into what it actually is: monitoring, approving, intervening. When your highest-performers start asking for transfers to teams with less automation, that’s not resistance. That’s a signal about the sustainability of the new model.
The revolution is real. The cost is unscoped
I’m not arguing against AI coding tools. The productivity gains are real and they’re not going away. What I’m arguing is that the organizations adopting these tools are treating them as a technology change when they’re actually a job redesign, and job redesigns have psychological costs that show up on a delay.
The engineers in the Fortune article haven’t abandoned traditional programming. They’ve been moved into a different job that happens to have the same title, the same desk, and the same Slack channels. The old job built things and occasionally judged them. The new job judges things and occasionally intervenes. Those are different cognitive profiles with different sustainability characteristics, and the second one is harder to maintain over time.
Human systems have a burn rate. If your productivity model doesn’t account for it, you’re not running a revolution. You’re running a sprint and calling it the future.