Navigating Vibe Coding Safely

Andrej Karpathy coined the term "vibe coding" where you describe what you want in plain language, the model writes the code, and you keep going until it feels right. For experiments and quick prototypes, it's fast and maybe a little addictive. For anything that has to run in production, it creates a whole different set of problems. You end up responsible for code you didn't write and may not fully understand.

The Real Risk

The danger isn't that the code won't work. It's that you won't know why it works, or where it breaks.

When something goes wrong at 2 a.m., you need to know where to look. When a security issue appears, you need to know what the model actually did. When the system needs to scale, you need to know which parts were built on assumptions that no longer hold. If you can't explain the code, you can't do any of that.

This is the part that gets glossed over. The speed feels like progress. The output looks complete. But the understanding that used to come from writing the code yourself doesn't appear by magic just because you prompted for it.

Who This Actually Affects

Not every developer faces the same risk.

Someone early in their career who uses AI to generate code they then study and rework is still building intuition. The tool is doing what a good mentor or pair programmer would do, showing possibilities and forcing questions. That's different from someone shipping production systems they treat as black boxes.

The gap matters most for people who already have experience but have blind spots. A backend engineer might miss frontend security issues. A frontend specialist might generate inefficient queries without realizing it. Experience in one area doesn't protect you from mistakes in another. The model doesn't fill those gaps. It just makes them harder to see.

What "Staying in Control" Actually Looks Like

The difference between using these tools well and using them recklessly comes down to a simple test: can you explain what the code does and why it does it that way?

If the answer is no, the work isn't done. You keep asking until the explanation makes sense. You don't ship what you can't defend.

That doesn't mean writing everything by hand. It means the model proposes, and you verify. It means you define the hard parts, the data shapes, the security boundaries, the performance constraints, before you ask for code. It means you treat the output as a first draft from a very fast junior developer who needs review, not as finished work.

The developers who will actually benefit from this moment are the ones who treat understanding as non-negotiable. The ones who use the speed to explore more, not to skip the part where they figure out what they're building.

Building Barrios AI in Public

I'm building Barrios AI this way. The platform combines curated knowledge, chat interfaces that actually know the material, and workflows that don't fall apart when something changes. I'm using the same tools everyone else has access to, Cursor, Claude, Grok, LangChain, and I'm documenting every step.

The prompts that worked. The changes I had to make. I show the problems the model introduced and how I caught them before they reached production. I'm doing this in public because the only way to know if this approach holds up is to actually use it on real systems with real stakes.

Even with decades of experience building and teaching these systems, I don't skip the review step. The model is fast. That doesn't make it trustworthy on its own.

The Real Choice

Vibe coding changes how fast you can move. It doesn't change what it takes to own a system.

You can generate code without understanding it. You can ship it. For a while, it might even work. But eventually something will break, or need to change, or expose a vulnerability you didn't know was there. At that point, the speed you gained becomes the cost you pay.

The developers who come out ahead are the ones who use these tools to go further, not the ones who use them to avoid the work of knowing what they're shipping.

I'm building Barrios AI this way and showing the process as I go. If you're working through the same tension, wanting the speed without giving up control, follow along at @barrios_ai.

Follow the work at barrios.ai and @barrios_ai.