About a month ago, Andrej Karpathy gave a name to something many of us were already doing. He called it vibe coding. You describe what you want to the AI, you accept what it gives you, you do not really read the code, and when something breaks you just paste the error back and ask it to fix it. You surf on vibes. The code is almost a side effect.
The internet split immediately into two camps. One camp says this is the future and traditional programming is dead. The other camp says this is the end of software quality and we are all doomed. As usual, I think both camps are selling something. Let me try to write the boring middle position, because the boring middle is where I actually work.
Where vibe coding is genuinely great
Last weekend I vibe coded a small tool for myself. A script that reads my bank export and categorizes spending the way I like. I did not read most of the code. I described, I ran, I corrected, I ran again. Forty minutes, done. Writing it by hand would have taken me a few evenings, and honestly I would never have started.
This is the real gift. Vibe coding collapses the cost of trying ideas. And that has a direct business meaning. Prototypes used to be expensive, so companies argued for weeks about whether an idea was worth building. Now you can build the throwaway version in an afternoon and argue about something real. Cheap experiments mean more experiments, and more experiments mean you find the good ideas faster. In my company years in Brazil, we lost clients because mocking up an idea took two weeks. Today that same mockup is one afternoon of vibes. I would have killed for this.
Vibe coding is also a great learning tool. Want to feel how a new framework works? Vibe a small app in it. You get a working artifact to poke at, which teaches faster than reading docs. The artifact is disposable. The understanding is not.
Where it becomes dangerous
The problem starts when the prototype does not get thrown away. Everyone who has worked in this industry for more than five years knows the pattern. The demo impresses someone, the someone says ship it, and the throwaway code becomes load bearing. I once had a client who, right after a sales meeting where we showed a demo, turned to us and said just change the logo, this is exactly what we need. That demo was held together with tape and hope, but to them it looked like a finished product. This pattern existed long before AI. Vibe coding just industrializes it.
Here is the core issue, said plainly. Vibe coding means nobody understands the code. Not the AI, which has no memory of why, and not you, who did not read it. In a prototype, that is fine. In production, understanding is the product. When the incident happens at 2 a.m., when the security audit comes, when a customer hits the edge case, somebody has to understand the system. If nobody does, you do not have a software asset. You have a liability that happens to run.
And the failures are not theoretical. Code that nobody reviewed will contain things nobody would have approved. Secrets in plain text. Input that is never validated. SQL built by string concatenation. Dependencies pulled in without a look at what they are. A human writing carelessly makes these mistakes sometimes. A model generating fast makes them at scale, with full confidence, in code that looks clean enough that nobody checks. This is the same trap I wrote about in AI code, where the bug wears a nice suit, just with the review step skipped entirely.
I really hope the future proves me wrong here. I hope we do not see a wave of leaked data, exposed passwords, and embarrassed companies because of code that nobody ever read. But I have been in this industry too long to believe that. It is going to happen. The only question is how often, and how bad.
The professionalism line
Many experienced developers, Robert Martin and plenty of others, have spent years hammering one idea, that programmers are professionals, and a professional does not ship work they cannot stand behind. You can disagree with them about many details, I do too sometimes, but that core idea is the right lens here.
A structural engineer can use software to calculate a beam. They cannot say the software did it when the beam fails. The signature on the drawing is theirs. I think we are arriving at the same place. Use the AI for everything, fine. But if you ship it, you own it. The vibe is not a legal entity. You are.
So my personal rule is simple, and it is about the destination of the code, not the source of it. If the code is disposable, vibe freely, enjoy, this is the best toy our industry ever got. If the code will touch production, real users, or real money, then every line gets read by a human who can explain it. Generated or handwritten makes no difference. Review is the gate, understanding is the standard.
The economics underneath
Let me close with the money view, because the money view makes this whole debate less emotional.
Vibe coding optimizes the cost of writing code, which was already the cheap part. The expensive parts of software were always elsewhere. Maintenance, debugging, security incidents, the slow drag of a codebase nobody understands. Vibe coding in production lowers the cheap cost and raises the expensive ones. That trade is bad almost by definition.
But vibe coding for prototypes lowers the cost of learning what to build, which is the most expensive question in all of software. That trade is wonderful.
Same technique, opposite outcomes, and the only variable is whether you treated the output as a draft or as a product. Karpathy named a fun thing, and it really is fun. Just remember that fun things and load bearing things have different rules. They always did.
Pax et bonum.