Mastering Vibe Coding: 5 Essential Skills for Building with AI
Today, this article will explore five key skills in vibe coding. These follow largely from the same techniques used when building applications. The concepts will be broken down to help you understand the approach to thinking about and building apps. This is going to be a mostly theoretical article; we're not going to write any code or build anything. However, the concepts are universally applicable to building just about anything with AI, making them super useful.
Specifically, this article is for vibe coders who are trying to up their game. If you're seeking to improve your building process or thinking, this article is for you. Let's jump right into it.
1. The Art of Thinking
The first skill is thinking. The foundation of thought is logical and analytical thinking. We can define this as doing something like playing chess or even learning how the pieces on a chessboard work.
While it's good to think logically, there are a couple of higher orders of thought that are more complicated. A great example is computational thinking. For instance, programming a computer to enforce the rules of chess requires understanding both how to program a computer and the foundational rules of chess. You have to grasp the scope and problem space of the game.
One order above that is procedural thinking. How do you excel at the game of chess? How do you program a computer to play chess competitively? Now, you not only need to understand how to manipulate language to program a computer, but you also have to understand how to be a top-tier chess player.
Tying this back to vibe coding, when you're building an application—whether complex or simple, like a tip-splitting app—you must understand all the edge cases and the product itself. What makes a good tip-splitting application? What creates a great user experience for sharing with friends? What will people actually engage with?
Procedural thinking in building with AI is like being your own product manager. You have to break down all the requirements and functionality of the application and then implement it. You are both the product manager and the engineer, which requires high levels of thought and a core understanding of what you're trying to build.
2. Leveraging Frameworks
One thing that ties into this is frameworks. A common saying is, "You don't know what you don't know." If you're trying to build an app with a drag-and-drop interface and you ask an AI for help, you could get stuck in a loop for days or weeks trying to build it from scratch. Meanwhile, numerous React frameworks already provide that exact tool. Someone has already done the hard work of building an open-source package you can use. The same applies to animating motion or using components.
The question you have to ask yourself is: "How do I do the thing I want to do?" What frameworks allow for that? What frameworks work best with LLMs? A key point about LLMs is their training cutoff, so newer frameworks might not work well without additional context.
The amazing thing is that if you don't know, you can just ask the LLM. For example:
"I'm trying to understand security best practices for my application. What are some ways of doing that in JavaScript with Express? What framework should I use for my front and back end? How would I implement these best practices? Tell me everything I need to do."
There comes a point where you realize you can get better advice by doing research, and now, you can do even better research by first asking LLMs to understand the problem space and then following up. Frameworks, languages, and tools are like puzzle pieces. You have to think about what you're building and consider all the available puzzle pieces at your disposal that you can connect to create the final product. This might require more than just a prompt; it might require sitting down to think procedurally and understand the problem to arrive at a solution.
3. The Importance of Checkpoints and Versions
The next concept is checkpoints and versions. A simpler way to think about this is to "build in chunks" or "build in steps." Things break—that's a fact, especially with AI. You should always be using version control to minimize issues.
We can tie version control into our building process by chunking builds into checkpoints, versions, or short sprints. You can say, "I want to build this feature. If it works, I'll check it in and move on. If it doesn't, I'll go back to the last checkpoint and try again." If you're stuck, you can prompt the AI repeatedly to see if it can be fixed. If that fails, revert to the checkpoint and try a different approach.
This is a fundamental concept. Many people report getting stuck in a "doom loop," sending the AI the same message over and over. If you're ever sending an AI the exact same message, it's like telling someone to do something they aren't doing and just repeating yourself—it's not going to fix the problem. So, using checkpoints, rolling things back, and trying new approaches is crucial.
4. The Skill of Debugging
From there, debugging emerges as a huge skill. Many of these might seem like fundamental software engineering skills, but if you're new to building, they might not be obvious. Debugging can seem boring—you're not implementing a new feature, just figuring out why something is broken.
But we can make anything fun. The goal is to make building enjoyable. The best debugging is methodical and thorough. You can turn it into a little game or problem. For example, if a lamp doesn't work, you would walk through steps to break down all the possible reasons why it might be broken and then test each one by one.
Let's make this more practical. Say you're building with AI and you hit an error. The debugging process involves asking: - Why am I getting this error? - Where can I look for clues about the cause of the error?
The goal is to understand how your app works, locate the error, get to the root cause, and then pass that information to the LLM to ask what's wrong.
5. Providing the Right Context
How do you pass that information to the LLM? That's where context comes in. You've likely heard the term "context window," which is the amount of tokens an LLM can process at a given time. It's like memory. If you give someone a long list of tasks, they'll eventually start forgetting.
Context can be the prompt we provide to the LLM, but it can also be a host of other things since LLMs are multimodal and can accept various media types like images, documentation, errors, or details about your application. As mentioned, because LLMs might have outdated training data, we must provide additional context.
The key thing to mention here is that it's not just important what you give the LLM, but also what you don't give it. Think about it like working with a baker. You're trying to get a cake for a significant other, and the baker asks what they like. If you only talk about yourself—your hobbies, your favorite cake flavor—you're probably not going to get a cake your partner likes.
If you give the baker the right context about the important person, you're more likely to succeed. But if you provide good information and then go off the rails talking about irrelevant things, it will get confusing. With a limited context window, providing multiple conflicting pieces of information makes a good response unlikely.
Interacting with AI is all about being selective—not only with what we provide but also with what we do not provide. Thinking about context is a centerpiece of building with AI.
Putting It All Together: From MVP to New Features
So, what does all this mean when tied together?
- For an MVP: We want to give the AI only the information relevant to the Minimum Viable Product. Start small, work your way up, and provide only foundational context and important details.
- For New Features: Once you have an MVP, you'll want to build new features. Now, you provide context relevant only to that new feature. This often means creating new chats or clearing the context to ensure the conversation is focused. You should mention frameworks, provide documentation, and be explicit with implementation details. If you find a code snippet showing how to use a framework, copy that snippet, as it will be very useful for the AI.
This all creates an iterative loop: 1. Build: Prompt to create a feature. 2. Test: Does it work? If yes, create a checkpoint and move on. 3. Debug: If you get an error, use your debugging skills. Prompt with different context, try different things, or roll back to a previous checkpoint. 4. Checkpoint: Once it works, save your progress. 5. Repeat: Move on to the next feature.
It's this iterative process—these feedback loops of building, testing, and debugging—all while providing different context and thinking about how to manipulate tokens at a high level. It's all about piecing together information to guide the statistical model toward your goal.
At a high level, this is vibe coding. It's a procedural thinking exercise where you define the problem space, break it down, and go through feedback loops to hit checkpoints until you reach your destination. Along the way, your vision might change, you might come up with new ideas, or you might realize you're not building the right thing in the first place. And that's okay because you've learned something you can carry into your next experience.
Ultimately, you'll get better at critical thinking, visualizing what you want, breaking problems down into discrete steps, and managing an AI agent to build those things for you.
