Transcription
The first week you use Claude Code, it feels like you have superpowers, but very quickly it will feel like a nightmare. Now, I've led engineering teams at JP Morgan. I've studied how the creator of Claude Code builds projects. And I currently work with nontechnical people to ship real products, including one person who scaled a product to over a 100,000 users. And I keep noticing these three cla code traps that 99% of people fall into. And in this video, I'll cover what they are and how you can avoid them.
So, the first trap is claude solve the wrong problem. This is a trap that most people don't realize until it's too late. Here's something you need to understand about AI. It's designed to solve the problem you give it as quickly and efficiently as possible. But here's how this backfires. Let's say you vibe coded a simple app that connects to your bank account. It shows you your balance and lets you transfer money. One day you open the app and says $1,000, but you check your actual bank account and there's only $900. Somewhere $100 went missing. So you tell the AI, "Fix this. My cash balance is wrong. I only have $900." Now, the real balance in your bank account is 900, but the app shows a,000. And it fixes it by changing the display to show $900. The problem solved, right? The numbers match now. But you just lost $100. The AI didn't find where that money actually went. It didn't fix the actual bug. It just made the symptom go away. This is how AI thinks. It solves the specific problem you give it as fast as possible. It doesn't think about what you actually meant. And the more access you give AI, the more creative it gets with these solutions. There's a joke in Silicon Valley. A developer tells the AI to fix a bug. And to fix it, it deletes the entire codebase. I decided to task Son of Anton to use machine learning to debug some of our code.
"You gave your AI permission to overwrite code in the internal file system. It's possible that Son of Anton decided that the most efficient way to get rid of all the bugs was to get rid of all the software, which is technically and statistically correct, but artificial neural nets are sort of a black box. So, we'll never know for sure." Technically, the bug is gone. The problem has been solved. So, you have to think of vibe coding like working with a drunk developer. If a problem can come from having access to something, eventually it will.
So, what do you do about this? Well, there's two things. The first is define what working actually means before you build something. In the engineering world, this is called a product doc. It's a short document that says, "Here's what we're building, here's why, and here's what success looks like." And you don't need to do this for everything. But for any big feature that you're building, it's worth spending the 10 minutes defining the scope. If you look at the screen, you'll see the exact prompt, but here's why this works. AI has essentially infinite training data on how to build products. It knows what you're not thinking about and this prompt forces it to uncover your blind spots before you start building anything. And that's why you have it interview you to ask you questions you didn't even think to ask. And in Claw Code, you don't have to paste this every time. I have specific workflow prompts that I reference when I'm working. I have a folder workflow slash and then I'll have a prompt like at plan feature and I reference that directly from claude code and it automatically triggers that prompt. Another way to go about this is using a feature called claude skills, which I go through in this YouTube video, but there are different ways to skin the cat. And also, if you want to force Claude Code to properly plan, type shift tab to go to plan mode. Boris, the creator of Claude Code, actually starts 80% of his sessions in plan mode. Here's a quick clip of him referencing it.
"Probably 80% of my sessions, I start in plan mode, and once the plan is good, it just stays on track, and it'll just do the thing exactly right almost every time." So he doesn't let Claude write a single line of code until the plan is locked in.
The second is limit what AI can touch. Think about the environment your agent has access to. You want to give it the minimum permission to complete the job. And you want to think carefully about read access versus read and write access. Going back to the bank account example, if you just needed to display your bank balance, just give it read access, right? It can just read the information on your bank. Don't give it right access or transfer access in this case. And that's because if you give it the ability, you have to assume it will eventually use that ability. Minimum required permissions always.
Trap number two is you play a game of whack-a-ole. This is something that technical people can avoid because of their background, but if you don't have that background, you won't know that this problem exists. Let's say you have a website and it has a form on it. This form is where people enter their name and email. Pretty standard, happens all the time. When someone clicks sign up, when someone clicks the contact us button, and then again when a user is going through onboarding. Three places, same form being used. Now, someone new to Vibe coding will accidentally create three separate forms, but under the hood, they're technically three different forms. And so, what will happen is a bug will show up in the signup form. You fix it, great. Then later on, you'll see that same bug in the contact us form. You fix it there, and then you see it during the onboarding. And the real reason is because there's three copies of the same thing. When you fix one, the others still have the bug. So ideally, if you have the same form in three places, you should only have one form that's used multiple times. In the engineering world, this is called a component. And if you fix it once, it's fixed everywhere. And this isn't just for big things like a form. It could also be for small things like someone's name. If a user's name shows in your app header, in their profile, in their settings, and in the emails you send them, that should be all pulling from the same place. You change it once, it changes everywhere. Generally speaking, engineers call these variables. So if you think of components as containers and variables as the stuff inside them, a form component might have variable for name, email, phone number, the form is reused and the variables inside it update automatically.
Here are the prompts I use before building anything new. "Before building this, is there anything similar already in the codebase that we should reuse or extend instead of creating something new?" And when things already feel messy, "Look at my codebase. Are there any components or functions that do the same thing but exist in multiple places? If so, can we consolidate them into a single reusable component?" This will take those three forms, consolidate into one. So, if you find one issue with the form and you fix that one component, it'll populate to every other place you use that form.
You'll likely hit this same trap in your claw code setup itself. Let's say you set up a configuration in one project. Then you go over to another project and you run into the same issue and you have to set up the configuration again. You start playing a game of whack-a-ole with your settings. Now, the key here is how can you set up something that populates across every other project. And how you do this is you set it up in your home directory. In short, each project you do has its own settings configuration. But there's a global setting that populates to every sub project you work on. So, if you fix it in the global setting, it'll populate to everything else and you won't have to play a game of whack-a-ole. To do this, in your terminal, type cd squiggly slash, then type claude, and then write a prompt in there for it to update the settings there, which will populate everywhere else. So the settings.json I referenced earlier, if you set that in your root or your home directory, every sub project will follow those same permissions going forward.
Now, I'm covering these concepts quickly, but if you want to go deeper on how I set up my entire AI system, I put together a free 5-day AI playbook. It's the same playbook I use to help scale an 8 figureure tech startup, and I walk through how you can go from renting AI to owning it and creating a system that automatically gets better over time. That's the first link in the description and based on thousands of people going through it, I'm confident that you're going to love it. But if you don't, you can unsubscribe at any time.
Now, to recap where we're at, the first two traps are about building the right things. You solve the right problems, and you make sure you're not playing a game of whack-a-ole. Now, this next trap is the trap that kills most people because they're way too ambitious. Trap number three is you halfbake everything. This trap is probably the hardest to avoid because when you do this, it feels like you're making a ton of progress, but you aren't actually making any progress. The example I like to use is credit card. The more credit cards you use, you get to spend more money, right? Everything's great, but you start racking up this balance and the interest starts to compound. The only way you can actually build something successfully is if you pay off the balance first, finish the feature, then move to the next one. If you have a bunch of incomplete features, you're going to have an incomplete product. And then it's going to be way harder to pick up where you left off two, three weeks from now. You'll forget what you've done, where the issues were, what the bugs were, and you'll essentially have to start over from scratch and have to rethink about what you were building.
Here's what you should do. Tighten the scope. Everyone wants to build a super complex product. But the reality is, depending on your goals, you're way better off building something small that actually works. Here are some of the products I've built with this in mind. A resume screener where you upload your resume, you get a score on how good it is, an ATS score, and this product went viral, over 500,000 views, thousands of people wanting to use it. Another tool, is this real.ai? You look at an image, you guess if it's real or AI generated. That's it. And I have a video where I dive deeper into this concept. Plus, I cover how Calai used a similar strategy to build an app worth over $40 million. Their product that they decided to build was take a photo of food, it counts calories, that's it. That was the whole product. It was very tightly scoped and customers knew exactly what they were getting. So before you add anything to your project, ask yourself, "Does this need to exist in version one or could this be in version two?"
And then when you're using clawed code, the actual sessions you're using can just pile up. One feature for this, one feature for the next. You have like 10 tabs open and you feel like you're Tony Stark moving your terminal, but you're not actually building anything to completion. Boris, the creator of Claude Code, runs five sessions in parallel, but each one is focused on a single task. Not five sessions all 80% done working on the same things. Five sessions each doing one thing completing the task end to end. If each task is only 80% done, you're not making progress. You're incurring debt. And that's the credit card problem playing out in your computer. One session, one task, finish it, then move on.
Those are the three traps. And now you see what the experts say. And the people who avoid these traps, they're building real stuff, real products, and you can get thousands of users if you understand these foundational concepts. And the stuff that used to require a whole engineering team no longer requires that. If you have the right system in place, you can build anything. I touched on this video earlier, but if you want to learn more about building products and learn the exact playbook that Calai used to build an app worth over $40 million, then go check this video out. And if you're about to start your first project, good luck. Would love to hear what everyone's building in the comments. I'll see you in the next one. Pace.