AI brain rot: what happens to engineers when the hard part becomes optional

A pull request lands. The code is clean, the tests pass, the naming is better than yours. You ask the author why they used a queue there instead of just calling the service, and there's a pause.

Not the pause of someone gathering their thoughts. The pause of someone reading their own code for the first time.

That pause is what this piece is about.

Last year researchers at MIT put 54 people through four essay-writing sessions while recording their brain activity. One group used ChatGPT, one used a search engine, one used nothing. In the first session, 83% of the ChatGPT group couldn't quote a single line from the essay they'd just handed in. Almost everyone in the other two groups could. They called what builds up in that gap cognitive debt.

The word people reach for is brain rot. Oxford made it word of the year in 2024, after usage jumped 230% in twelve months, and back then it meant short video and what it was doing to teenagers. The claim now is that AI is doing the same thing to engineers.

I think it's worth taking seriously. I also think the evidence is more interesting than the slogan, and it points somewhere much more specific than "we're all getting dumber."

The short version

• The cognitive decline everyone blames on YouTube started with people born in 1975. The timeline doesn't work.
• The calculator research that gets used to shut down these arguments actually contains the sharpest warning in the whole debate.
• The AI studies all show the same shape: output goes up, checking goes down, and confidence follows the output rather than the checking.
• The same technology made professional Go players measurably better. The difference is the feedback loop, not the model.
• The real risk isn't that individual engineers get worse. It's that we stop producing the seniors who can tell when the machine is wrong.
• Aviation hit this exact problem and fixed it by scheduling practice. Software hasn't.

We've been here before, but not quite like this

Every new tool gets this complaint. Socrates thought writing would wreck people's memories. He wasn't entirely wrong, and he also wasn't a reason to stop writing things down.

That's the standard reply to any deskilling worry, and it's a bit too comfortable, because there's something in the data that doesn't fit it.

Average measured intelligence in rich countries stopped climbing and started falling. Norwegian researchers had conscript test records covering three decades of birth cohorts, and they found scores peaked around the 1975 cohort and have slid since, roughly a fifth of a point a year.

The clever part is how they proved it was environmental. The decline shows up within families. A younger brother scores lower than his older brother. That rules out genetics. It rules out immigration. Something in the environment is doing it.

But look at the date. The turning point is people born in 1975. They were teenagers before the web existed. Whatever this is, TikTok didn't start it.

Two things follow, and both matter here. Environments really do change what minds are good at, at scale, measurably. And the cause is almost never the device everyone's pointing at.

The calculator argument, which everyone gets backwards

Every rung on that ladder took away work the previous generation thought was the job. Nobody seriously wants to go back. The question was never whether to use the tool. It's what the removed effort was quietly doing while we weren't paying attention.

Calculators are the best-studied case, and they usually get cited to end the argument. A 1986 review pulled together 79 separate studies and found that calculator use alongside normal teaching improved kids' pencil-and-paper skills and their problem solving. Students got better at the thing the tool supposedly replaced.

At every grade except one.

Sustained calculator use in Grade 4 appeared to hold back basic skills in average students.

Grade 4 is roughly when long division gets learned. So the tool was harmless everywhere except the exact moment the skill was forming.

That's the finding worth carrying around. Not "assistance is bad." Assistance while you're building the skill is a completely different thing from assistance after you've built it, and the two look identical from the outside.

There's a second effect worth knowing about. A study in Science found that when people expect information to stay available, they remember where to find it rather than what it said. Memory didn't rot. It got reallocated. Something similar is happening with reasoning now: not erased, just redirected towards knowing which prompt gets the answer.

Reallocation is fine as long as you can still get the original back.

What the research actually shows

Here's the current state of play, and I've tried to be fair about what each one can and can't support.

The one that unsettles people. METR ran a proper randomised trial with 16 experienced developers on repositories they'd worked in for an average of five years. Tasks were randomly assigned to allow or forbid AI. Beforehand, the developers expected to be 24% faster. Afterwards, they reported being 20% faster. They were 19% slower. That's a 39-point gap between what people felt and what the clock said, in a group with every reason to be honest. It's a small sample and METR has since said it's changing the design, which is what careful researchers do, so don't treat one trial as the final word.

The one that explains why. Microsoft and Carnegie Mellon surveyed 319 knowledge workers about 936 real uses of AI at work. People described their thinking shifting from producing to verifying, which sounds like a promotion. It only is if the verifying happens, and the more people trusted the tool, the less of it they did. Their confidence in themselves pushed the other way. People who trusted their own judgement checked more.

The one about security. In a controlled study, participants with an AI assistant wrote less secure code and were more confident it was secure. Both halves of that sentence matter.

The one about the edges. In a field experiment with 758 consultants, AI helped enormously on tasks inside the model's competence. On a task deliberately picked to sit just outside it, the AI users were 19 percentage points less likely to get the right answer than people working with no AI at all. The frontier is jagged and there's no signal when you cross it.

The one in the codebase. GitClear tracks millions of changed lines. Refactoring, measured as moved lines, is down 70% against 2022. Duplicated blocks are at the highest level they've recorded. That's correlation, not proof, but it's the exact fingerprint you'd expect from generated code that works and nobody consolidates.

The one from the developers themselves. Stack Overflow's 2025 survey found 84% using or planning to use AI tools, only 33% trusting their accuracy, 46% actively distrusting, and 3% highly trusting. The single biggest frustration, at 66%, is "AI solutions that are almost right, but not quite."

Read that last one again. Developers don't believe the output. They use it anyway, constantly. And the thing they complain about most is the failure mode that's hardest to catch by reading.

None of this proves the brain rot thesis. Put together, though, it keeps showing the same shape: more output, less checking, and confidence attached to the wrong one of the two.

So why did Go players get better?

Here's the part that breaks the doom story.

When AlphaGo beat Lee Sedol in 2016, everyone assumed human Go would wither. Researchers later scored 5.8 million professional moves across 71 years using an engine to judge each one. Human decision quality went up after superhuman AI arrived. Players started making more moves nobody had played before, and those novel moves were better than the novel moves of earlier eras.

The economics agrees in places. A study of 5,179 customer support agents found productivity up 14% overall and 34% for the newest, least skilled workers, with barely any effect on the veterans. The model seemed to spread what the best people already knew.

So AI isn't a deskilling machine. It does whatever the feedback loop around it allows.

Go has something software doesn't. Every move gets an objective verdict, immediately, and you can't argue with it. Pick up a bad habit from an engine and you find out. There's no version of Go where a weak move quietly works for nine months.

Code is almost the opposite. A generated function that's subtly wrong compiles, passes the tests that were generated next to it, survives review, and falls over eight months later in a way nobody connects to the afternoon it was accepted. The support agents had a script, a resolution metric and a customer on the phone. An engineer merging a plausible refactor has none of that.

Go players got better because they couldn't fool themselves. We can.

What the struggle was doing

Three things explain that loop, and none of them are about AI.

Difficulty isn't just a cost, it's a mechanism. Decades of learning research points the same way: the conditions that make learning feel slow and unpleasant, like being forced to retrieve something from memory or having your practice spaced out awkwardly, produce better retention. Feeling fluent while you learn is a terrible predictor of having learned. And fluency is exactly what a good model hands you.

A worked example only teaches if you then do one yourself. Showing a beginner a solved problem beats letting them flounder, that part is well established. The bit that matters is what comes next: the learner gets a half-finished problem and has to complete it. AI gives you the worked example and then completes the problem too. The scaffolding goes up and the building never does.

Automation takes the easy parts and leaves you the hard one. An engineer called Lisanne Bainbridge wrote this down in 1983, in a paper called Ironies of Automation. Automate the routine bits and the human is left doing two things: monitoring, which people are genuinely bad at, and taking over when it fails, which needs exactly the manual skill that no longer gets used. The operator has to be an expert in the rare case using skills the common case no longer exercises. And because the automation is usually right, people check it less and less, which is why they miss it when it isn't.

She was writing about chemical plants. Every word of it describes a senior engineer reviewing generated pull requests.

Put the three together and you get the conditions under which help actually helps:

1. The effort survives at the stage where the mental model forms.
2. Feedback is fast, honest and hard to argue with.
3. Someone can still take over when the tool is wrong.

Go has all three. Essay writing with ChatGPT has none. Software has the third one only for as long as the current crop of seniors is still working.

The bit that should actually worry you

This is where it stops being about individual willpower.

Junior work was never really about the output. Fixing the flaky test, writing the migration, chasing a bug through three services and a queue. The ticket was the excuse. The point was what got built in the person doing it. Ten years of those tickets is what a senior engineer is made of.

It's also the most documented, most standardised, most codified work in the building, which makes it exactly what a model is good at.

The labour data has started showing it. Stanford's Digital Economy Lab, working from ADP payroll records, finds workers aged 22 to 25 in the most AI-exposed jobs now facing an employment gap of about 19% against peers in less exposed work, up from about 15% a year earlier. Software development is one of those jobs. It's happening through slower hiring rather than layoffs, and it's concentrated in roles built on codified knowledge. Roles built on the tacit stuff, the kind you get from mentoring and time, have held up fine.

The researchers are careful about this and so should we be. Interest rates, the post-pandemic correction and shifts in education could all be contributing.

But follow the recursion anyway. Senior engineers are made out of former junior engineers. Senior review is the control that makes generated code safe, which DORA's 2025 report says outright when it notes that AI doesn't replace code review, it makes it matter more.

Stop hiring and training juniors for a decade and you don't get a shortage of juniors in a decade. You get a shortage of seniors, right around the time you've made yourself maximally dependent on their judgement.

That's the version of brain rot that should keep an engineering leader up at night. Not that anyone gets dumber. That the organisation loses the ability to produce the people who check the machine.

There's a fair counterargument, which is that "junior" just changes meaning, and the support-agent result generalises: new engineers get productive faster than they ever could before. That might well be true for bounded, scored, scripted work. Architecture, incident response and debugging an unfamiliar system aren't any of those. And the same study that found huge novice gains found almost nothing for the experts. It was good at getting people to a known standard, not at producing the judgement that sets one.

Aviation already solved this

On 1 June 2009, Air France 447 left Rio for Paris with 228 people on board. At cruise altitude the speed sensors iced over, the readings went unreliable, and the autopilot handed control to a crew who, like most pilots of their generation, had flown almost their entire careers with the automation on. They didn't recognise that the aircraft had stalled. It fell for about three and a half minutes.

The investigation pointed at a crew handling a high-altitude manual situation they'd effectively never practised.

What happened next is the interesting part. Nobody suggested removing the automation. Nobody proposed going back to flying by hand. They made the practice mandatory.

The FAA's guidance on manual flight proficiency tells airlines their policy should encourage pilots to hand-fly whole departures and arrivals, and the whole flight where practical, with the autopilot and autothrottle off in various combinations. From 2019, training had to include stalls, upsets, unreliable airspeed and the rest.

Aviation decided proficiency is something you schedule, not something you hope survives.

We have nothing like it. No recency requirement, no rostered manual block, no standard anywhere that says an engineer should have built something from an empty file this quarter. We took the automation and skipped the part where you keep the humans current.

Where this ends up

In 1909, E. M. Forster published a story called The Machine Stops. People live alone in identical underground cells. The Machine feeds them, entertains them, connects them, supplies their ideas. Going outside is considered vulgar. Nobody understands how the Machine works, because understanding it stopped being necessary generations ago.

Then it starts to fail. The repair system itself breaks. And there's nobody left who knows what to do.

Forster's people aren't oppressed. They're comfortable, well fed and intellectually busy. That's the whole point of the story and the reason it's outlived almost everything written alongside it.

The question everyone's circling right now is whether a world where nobody has to do anything hard means a population that's controlled or just one that's idle. I think that's the wrong split. Dependence isn't the same thing as control. But dependence is what makes control cheap.

If most people can't evaluate, audit or rebuild the systems they live inside, nobody has to coerce anyone. Whoever can maintain those systems sets the terms by default. They don't need bad intentions. They just need to be the only ones who can.

The middle one is the default, and not because anyone picks it. It's the default because keeping people competent is currently nobody's job. It isn't in a quarterly target, a delivery metric, a performance review or a regulation. Every single decision to let the model handle it is defensible on its own. The aggregate is capability slowly moving out of the population and into a small number of institutions.

A utopia where nobody needs to do anything is only a utopia while somebody can still do everything. Otherwise it's a well-catered dependency with a failure mode nobody has rehearsed.

Which one we get isn't decided by how good the models become. It's decided by whether anyone is accountable for the skill that's left.

What to actually do about it

For yourself. One rule, and it costs almost nothing: never accept code you couldn't explain cold, to a colleague, with the tool shut. If you can't, read it until you can or write it yourself. Keep a mental list of things you can still build from an empty file, and notice when something falls off it. Write the first version of anything you want to still be able to do in five years. Set aside a bit of work each week where you don't use assistance at all, the same way a pilot hand-flies an approach on a clear day rather than on the day the instruments quit.

For your team. Review the reasoning, not just the diff. Ask why, and treat the pause at the top of this piece as information rather than an awkward moment. Keep juniors on work that builds mental models even when the model would finish it faster, and be honest that you're choosing to pay a training cost. Interview with the tools off at least once, not because that's how the job works, but because you need to know what's underneath.

For your organisation. Measure the checking, not the volume. Merged pull requests and closed tickets look fantastic in exactly the failure mode I've described. Track the things that actually tell you something: defects reaching production, time spent debugging generated code, how often review catches something the model got confidently wrong. Then decide who is responsible for how good your engineers are in five years, and write their name next to it. If nobody owns it, it's already sliding.

Questions people ask

Is AI brain rot real? Not as permanent damage. Nobody has shown that. What has been shown is weaker recall of AI-assisted work, less checking among the people who trust the tools most, and a big gap between how fast people feel and how fast they are. Cognitive debt is the better term. Something is owed and it gets paid later.

Does AI make developers slower? Sometimes, and not in the way either camp claims. The one randomised trial with experienced developers on familiar code found them 19% slower while feeling 20% faster. Other studies find big gains, especially for beginners on well-scored tasks. The reliable finding isn't the direction. It's that people are bad at judging this about themselves.

Should junior engineers use AI? Yes, with one rule: not for the thing they're currently trying to learn. The calculator evidence and the worked-example research both land in the same place. Help after the mental model forms multiplies what you can do. Help during formation replaces the process that would have formed it.

Isn't this just the calculator argument again? Partly, and the calculator argument doesn't say what people think it says. Calculators helped at nearly every grade except the one where the skill was being built. The question for AI is which stage it's sitting in, and for a lot of early-career engineering work the answer is Grade 4.

Will AI replace engineers? The nearer question is whether it removes the path by which engineers get made. Early-career hiring in AI-exposed jobs is already visibly softer, and the work being automated first is the work people used to learn on.

The hard part was doing something

The honest version of this argument isn't that AI makes people stupid. It's that difficulty was holding something up, and we took it away without checking what.

Sometimes nothing. Nobody needs to do long division by hand, and nobody should write machine code to build a web form. Sometimes something quite specific: the mental model that lets you tell, in about four seconds, that a plausible answer is wrong.

The choice was never between using these tools and refusing them. That argument was over before it started. The choice is whether removing the effort is a decision somebody makes and compensates for, or something that happens to an industry while every individual step looks sensible.

Aviation made the decision. It scheduled the practice, mandated the drills and ate the cost. We haven't, and we're currently assuming it'll sort itself out.

It will sort itself out one way or another. In about ten years we'll find out what the hard part was doing.