Vibe Coding Is No Joke. It Actually Works.

Editor’s note, August 2026: I originally published this on LinkedIn on April 29, 2025, when “vibe coding” was still a new term. I have adapted the formatting for the site and transcribed the accompanying 15-rule graphic into accessible text, but left the argument and advice in their original moment. For my current view, read Vibe Coding, One Year Later: Agentic Workflows and Engineered Loops.

I’ve been vibe coding for three months now, and it’s not a joke. It actually works.

Are you a technical founder struggling to build your MVP quickly? Vibe coding might be your answer.

What I have learned

It is a strong fit for technical founders who need to move fast.
It has accelerated development by three to five times in my own experience.
It removes the blank-page problem almost completely.

That speed changes the early stages of building. Instead of spending days creating enough structure to test an idea, I can get to something concrete much sooner. I have code to run, behavior to react to, and a clearer sense of whether the idea is worth pursuing.

But let’s be real.

You still need to be a software engineer

Getting a non-trivial SaaS product finished still requires technical judgment:

You need to articulate requirements using real software-engineering concepts.
Getting security right requires technical knowledge.
Understanding fundamental software-architecture principles remains essential.

The model can produce a lot of code very quickly. Someone still has to know what the system should do, recognize when the implementation is heading in the wrong direction, and take responsibility for the result.

The 15 rules of vibe coding

This checklist had been circulating on social media and was enough to help someone get started with the tools available in early 2025.

Start from a template. Begin by cloning a suitable template from GitHub or another trusted source so the project starts with a solid foundation.
Use agent mode. In Cursor, use Agent mode rather than the standard chat mode so the agent can create, edit, and manage files through natural-language instructions.
Use Perplexity for research. Look up current designs, APIs, and examples before asking the coding agent to implement an unfamiliar feature.
Create a new Composer chat for each distinct task. Keep each agent conversation focused and relatively short.
Run locally and test frequently. Use the built-in development server and exercise the application often so issues appear early.
Iterate and refine. Do not worry about a perfect design on the first pass. Improve it step by step.
Use voice-to-text. Tools such as Wispr Flow can make it faster to give the agent detailed instructions.
Clone and fork wisely. Reuse repositories for acceleration or inspiration, then adapt them to the product you actually want to build.
Give errors back to the agent. When something fails, copy the console output into Composer. If the first fix does not work, add more context and explain the problem more precisely.
Preserve a recoverable state. Save your work frequently so you can return to an earlier point when an experiment goes wrong.
Secure your secrets. Keep API keys and sensitive values in environment files rather than hard-coding them into the application.
Commit often. Push progress to GitHub regularly so changes are tracked and the work is protected. The agent can help with this too.
Deploy early. Use a platform such as Vercel to test deployment before the project grows large enough to hide integration problems.
Record and reuse effective prompts. Keep the instructions that produce good results so future development and debugging become easier.
Enjoy the process, just vibe. Experiment, learn, and have fun with the creative part of building.

At the time, these rules captured the workflow pretty well: give the model a good starting point, work in small steps, test what it produces, and make sure you can recover when an experiment fails.

The tools will change quickly. The useful part is learning how to turn an idea into working software without surrendering the engineering judgment needed to finish it.

Results may vary. But the vibes are consistently good.