Software engineering has traditionally assumed a high cost of knowledge and a long process of understanding.
The traditional educational model has worked well enough: there are experts and instructors who help students understand complex topics that instructors are uniquely qualified to teach.
Want to learn to code? Most people won't make it through Learning Python on their own, better take a course.1
This is because there have always been a large number of primitives that served as prerequisites to any project.
To build a Hello World app, you need to know about syntax, variables, and functions. You actually need to know Python. Anything more complex and you need to know about virtual environments and dependency management.
Want a database? Time to install Postgres on your laptop. You need to know about SQL, and how to use a terminal.
This is how it's always been. The internet made things easier, but it was still a slow process to put in the work and understand the concepts.
But two parallel forces are disrupting the traditional education model:
- A falling cost and latency to learning
- Rapidly improving devtools
On-demand learning
The internet brought the cost and latency of learning down, but understanding still took time. You had to find, vet, and reconcile conflicting answers. Stack Overflow helped by surfacing exact fixes.
Now, AI makes learning near-instant and free. With high-quality OSS models, the marginal cost per token is effectively zero.

GPT model costs are falling while models continue to improve.
Moreover, you can get an answer tailored to your exact question and learning style.
At a broad level, you can just do things.
It's possible for a reasonably clever person to ship a web app in a few hours with vibe coding, serverless tools, and modern scaffolding.
No CS degree, no fundamentals, just logic & agency.
What I'm seeing is that if you ask some of these new learners about how things work they have no clue, which doomers will tell you is totally bad, evil, and the end of software engineering as we know it.
But I'm here to say it's totally fine. They're learning.
I'm not going to poke fun of someone at the gym, even if they're doing the silliest thing I've ever seen. Maybe it's their first day. Maybe they just got on the path. Maybe this is a new evidence-based approach and I'm wrong (unlikely).
Maybe they're trying to get a bit better every day, like me.
There's a human inclination to talk down to those who are early in their journey.
Some engineers valorize deep systems knowledge and dismiss newer workflows outright.
That attitude often extends to vibe coders.
What's the goal?
The goal of engineering is not to know more fun facts about TypeScript.
The goal of engineering is to build amazing things that improve lives.
Learning is now on-demand. I don't need to know Python to build a Hello World app. I can build the app, then understand how it works.
I don't need to know DevOps to have a serverless production database. I can connect it to my app and learn along the way.
Vibe coding, ephemeral chats, and curiosity can get you very far with today's tools. Arguably too far.
The problem is that many new learners do not understand the difference between a toy and a project.
I might spend a morning spinning up a prototype to validate an idea. I have no idea how the code works and I guarantee it's the most hideous thing I've ever seen.
But I recognize that.
I recognize that if I want to use this thing, I'll need to tear it apart, understand it, then rebuild it from scratch.
Yes, rebuild it with AI, but rebuild it file by file.
The divide between building irresponsibly and responsibly is understanding. Exploration without deep understanding is fine; shipping to users is not.
Many new learners are so amazed that they created something that actually works... that they'll run with it.
They'll run with it even if they don't understand it.
And that's because creation has been gated for so long.
The same was true of the first photos on Instagram—creating digital images was limited to professional photographers, so when people realized they could create, they ran with it.
The result was millions of blurry, horribly filtered images.
Now, a dozen years later, new content creators are being born because of a different type of democratization:
Personal software.
And my prediction is that we'll see the same thing, albeit on a compressed timeline, that we did with media.
But putting your name on something you don't understand is a dangerous game, one that doesn't apply to photos, but does apply to executable code.
The contract
If I gave you a contract and you skimmed the first paragraph and made some edits, would you sign your name?
Software is a contract.
Creating is a contract.
When I create something, I'm putting my name on it, just like I'm putting my name on this post. And if you have integrity, you'll only do that if you care deeply about what you're creating.
Now, it seems increasingly likely that a future exists where none of this matters—someday we'll be able to build whatever, whenever and not worry about code. That is not today.
On-demand learning for data security doesn't really work if my app is already live and storing user data.
Learning that lesson the hard way not only hurts me, but all the users of my app.
Creating software is something special... and a bit scary. Code is not like a meme or an Instagram Reel.
Our contract
As "vibe coders," we're building the future. We're building the future of work. We're building the future of learning.
We need to understand when we don't understand.
It's ok to not understand! It's actually important to not understand, because recognizing is the first step to understanding.
But there comes a time (we all know that time) when you need to sit down and do the hard work.
AI can tempt us to hand-wave and bullshit over the parts we don't get.
The contract we have to make with ourselves is that we will not put our name on something we don't understand.
The contract is not about being "above" anyone.
It's about being a professional. Professionals deliver excellent work. Professionals do not compromise on user safety, data security, or truthful representation of competence.
And if you want to make the claim that you're building a $50k MRR SaaS or that you're writing 10k lines of code everyday, you are claiming to be a professional.
My challenge is to act like it.
The contract I'm willing to make is that I will do everything in my power to make understanding these concepts as simple, relatable, and straightforward as possible.
But we (vibe coders) have to make a similar contract with ourselves—to be professionals.
Where next?
I'm not saying everyone needs to be an expert (I am not one).
I'm not saying we should stifle new learners. I'm not saying we should be pessimistic.
We are barreling toward a future where we can build anything, anytime and we are not in control of where that future leads.2
Me yapping on this blog isn't going to stop a vibe coder from leaking their API keys.
But we can do everything in our power to make sure that we're building the future in a way that is safe, secure, and responsible. I believe that happens through education and understanding.
We need to continue encouraging understanding.
Last week, I wrote a post on building agents and I was a bit embarrassed. It took a LONG time to shake off the rust... almost everything I've built in the past few months has been vibe coded.
But it continues to be useful as I formulate ways to educate and improve.
And so I have two asks:
- If you're already a software engineer, don't feel threatened by new learners. They have access to the same tools you do, but much less nuance and pattern mapping. Try to help them understand, learn, and grow.
- If you're a new learner, ABSOLUTELY use every tool at your disposal, but start from the premise of improving your craft and growing. That means being a professional, that means putting in the work, and that means understanding. If you vibe code something quickly, anyone with taste can spot it from a mile away.
I'm incredibly excited to see where the future leads. Now is truly the greatest time in human history to be a builder (and a learner).
