What is vibe coding? Should we all be vibe coding? And how can we do it right?

Coding with AI is moving at a fast pace thanks to great tools like Cursor, Highlight and other tools.

The Cursor team have been working super hard on pushing lots of updates to their IDE and it's made the possibility of vibe coding much easier for everyone to try.

What is Vibe Coding?

Coined by OpenAI co-founder Andrej Karpathy in February 2025, Vibe coding is an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a AI chatbot or tool like Cursor and the AI generates all the code, shifting the human's role from manual coding to guiding the AI to generated source code, often without understanding what is being written.

This relates back to Karpathy's 2023 statement that "the new hottest programming language is English".

Why vibe coding is cool

Vibe Coding allows anyone to produce applications without having to think about the complexities of code. They can reel off an idea to an AI and then iterate on that idea without having to write any lines of code. And the results can be pretty impressive.

Why doesn't everyone just vibe code then?

For a non-engineer, vibe coding is a great gateway to getting started with code. It's really easy to get something going and make quick progress.

For an engineer, however the situation is slightly different.

Non-engineers see vibe coding and then struggle to understand why engineers are still taking time to write code manually.

There are a few reasons for this:

1. It's far easier to write code than it is to read code

When developers write code, they try to follow best practices for keeping code clean and maintainable through consistent naming, DRY principles and architected modular design. Writing readable code is a very hard thing to do - and even when coding manually developers often don't get it exactly right.

Vibe coding is a bit like having a junior developer on your team - they do exactly what you ask for without thinking about the bigger picture; or even if they should do it; and they have a habit of going off track and making other changes too.

2. The 80:20 rule

If you rely solely on vibe coding without establishing proper guardrails first (which may happen if you don't understand what guardrails are needed), you'll inevitably encounter problems as your application grows in complexity.

This situation illustrates the 80:20 rule of software development - where the final 20% of a project often requires the most time and effort to complete properly. With vibe coding, the challenge is compounded because you lack familiarity with the initial 80% of the codebase that was AI-generated.

As you approach the final stages of product development and begin refining your concept, issues are more likely to emerge. At this point, the vibe code engineer often finds themselves stuck.

For non-engineers, resolving these issues becomes nearly impossible because they don't understand the underlying code structure or problems. Even for experienced engineers who can read code, they're confronted with a disorganized collection of code that doesn't follow best practices, resulting in significantly longer debugging sessions.

3. What about security?

When vibe coding, you might overlook critical security considerations that professional developers would routinely implement. Essential security practices such as:

• Ensuring user inputs are safe
• Passwords are not stored in plain text
• API and Database keys are stored securely
• APIs are rate limited
• Permissions are set up correctly
• Errors are handled carefully

Not considering these security issues at all leads to issues like the ones we are seeing in the AI community now.

So what can we do?

Engineers naturally approach AI code generation with caution. Beyond concerns about being undervalued or replaced, they prioritize keeping code readable and maintainable over time. While Cursor's MDC files can help address some of these concerns, you still need technical expertise to use them effectively.

Fortunately, this isn't an all-or-nothing proposition. Many routine tasks can be automated while engineers maintain control over the codebase structure. Time-consuming but low-value tasks like test maintenance and linting fixes can be efficiently handled using Cursor's YOLO mode, freeing up valuable time for more strategic coding work. I explore these automation opportunities in more depth in my Cursor tips and tricks article.

For non-engineers excited about vibe coding, keep the 80:20 rule in mind: what seems easier at the beginning often becomes significantly more challenging later in the development process.

Tips for better Vibe Coding

From my experience, the best use case for vibe coding is to test the vibe of an idea. As per Pieter Levels (https://x.com/levelsio) recommendation - creating a prototype in 3 hours to see if the idea is even feasible is a great use case for vibe coding. It produces a lot of thought about the use cases of the idea and information about how it would work.

Here's some tips for being better at vibe coding:

1. Use AI to first make a PRD (Product Requirements Document) before writing code. Include the PRD file in your codebase. Grok, o1 Pro or GPT 4.5 are particularly good at creating these.
2. Be less specific. Vibe coding is about getting things "almost right" and accepting compromises. AI has a habit of getting stuck in the most unusual situations.
3. Vibe coding frequently won't go right. So start over when things go wrong. Learn lessons with each iteration on what did and didn't work with your prompts until you get something good. Cursor also has a handy 'revert' feature that allows you to step back through code changes.
4. Utilise TDD to get the AI to test it's own code, and ask it when you want it to break code up in to smaller pieces.

As of March 2025, for production code of complex applications however, you're probably best keeping it in the safe hands of your engineers.

As I wrote at the top of the article, coding in AI is moving fast - so let's see how long it takes for that to change.