I Found The Secret To Making Claude 1000x Smarter
By Beau Johnson · · 16 min · 1.6K views
Chapters
About this video
Transcript
Read the full transcript
0:00Most people are using Claude code completely wrong and then they work on their project and wonder why their code is completely garbage. Well, in this video we're going to be fixing that. I've been building with Claude code for over 8 months now and I've launched three SaaS apps using my next JS starter kit and lately I've been working a lot with open Claude getting my entire mission control dashboard up and running running multiple agents and automating the entire content pipeline. I've also helped dozens of entrepreneurs in our shipping school community as we have just launched just a few days ago and we're helping them get their apps built. But the biggest difference between people who succeed with AI coding and people who fail isn't the technical skill at all. It's not prompt engineering, it's not even knowing how
0:45to code at all, it's the configuration files. So specifically the Claude Claude markdown file and the agents markdown file that tell Claude exactly what to work with on your specific project. We actually went over this in the Claude day the day on how important your product requirements document is before you even start building anything. This is the vision, this is the roadmap for your project so Claude knows what you're exactly trying to build. And I'm going to break this down on why this matters so much and how I exactly use these in my own builds and why shipping and why skipping this step is actually sabotaging your whole AI product. The problem with Claude code out of the box is that it's basically flying blind, especially if you're coming from this
1:30industry fresh out the kitchen. You don't even know what you're doing at first and that's fine. I was there this time last year. You open up a new project and you start asking it to write components or fix bugs and Claude has no idea what project architecture you're even putting in place. And it doesn't know your coding standards, it doesn't know what your libraries you're using, it doesn't know your frameworks, doesn't know what you're using for database, authentication, it doesn't know what you're doing for payments. So, you're literally just flying blind and it's going to cause a lot of frustration. So, it doesn't know any of your file structure and it doesn't know any of your naming conventions. So, what happens when you go ahead and start without a PRD or an agent's file? Real quick, before we keep going, if you're watching this and you want to actually
2:15build with some of these tools than just watch videos about them, then you're going to want to check out our community down below, Shipping School. We have a full Claude code course, a full open Claude course, and four live boot camps every single week where we actually help you get set up from scratch. Like, actually set this thing up, not just watch a tutorial and figure it out by yourself. And we also provide one-on-one coaching so you could book a call with me, we could share screens, and I can help you get Claude code or open Claude running on your machine. That's it, no fluff. I built this community because watching YouTube's only gets you so far. We launched it just 3 days ago and we have over 55 members. You need people around you who are actually building, people who hold you accountable, and
3:01coaches who can help you when you get stuck. I'll put the link in the description down below. Get in now before the price goes up. This is going to cause a lot of problems because Claude writes generic React components that look like they came from a tutorial or a traditional vibe coded website. So, that's not what we're trying to build here. We're trying to build products that actually stick out, not blend in. And it suggests packages you're you're not using that are very straight out the box. It writes code in a completely different style from the rest of your project and then you spend half of the time explaining the context over and over again as your hair slowly turns gray. Trying to get Claude to understand what you're actually building can be a difficult thing. It's not as easy as just hitting a button to get Whisper flow activated and then just telling your thoughts and ideas. There's much
3:47more to it and that's why you're probably experiencing some problems. So, I ran into this exact problem when I first started building out Mission Control and getting Open Claw going. So, I'd ask Claw to add a new feature to my dashboard and it would write the code that looked like nothing like the patterns that I'd already established and it would just go off, do different naming conventions, different folder structures, and completely different approaches to the state management. It was a mess. I had 12 different agents going, all the cron jobs were breaking, the daily briefing would fail to deliver, Telegram wouldn't communicate correctly. So, a lot of things that needed to go and start over basically from scratch. So, then I discovered configuration files and this has gotten much better with updates, especially with Open Claw. So, the whole concept
4:33started getting popular after this viral tweet about keeping components under 150 lines hit about 1 and 1/2 thousand likes. The person was sharing their Claw markdown file that had specific rules for their project, including keeping React components under 150 lines of code and developers started realizing that you can literally give Claw a rulebook for your project. So, think about it this way. When you hire a developer to work on your team, you don't just throw them at the code base and say good luck, have fun, even though that sounds great. You give them actual coding standards, a rulebook, a playbook to go by. You show them the project structure, you explain the patterns you use in the libraries you prefer. You set the expectations about code quality and conventions. This is exactly why after building my first
5:20and finishing my second SaaS app, I was like, you know what? I already know what I want to use for database, I already want to know I want to use for authentication. I want to use Polar for payments. So, I just built it built out a starter kit that was going to suit my needs and just be plug and play. So, going back to the markdown files and why the Claw markdown file is super important, that gets created after you produce a really high-quality product requirements document. So, Claw markdown file is basically the vision and the roadmap for your product. It tells Claude, or whatever you want to call it, what to do and what the next steps are for your project. So, it's essentially just like a configuration file that lives within your project folder, and it tells Claude everything it needs to know
6:05about your project, like the tech stack that you're using, your coding standards, and your file organization, your preferred patterns, and even like specific rules about the code quality. It even goes more in-depth than the PRD that it talks about your marketing strategy and how that go-to-market strategy looks like. The results are very much black or white. It's night and day the difference between the two. So, like for example, my Mission Control project, I have an Agents markdown file that covers all of my specific patterns. I tell Claude that I'm using Next.js, and I'm using the app router. So, I specify that I'm using Tailwind for the styling in the front end, and that I prefer functional components with TypeScript. I lay out the folder structure so Claude knows the different types and the
6:50different files and where they should go. So, here's where it gets more powerful, and if you're not doing this, you're underestimating the power of these markdown files. I also include my business logic rules. So, I tell Claude about my agent architecture. Atlas is the chief of staff agent who coordinates everything. The Rizza handles the content creation and the scraping. Inspector Deck manages my social media posts. And when Claude understands this context, it can write code that actually fits into the system instead of generic examples. So, when I ask Claude to add a new feature, to check agent performance, it knows to create components that follow my existing dashboard patterns. It knows how to use the same styling approach I've established thus far. It knows how to integrate with my Neon Postgres database using the connection
7:36patterns that I've already set up. So, instead of suggesting some random state management library, it actually works with the patterns we've already established. The difference is massive when you're starting your project, especially if you've never built anything before. Before using configuration files, I'd spend about 50 to 60% of my time explaining context and fixing inconsistencies. Now Claude just gets it. It writes code and it feels like it belongs in my project from the first try. So this applies to way more than just React components. Inside of Shipping School community, I help the entrepreneurs build all kinds of AI apps. This is our first week going through and we have over 50 members and it's been a great community to kind of hold each other accountable as we build out our projects. So from e-commerce tools to content management systems to
8:23more of an automation dashboard, the people who set up proper configuration files always ship faster with cleaner code. So here's what I typically include in my agents markdown file. So first, the technical stack. Like what frameworks, what database, what libraries, but not just a list of these things. It's like I explain how to use them. Like like I'll specify that I'm using Tailwind, but I prefer utility classes over component classes. Or that I'm using Prisma with specific naming conventions for my database models. So the next thing is I worry about the file organization. Like I will map out the folder structure so Claude actually knows where the components go and then where the specific API routes live, where I keep my types and utilities.
9:10This prevents Claude from creating files in random places or using inconsistent naming. I guess the third thing when comes to setting this all up correctly is your coding standards. This is where that 150 line component rule comes in. I tell Claude to keep components focused and break them down if they get too complex. And if you're just starting out and you have none of this set up, it is okay. My my project that we launched Easy Flip and there was markdown files with 1,200 lines of code. Things worked, it was just sluggish, it was break. If you fix one component, it would break another. So, these are just rules and standards that you'd want to set, especially if you haven't launched anything before. It's going to make building that much more fun and exciting. I guarantee you I got way more
9:56gray hair building our first SaaS, and just not knowing these rules really made it a lot more frustrating and less fun. So, I basically specified that I want descriptive variable names, that I prefer explicit imports over wildcard imports, and that I want error handling on all API calls. The business logic context would be the next thing. This is the part that most people skip. This is the big thing is I explain what my app actually does. Claude doesn't know what your app does until you tell it. So, who the users are, you know, that the avatar that you're targeting, what the main workflows look like. At least give it some context. So, when Claude understands the business context, it makes much more better architectural decisions. The next thing would be like
10:42specific patterns and preferences, like how I structure my API responses, how I handle authentication, what the component composition patterns look like. All of those little details that make the code feel more consistent. And the craziest part is how few people actually do this. I estimate maybe 10, 15% of developers using Claude code have any kind of configuration file. Most people just jump straight into installing Claude code and having fun, which is great. That's a good way to start if you don't have any experience. I'm just telling the building process is going to be a lot more frustrating. So, getting into the coding and you're happy and you're oh man, these things are great. Um things will break, I will just say that. So, you will wonder why things
11:27are inconsistent. So, when you think about it, this makes total sense. You're just jumping in expecting AI to do everything for you, but there are a few files that you just need to get done. You need to put these in your project folder. So, agents markdown file, Claude markdown file, and product requirements document. Those need to be done and reviewed by yourself to make sure that's the project that you actually want to build. So, every successful development team has coding standards and documentation. Every big codebase has a contribution guidelines and architectural decision records. We've known for decades that context and standards are crucial for code quality. Now, I'm not saying you need to learn how to read code or know how to code. I'm just saying learn how to write a good Claude markdown file, good agents
12:13markdown file, and a great PRD. You can have Claude help you with that. So, AI coding is no different. It's just like Actually, it's just more important because Claude has no implicit understanding that human developers pick up from working on the same codebase for months. It needs to know some context. So, from my experience from launching these three apps and setting up a good configuration file, and it's maybe like an hour or two of upfront work, but it does save you dozens of hours of, you know, possibly giving up down the road. And I don't want you to do that. It's been many sleepless nights where when I was trying to get things to work and why API calls weren't working, it's because I didn't have those three files set up correctly. It's not just about time savings. It goes deeper than that. The
12:58code quality is dramatically better. Your project feels cohesive instead of like a bunch of random examples stitched together. So, if you want to see exactly how these structure files get done and get actually the hands-on help of setting your own project, we cover this in the community. I'll put a link down below, and we'll walk you through all of those file setups. We have a full-on Claude cord Claude code course all done. It's 4 hours long. That'll help you get you going. You know, we try to help people that have no technical experience, but they have an idea and they want to launch their app. That's what the community's for. But even if you just take this one insight from this video, just create a basic configuration file for your next project. You're going to see a massive difference in the results. Claude will actually understand
13:43your project better. It will write more consistent code and require a way that has less hand-holding. The key is being specific. Don't just say you're using React and let it rip. Explain your component patterns, your state management approach, your styling methodology. Don't just list the tech stack. Explain how you want to use each piece and how they connect together. So, if you're just getting started and I know it's daunting to feel like, "Oh, I don't want to go in the terminal. I don't want to learn how to code." You don't need to do any of that. You don't need to learn how to code. You just need to know what What's the architecture you're using? What does Better Off Do? What does Supabase Do? Why do I need Google OAuth? And why does that matter? Why should I use Tailwind? You need to know why these things work and you don't necessarily need to know how they work.
14:28You just need to know why they exist in your project so you can relay the information to Claude so it can build out the project correctly. So, when you establish new patterns or add new dependencies, add them to those configuration files. Think of it as like documentation that makes your AI coding assistant actually useful instead of just randomly helpful. This is one of those simple changes that separates people who build real projects with AI from people who just mess around with tutorials. Not saying that's a bad thing. It's just it's going to make it a lot easier when you start building. So, configuration files turn Claude code from a generic coding assistant into an actual team member who actually understands your project. If you want to learn how to build stuff like this, check out link below. That's why we have a community. You'll be able to create
15:13proper configuration files and ship your app idea within days, not months of pulling your hair out. So, we do four live calls a week and we also just opened up a one-on-one with me. So, that is available. And if you guys aren't subscribed already, what are you waiting for? We do five, six videos a day, all on AI news, keeping you up-to-date with the latest tools. Hope you guys see We hope to see you in the next one. Be blessed.
Build this with us, live
Shipping Skool is a free community with 4 live build sessions a week. Bring your idea.
Join Shipping Skool — Free





