Picture two people facing a deadline.
One is a student at MIT who has to hand in a problem that will be graded. The other just started as a software engineer: she has a ticket, a team waiting and a probation period hanging over her.
Both have an AI at hand. Both could stop to understand every step. But the clock keeps running.
For one, what’s at stake is a grade. For the other, maybe the job. Learning still matters, but delivering has more immediate consequences.
There’ll be time to understand it later.
Maybe.
Over the last few months I’ve seen, more than once, work conversations with not a single minute of human analysis left in them.
At first glance it looks like efficiency. But it actually makes us look for value in the wrong place.
As engineers, our value isn’t only in making something work. It’s also in understanding why it works.
I write very little code these days. And I still deliver almost as fast as ever. Not because I used to deliver at light speed, but because I kept the same engineering judgment.
If you asked me to write a reduce from memory, I might not even remember the syntax. But I know when it makes sense to use one, and why swapping an array lookup for a Map or a Set can make the code the AI just wrote much more efficient.
I didn’t learn that by copying and pasting from Stack Overflow (rest in peace… almost). I learned it by reading, studying, experimenting and questioning.
#.What MIT saw
In August this year, an MIT committee published a report on AI in teaching and learning. It records something the students themselves said: the temptation to hand off their thinking was greater when they feared missing a deadline.
It also warns that getting the right answer can create an illusion of learning. And that with so much focus on grades and credentials, anyone set on maximizing their GPA has a strong incentive to use whatever seems most effective.
To be clear: it’s a report built from consultations and surveys, not an experiment.
But it made me think about how we organize work. If we mostly evaluate the visible result, why are we surprised when someone prioritizes getting it?
A university isn’t a company, and none of this proves that fear of being fired makes anyone depend on AI. That’s my hypothesis, not a finding.
#.Delegating isn’t surrendering
The report uses a phrase that stuck with me: cognitive surrender. It cites research by Steven Shaw and Gideon Nave, at Wharton.
For them, it means accepting the AI’s answer with barely any scrutiny, and letting its reasoning replace your own.
Asking for help isn’t that. I can delegate a task and still be the one who decides whether it makes sense. Surrendering is adopting a conclusion because it comes explained with confidence. And remember: AI will almost never push back.
In their experiments, people consulted the AI on more than half of the problems, and when the AI was wrong, they got noticeably fewer right than people with no AI at all. It’s a preprint built on reasoning problems, not a study of software teams. But it leaves an uncomfortable question for engineering:
What’s the point of putting a person in charge of reviewing, if they have no way to review?
Can they explain what’s happening? Do they recognize a dangerous assumption? Are they allowed to stop the release if they still don’t understand something?
#.A closed ticket doesn’t tell the whole story
In an Anthropic experiment, 52 developers, mostly junior, learned a new Python library, with and without AI help. Afterwards, the AI group averaged 50% on a quiz; the group without AI, 67%. The biggest gap was in debugging questions. And finishing with AI wasn’t significantly faster.
At the Technical University of Munich, a trial with 275 students saw it from another angle: with AI they scored better on a 90-minute exercise, but didn’t learn more.
These are short studies, and they don’t predict a whole career. But they separate two questions a closed ticket mixes together: what could the person deliver, and what did they learn along the way?
#.What are we asking of juniors?
A company can ask someone to build judgment and, at the same time, make it very clear how costly it is to take longer. It can ask them to ask questions, without setting aside time to answer them.
In that environment, AI offers something very attractive: moving forward without showing what you don’t know yet.
That isn’t bad faith. It’s trying to meet what you understand is expected of you. The problem is when it becomes a habit, and practicing diagnosis always gets left for later.
#.Making room to understand
We learn from mistakes, yes. But only if the second half exists: someone who helps you see what failed and why.
I’d start with something concrete:
- Before looking for the solution, the person writes down what they think is happening and how they’d check it.
- If they use AI, they compare its proposal against that hypothesis.
- In the review, someone helps them understand why it worked, or which assumption failed.
It’s not a validated recipe. It takes time, and it depends on how risky the task is. Getting it wrong in a local environment is fine; losing customer data shouldn’t be anyone’s teaching exercise.
If we want engineers who can supervise increasingly automated systems, we’ll have to build that ability. Saying “I don’t understand this” has to open a conversation, not close an evaluation.
The student needs to deliver. So does the junior engineer. We can’t ask them to ignore the consequences of failing and then judge them as if those consequences didn’t exist.