Your brain remembers what it makes. It barely notices what it reads.
That's not a productivity quote. It's one of the most reliable findings in memory research, and it has a name: the generation effect. If you write code for a living, and lately you've been letting an assistant write a lot of it, it's worth knowing about.
Two psychologists, a list of words
In 1978, Norman Slamecka and Peter Graf at the University of Toronto ran a set of experiments that sound almost too simple to matter. Half the time, people read a word pair in full. The other half, they got the first word and a fragment of the second, and had to fill in the rest. Think "hot" and "c___", where you supply "cold".
Same words. Same time on the page. The only difference was who produced the answer.
People remembered the words they produced better. Every time. Across five experiments, on recognition tests, free recall, cued recall and even confidence ratings, the "generate" condition beat the "read" condition. The authors noted the effect showed up at high levels of reliability "even in experiments employing only 12 subjects." You can read the original paper here.
They also admitted they didn't fully know why. "It is concluded that the generation effect is real and that it poses an interesting interpretative problem."
Then the field checked their work
A single lab finding can be a fluke. This one wasn't.
In 2007, Sharon Bertsch, Michael McDaniel and colleagues pooled the research into a meta-analysis in Memory & Cognition: 86 studies, 445 effect sizes, more than 17,000 participants. The average benefit of generating over reading was about 0.40 standard deviations, or in their words, "almost half a standard deviation." That's a solid, ordinary-sized effect. Not magic. Not nothing.
A larger review in 2020, led by Matthew McCurdy at the University of Illinois Chicago, went through 310 experiments and found the effect held on every type of memory test they looked at. It also found something useful. The less constrained the generation, the bigger the payoff for recall. Filling in one obvious letter helps a little. Building the answer with more of your own thinking helps more.
There's one catch in the 2007 data that I find the most telling. When the material was nonsense, like made-up nonwords, the generation effect nearly vanished (an effect size of 0.05). Generating only helps when there's something already in your head to connect the new thing to. Your brain isn't rewarding effort for its own sake. It's rewarding you for wiring the new fact into what you already know.
Now swap "words" for "code"
Here's where it gets uncomfortable for developers.
Early this year, Anthropic published a randomized trial (full paper on arXiv) with 52 mostly junior engineers. All of them used Python weekly. None of them knew Trio, an async library. They built two small features with it, then took a quiz on the concepts they'd just used.
One group had an AI assistant in the sidebar that could produce correct code on request. The other group coded by hand.
The AI group averaged 50% on the quiz. The hand-coding group averaged 67%. The time saved by the AI group wasn't statistically significant. The biggest gap was on debugging questions, which is the exact skill you need when the generated code is wrong.
A field experiment in a Turkish high school, published in PNAS in 2025 by Hamsa Bastani and colleagues, found the same shape with nearly a thousand math students. A plain ChatGPT-style tutor boosted practice scores by 48%. When the AI was taken away for the exam, those students scored 17% lower than students who never had it. The researchers saw students using it as a "crutch," asking for answers and copying them.
Neither study is a generation-effect experiment in the strict sense. Different tasks, different tests. But they rhyme with it. When something else produces the answer, you end up in the "read" condition, even if your name is on the commit.
It's not "never use AI"
The Anthropic paper has the hopeful part. Using AI didn't automatically mean a low score. The people who did well asked follow-up questions, requested explanations, or asked conceptual questions while writing the code themselves. The ones who handed over the whole task got some speed and lost the learning.
Same in the PNAS study. A version of the tutor with guardrails, which nudged students toward working things out, mostly removed the harm.
So the tool isn't the problem. Who does the generating is.
Things you can try this week
You don't need a new system. You need small moments where your brain produces the answer before it sees one.
Guess the code first. Before you ask an assistant for a function, write the signature and a rough version, even a wrong one. Then compare. You've turned a read into a generate.
Retype, don't paste, the first time. When you're learning a new API, type the example from the docs by hand once. It's slower. That's the point.
Explain the diff in your own words. After accepting a suggestion, write one line in the commit message about why it works. Not what it does. Why.
Ask the AI to quiz you. Instead of "write this," try "give me a hint, not the answer." It's the guardrail version of the tutor, applied by you.
Close the tab and rebuild it. After reading a good explainer on, say, structured concurrency, close it and write three sentences from memory. Then check what you missed.
Every one of these is just the 1978 experiment again. A word with a gap, and you fill it in.
Where I've landed
I build a small app called Recl, mostly because I kept saving good explainers and never thinking about them again. It turns what you save, like a talk, an article or a thread, into a short summary and then brings it back later as a question you have to answer yourself. That "answer it yourself" part is the generation effect doing the work, not the summary. You can see some example saves in the public library.
But you can get most of the benefit with a notebook and a little discomfort. Next time an answer appears instantly, try making it first.
Your brain keeps what it builds.
I'm Asutosh. I write about how memory and learning work, and I build Recl, a tool for remembering what you watch and read.
Top comments (0)