Can you actually learn while vibe coding?

Andrej Karpathy coined “vibe coding” in a February 2025 post as a way of building where you give in to the vibes, let the model write everything, and, in his phrase, “forget that the code even exists.” Read that definition closely and the answer to whether you can learn from it is already contained in it. The defining move of pure vibe coding is not reading the code the model wrote. There is no step where anything gets encoded in your head, because the whole point is to not look.

Here is the whole answer up front. Yes, you can learn while building this way, but only by deliberately doing the one thing the definition tells you to skip: look at the code. The learning is not a side effect of vibe coding; it is what you add on top of it. Three cheap moves do almost all of the work, and they cost you minutes: read the diff before you accept it, ask the model to explain what it wrote, and rebuild a small piece from memory. Everything below is why those three, and why the feeling that you already understood it is the thing you cannot trust.

The definitional trap

Most arguments about whether AI “helps or hurts” learning are stuck because they treat vibe coding as one thing. It is not. There are two activities wearing one name, and they sit on opposite sides of a line that Simon Willison drew cleanly.

Willison’s March 2025 essay defines vibe coding narrowly: building software with an LLM without reviewing the code it writes. Cross that line, review what it wrote, test it, make sure you could explain it to another person, and you are no longer vibe coding at all. You are doing ordinary software development with an AI assistant. His golden rule is the whole primer in one sentence: he will not commit code to his repository that he could not explain to somebody else.

So the question “can you learn while vibe coding?” is really a question about which side of that line you spend your time on. Pure vibe coding, by definition, has no learning step in it. The moment you add one, you have stopped pure vibe coding and started the thing that builds skill. That is not a criticism of vibe coding. It is a map of where the learning actually happens, so you can choose to be there on purpose.

Why “it felt like I understood it” cannot be trusted

The obvious objection is that you do read the code, sort of, as it scrolls by, and it makes sense at the time. That feeling is exactly the instrument you should not rely on, and there is a pointed result about why.

METR, an independent research organization, ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they maintain. The headline is well known: with AI tools allowed, they were 19% slower. The part that matters for learning is the perception gap. Before the study these developers expected AI to speed them up by 24%. Afterward, having actually been slowed down, they still believed AI had sped them up by 20%. Their felt sense of their own performance was inverted from the measured reality, and the gap did not close even after the fact.

Carry that into learning. If a skilled developer’s sense of “this made me faster” can be flatly wrong, your sense of “I understood that diff” is on the same unreliable footing. Understanding, like speed, needs an external check rather than a feeling. Which is the entire case for the three moves below: each one replaces “I think I got it” with something you can actually observe. This is the same perception-versus-reality gap our study on whether AI makes you faster is built around.

What the brain-science headlines do and do not say

You may have seen a study going around as proof that AI “rots your brain.” It is worth handling carefully, because it is real, it is interesting, and it is not about coding.

The paper is “Your Brain on ChatGPT,” a 2025 preprint. Two caveats have to travel with it every time it is cited: it is not peer reviewed, and its 54 participants were writing essays, not code, while researchers measured EEG connectivity and recall. The finding, that the group using an LLM showed weaker neural connectivity and had more trouble quoting work they had just produced, is genuinely suggestive about what happens when you offload a cognitive task wholesale. It is adjacent evidence, not a verdict on programmers, and anyone citing it as “science proves vibe coding makes you dumber” has stretched an essay-writing preprint past what it can hold. What it fairly supports is narrower and still useful: when you fully hand off the thinking, less of it stays with you. That is a reason to keep a hand on the work, not a diagnosis.

The three moves that turn vibe coding into learning

None of these is preachy and none takes long. They are the cheapest possible conversions of a delegated diff into something you actually know.

1. Read the diff before you accept it. Not after, not later. The instant before you approve a change is the one moment you have the most context and the most motivation to understand it. Read what changed and why, and refuse to accept anything you cannot follow. This single habit is the entire difference between Willison’s two sides of the line.
2. Ask the model to explain what it wrote. You have the best available tutor sitting right there. Ask it why it chose this approach, what the tricky line does, what breaks if you remove it. This is the one place where the AI genuinely accelerates learning rather than replacing it, because it turns an opaque block into a walkable explanation, on demand.
3. Rebuild a small piece from memory. The strongest test of understanding is production, not recognition. Close the file and rewrite one function, or one component, from memory. Where you stall is precisely what you did not actually understand, and the stall is the lesson. Recognition feels like knowing; reconstruction proves it.

Doing all three on every change would be exhausting and unnecessary. Doing them on the parts that matter, the auth check, the payment path, the piece you will have to modify next week, is where a vibe-coded project quietly turns into an education. The place to run these moves inside a real workflow is exactly what our Claude Code guide walks through.

When not to bother

The fair close is that sometimes the right amount to learn is nothing, and pure vibe coding is the correct tool.

Willison, who drew the strict definition, is also enthusiastic about vibe coding for the right job: a low-stakes throwaway, a weekend toy, a one-off script you will run once and delete. For those, forgetting the code exists is a feature, not a risk, because there is nothing to maintain and nothing to secure. Reach for the three moves when the code will live: when it goes to production, handles other people’s data, or you will have to change it later. The skill worth having is not “always read everything” or “never read anything.” It is knowing which project you are on, and choosing your side of the line deliberately instead of by accident. Learn on the code that matters, and let the throwaway stay a throwaway.