The Accidental Education of Vibe Coding

People come to vibe coding to get out of learning how software works. That is the pitch, more or less: describe what you want, let the agent handle the parts you never wanted to understand, ship something that runs. The whole appeal is the skipped course.

What happens instead is the part nobody advertises. You set out to build a small tool and you back into an education. Not the structured kind, with a syllabus and a final, but the kind that arrives embedded in problems you actually had. You wanted a thing that worked. You got the thing, and on the way you learned why the thing kept not working, which turns out to be most of what software knowledge actually is.

The lesson is hidden inside the bug

Watch what happens when you ask an agent to pull data from some service and put it somewhere useful. It writes code that calls the service. The call fails. It reads the error, adjusts, calls again, and a few rounds later the data comes back, and you, standing behind it, have just watched the shape of a real system.

You learned that the service has a rate limit, because the agent hit it and had to back off. You learned that the data came back as something nested and awkward rather than the neat table you pictured, because the agent had to reach three levels down to find the field it wanted. And the thing that worked yesterday returns an error today, because a token expired and nobody told you tokens expire. None of this was explained to you. It was demonstrated, at the exact moment it mattered, against a problem you cared about because it was blocking the thing you were trying to make.

That is a better teacher than most courses, and it is better for a specific reason. A course gives you the concept first and the problem later, if at all, as an exercise. Building with an agent gives you the problem first and lets the concept arrive as the explanation for why you are stuck. Rate limiting stops being a chapter you skim and becomes the reason your script died at 4 p.m. on a Tuesday. You remember the ones that cost you an afternoon.

What you actually pick up

The list is longer than you would expect, and almost none of it is syntax.

You learn how data is shaped, and why the shape matters: that a list of records is a different thing from a single record, that an empty value and a zero are not the same, that the field you want is sometimes a string pretending to be a number. You learn what an API is by watching one refuse you, and how it fails, and that "it failed" is rarely the same as "it's broken." Secrets need handling, and that lesson usually arrives the first time you paste one somewhere you shouldn't and an agent gently moves it into a config file, explaining, in passing, why. "State" you learn by losing some. "Works on my machine" turns out to be a real sentence with a real cause.

In my own experiments the list got specific fast. I learned to host on Vercel, and to use git and GitHub properly rather than as a place files go to die. I picked up the shape of the modern web stack: Node underneath, React on top, a few of the UI frameworks that sit on those, and the browser dev console as the place you actually find out what broke. I learned what an ORM like Prisma is for, and that "the database" is usually a hosted service someone else keeps alive. I still could not build a modern web app from scratch on my own. But I can explain the moving parts now, and I talk to web and app developers as someone who knows what the pieces are and how they fail, which I could not do a year ago.

The understanding runs ahead of the ability, which is an odd state to be in and a productive one.

This is knowledge of how systems behave, and it is the genuinely useful kind. It is also, notably, knowledge you can hold without being able to produce it from scratch. You understand what a rate limit is and why it bit you long before you could write the code that respects one unprompted.

The diff is the textbook

The single habit that turns this from osmosis into education is reading what the agent changed.

You don't have to be able to write the change to learn from reading it. When the agent fixes the failing call, look at what it did differently. When it reshapes the data, watch where the field moved. The diff is a before and after of a working system, annotated by the act of repair. Reading a few hundred of them teaches you to read systems generally. It is the closest thing this practice has to a curriculum, and it costs nothing but attention.

I'd put it more strongly. If you do exactly one disciplined thing while building this way, make it reading the diff. Everything else you can let the agent carry. This one you cannot delegate without giving up the education entirely, because the education is in the reading.

The lopsided shape of this education

It is real, and it is lopsided. The lopsided part is where the trouble lives.

You learn the practical behaviour of things without the foundations underneath them. You will know that adding an index makes a slow query fast without knowing what a B-tree is or why it helps, that you should not trust user input without being able to enumerate the ways it can hurt you, and that the thing is slow without the vocabulary to say where the time went. Most of the time this is fine, and occasionally the gap bites, and it bites hardest in exactly the places where surface knowledge feels like enough: security, concurrency, anything involving money or other people's data.

The 2026 measurements are not reassuring. Veracode's spring update found close to half of AI-generated samples carried at least one known security flaw, a pass rate that has barely moved since 2023 even as the code grew more syntactically correct ^[R1]. The Cloud Security Alliance watched the fallout downstream: CVEs traced to AI-generated code climbed from six in January 2026 to thirty-five in March ^[R2]. The number matters less than what it implies for the self-taught builder: the failure modes you can't yet see are the ones the agent is most likely to introduce. The education gives you eyes for the bugs that announce themselves; it is slower to give you eyes for the ones that sit quietly until something external trips them. The vibe-coding platform Lovable, whose whole job is to make this easy, shipped an access-control hole that let any free account read other users' source and database credentials, and left it open for forty-eight days ^[R3]. If the toolmakers miss the quiet kind, the lone builder will too.

So the right posture is the one a good apprentice takes: build freely, and keep what you build well away from anything that matters until you understand it better than you currently do. The capability arrives before the judgement. Acting as if they arrived together is the mistake.

I changed my mind about the order

I used to think the order was fixed. You learn the fundamentals first, the data structures and the protocols and the way memory works, and then you apply them. Theory, then practice. Practice without theory was how you got people who could copy a snippet but fell apart the moment the snippet didn't fit, and I'd seen enough of that to be confident the foundations had to come first.

Watching people learn this backwards has made me less sure. They start with a working thing and absorb the theory afterward, or never, picking up exactly as much as the next problem demands and no more. It is not how I learned and it offends a tidy part of me that wanted the sequence to mean something. But the people doing it are shipping useful tools and, more to the point, they understand those tools, in the practical sense that matters when something breaks. The foundations they're missing are real, and some of them will eventually need filling. The order I was sure about turns out to be one order, not the only one.

Not only for beginners

When Karpathy named "vibe coding" in 2025, the word wore its hobbyism openly: describe what you want, accept what comes back, forget the code is even there. A year later, almost to the day, he retired his own coinage for "agentic engineering", because programming through agents had quietly become a default workflow for professionals, run with more oversight and scrutiny. The "engineering" was there to mark that it takes real skill you can build ^[R5]. The numbers tell the same story: by early 2026 AI was writing more than 40% of committed code, even as most developers admitted they didn't fully trust it and didn't always check it before it shipped ^[R4]. The term Collins had just made its word of the year was already being renamed by the person who invented it ^[R6]. The practice grew up and went to work.

What surprised me is that the education came with it. I'm a developer. I can read the diff because I've read diffs for twenty years, which means my "without being a Python developer" carries instrumentation a true beginner lacks: when an agent hands me something subtly wrong, I have a decent chance of catching it. Someone flying with less has less to catch it with, and should build accordingly.

And building this way still taught me things about my own habits. It made the cost of my assumptions visible: the agent would cheerfully implement the lazy version of an idea I'd never have written out longhand, and seeing it on the page was clarifying. It taught me about systems I thought I knew, by coming at them from the angle a model trained on everyone's code reaches for by default. That verification gap the surveys describe is the lesson from the other side: the people who get better are the ones who read what came back, the twenty-year veteran no less than the first-week beginner. The education isn't a beginner's consolation prize.

The side door

The strongest argument for a non-programmer to build with an agent isn't the tools they'll end up with. The tools are real and often useful, but they're not the prize. The prize is the understanding that arrives without being studied for: how data moves, how systems fail, why the thing worked yesterday and not today.

People walk through that side door looking for a shortcut around learning how computers work, and come out the far side having learned a fair amount about how computers work, sideways, while they believed they were doing something else. It is a lopsided education, and an unplanned one, and a surprising number of people are getting it without ever meaning to enrol.

_{The Accidental Education of Vibe Coding · July 2026 · A field note and an opinion. The read on practice-first learning, and the change of mind about it, are my own; the security and adoption figures, and Karpathy's renaming, are from the cited sources.}