I’m trying not to trigger anyone, but let’s talk about a vibe coding method that’s grounded in experience from the world of production enterprise software—and yes, I can already feel the piercing looks from the technical purists 😁
The conversation around AI-assisted coding is stuck between two extremes. On one side, you have tech-bros on X claiming they’re firing entire dev teams. On the other, you have technical purists calling it “dumb hype” because if an AI isn’t 100% correct, it’s useless. As always, the reality is somewhere in the middle. AI is already changing the coding world, but the “how” is still up for debate.
I’ve been in the AI coding trenches for a while now, watching it evolve from the beginning. That’s given me a chance to try everything I can get my hands on: simple autocomplete, vibe coding, PRD-based generation, you name it. This blog series is where I’ll share what I’ve learned. First up: a look at what I call “semi-vibe coding.”
It’s almost vibe coding because you don’t do a ton of upfront work to guide the AI. But it’s semi because you take absolute responsibility for the outcome, staying in control of the final codebase through rigorous review.
The process starts with one non-negotiable rule: the AI agent never gets permission to commit to git. All commits are done by you, as the operator. This is the safety net that makes the whole thing work.
The Prompt, The Process, and The Payoff
It all starts with the prompt. Be as clear and specific as you can. Think of it as giving the AI just enough context to succeed—concise but descriptive, outlining the goal without getting lost in implementation details.
Once the prompt is ready, let the AI generate a complete chunk of functionality. This could be an initial project setup, a new feature, or a complex refactoring. When it’s done, you evaluate the output. If it’s not good, don’t try to fix it. The most efficient move is to dismiss the changes, refine your prompt, and start over.
Tip: If the AI is struggling, give it a nudge. Point it to a specific file, a function, or a nuance you’re after. This “fail fast, restart faster” loop is a superpower.
If the AI seems to be in an endless and hopeless loop of not producing any valuable outcome—and it does happen sometimes—it’s a good idea to try a different model. Some models tend to work better in some scenarios than others. I currently find myself jumping between models like Claude Sonnet 4, Google Gemini 2.5 Pro, and now sometimes GPT-5. And occasionally, I try to add more exotic models, like Kimi K2, to the mix, just to see what happens. A fresh perspective from a different AI can often break the deadlock.
Repeat this cycle until the result is nearly perfect. Then, you step in to handle the final 5-10%—the polish and fine-tuning. Test it immediately, and only when you’re confident it’s right, commit the code and move on.
You Still Own the Code
This process only works if you maintain complete awareness of your codebase. You have to know every change that goes in and be ready to discard large chunks of work in a heartbeat. It’s normal to redo a task a few times to get it right.
Most importantly, you own the outcome. If you get lazy with code reviews or slack on your prompts, things will go sideways, and it’s on you.
To be clear, I’m not saying this is the future of coding. It’s just one of the many ways to leverage AI. I do, however, keep preaching that every single developer needs to start coding with AI to stay relevant. Why? Precisely because there are so many ways to do it, and none of them are perfect yet. The landscape is constantly evolving, and you need to be a part of that evolution.
