Transcription
I just had a tweet blow up, and reading the replies, one thing became clear. Everyone's using AI to code now. But there's a huge difference between software developers strategically guiding AI and vibe coders who just let it take the wheel. So today I'm showing you how to actually code with AI, not Vibe Code. And I'm going to be using Warp Code to showcase everything, as they are the sponsor of today's video. But these principles apply across the board.
Regardless if you use Warp Code or Claw Code or Cursor, whatever. First, stop repeating yourself. You want to set your foundation once. That is, have your AI index your codebase so it actually has context of your full codebase. Warp Code does this with codebase context. Then, set up your rules. Rules are important, and you have two different types: global rules and project-specific rules.
Global rules in Warp Code go in Warp Drive. These are your coding standards, preferred libraries, common bash commands, testing philosophy, whatever you want to apply to every single project you open in that tool. Project-specific tools go in a repo file like warp.md or claw.mmd or cursor-rules. That is your tech stack and versions and database schema, API patterns, branch naming conventions, and you can have more than one if you want to specify something different based on where you are within your codebase. So different sub-modules may need different rules. So have a specific rules file for that sub-module.
Now, with rules, every AI interaction knows your preferences and starts with guardrails without you typing "use TypeScript and Postgress" for the millionth time in every single prompt.
Now, let's talk about prompts. The number one rule is: be specific. Here's the difference between amateurs and professionals. A prompt that says "make the edit button toggle" is lazy. I mean, that can mean 50 different things and a bunch of different implementations of how to achieve that thing. Instead, say something like: "Add a boolean field 'editable' to the users table, expose it through API users ID endpoint, and conditionally render the edit button component based on that field." See, that's concrete. It's testable and removes margin for error and hallucination. It's also where your software engineering skills come into play. You already know what needs to be done. So, be specific in telling the AI what exactly to do. Here's a template you can steal. It's not perfect for everything, of course, but it'll point you in the right direction.
And to be even more specific than just what you say in your prompt, add context. Reference what file to add this to, or what file you need to read in order to implement a specific function, or what code you want refactored or changed. And sure, you might say, "Well, it already knows my entire codebase. I don't need to specify it." While that's true, it allows the task to be more specific and also saves you a lot of money and tokens because your AI doesn't have to search throughout the entire codebase. In Warp, I use `@context` or I just highlight whatever code and then right-click and add it to the prompt because now Warp does finally have a solid built-in rich text editor, which is one of my main complaints to them. But they fixed it, or should I say, added it. And sometimes you're facing an issue with the UI or a bug, something that you would need to take a screenshot of. You can also upload images to give more context to the AI. In the past, I would let my prompt be a little open-ended for the AI. I don't do that anymore. Don't ask the AI to guess.
And to save even more money, specify what models to use, not just auto-pick whatever model, because as you may know, Opus 4 is going to cost a whole lot more than, well, basically every single other model. And don't switch models mid-conversation unless it makes sense. Like if you're going to plan with a specific model that's better at planning, let's say it's GPT-5, and then you want to code using Opus 4 or Sonnet 4, that makes sense. But if you're just switching it willy-nilly, well, switching models doesn't transfer over the cash. So when you switch, more requests are going to be consumed, more money is going to be spent. Also, keep the conversations short and focused for each individual task because each conversation's history is going to be prepended as context. So the longer the convo, the more each prompt costs.
And when it comes to your workflow, treat it like an actual software development workflow. Treat each AI task like a real task you would have in a sprint. Small, iterative, testable, and approach them like a real software engineer, not a vibe coder. You understand architecture, you understand patterns and logic, and you know the codebase, so use that knowledge. And there are a few different approaches in how we tackle a task. Typically, we plan first. So, have the AI help you plan it first. So, first, in plain English, I tell the AI what I want to do, like: "Create a tool favorites or bookmarks feature for the developer tool directory." That's what this app is. And then I say: "Create a detailed implementation plan that breaks down exactly what needs to be built, in what order, and how the pieces connect together. Consider the data flow, the key functions or classes, the potential challenges, and the integration with other components." And you can see the other specifics that we have here. And focus on practical steps to make this feature work smoothly. Don't write any code yet. I'll do this with GPT-5 High Reasoning because it's good at planning, and let it roll.
And then you can take a look at the plan. Ensure that it's exactly what you were thinking of and give any restrictions in your next prompt when you say: "Implement exactly this plan with the following restrictions: Only edit these specific files, constraints like no new dependencies, and preserve existing filters. Deliverables: the code and how to test the code." And then, if anything in the plan is ambiguous, stop and output two options with trade-offs instead of guessing, because you don't want your AI to guess. And what I'll do is come over here, Claude 4.5 Sonnet, and let it roll. Or what I can do instead of manually changing the model every single time is come over to settings to AI and create an agent profile. So I can have the base model be Claude 4.5 Sonnet, and then the planning model is GPT-5 High Reasoning. I can also specify it to create a plan at any time. Oh, and it looks like this agent is done. And as we told it to, it gave us two concrete options of how to move forward. We can pick one of those and have it actually code the feature.
And when code comes back, review it like you're pair programming with a junior developer. Don't just blindly trust it like many juniors do to their seniors. Ask questions like: "Why did you choose this pattern?" or "What are the error cases?" or "How does this impact performance?" Question its decisions. Get an understanding of why it implemented anything that is confusing to you. And most importantly, jump in, look at the code, review the code, and don't be afraid to edit the code. And then have the AI refactor around your changes if you want. You don't always need to do that, but it's an option if you're a little uncertain on something. You have to view this as collaboration between you and the AI, not delegation. The only thing that's different between pair programming with an AI and pair programming with another dev is that the AI is not going to judge your variable names and eat your lunch. Sorry.
That's the overall gist of things, but nowhere near all an AI can do to help you code. Because once you get used to that flow, working pair programming with the AI, using the right prompts, and actually doing things correctly, because prompting, whether you want to believe it or not, is a skill. Once you get used to that flow, you could start implementing multiple agents at once in various different ways. And your first thought is, "Yeah, you can have three agents working on independent tasks." But you can also have three agents working on the same task. Agent one writes the code. Agent two reviews the code and provides feedback. And agent three writes tests for the code. The reason you'd want to do that is because having different context oftentimes helps. Just like with anything, having a new set of eyes on a problem can help. And you're not just affirming the work that you already did. You could even have a fourth agent read the code and the feedback and the tests and then refactor it from there. You just got to always make sure that you, the human agent, are also doing that. You're also reading the code and the tests and diving into the code and coding. I know I already said this, but it is the most important part of all of this. That's the difference between using AI to help you code and vibe coding.
And frankly, while you can have all of these agents running at once, it, it, I don't do that very often, at least for coding, if at all. I'll have one coding, one exploring the codebase, one maybe refactoring some code because those are more manageable than, you know, building a whole new feature, and maybe another for testing or something along those lines. I maybe I'll have two, three max. But if you do want to have three all running on independent tasks, what you would want to do is create multiple Git work trees or checkouts, and you can run different AI sessions in parallel. And you go from AI session to AI session, approving and denying operations as they go. Or you can have it run autonomously, and you review the code and feedback and tests as each one completes it, like you're Magnus Carlson playing chess against 20 people at the same time. And then you give them the next step. But again, this can get very overwhelming.
You can also operate Git in natural language, like just saying: "Create a release branch and cherry-pick the aux fixes." Warp Code handles the Git operations without you memorizing commands and flags and all that. And again, uploading images. If you can't describe a UI bug or something, screenshot it, upload it with a prompt to fix it. Or if you need to implement an API, drop in the docs URL. But something to remember, the full page typically gets sent to the model, then extracts the information you need. So it may increase usage, increase costs.
I made a whole video on this, but you can use AI to explore unfamiliar codebases, whether you're contributing to open-source or joining a new team. A lot of dev teams nowadays that I'm familiar with actually use this heavily as a part of the onboarding process. Just think of this as conversing with the codebase. Ask it to summarize component responsibilities or trace data flow. Explain architectural decisions and have it create a whole entire flowchart for you so you understand how things are connected and, well, anything you can imagine and anything you're curious about.
And something that's important is you should also set up permission checks. Some tasks need approval. Others can run autonomously because you don't want to have to approve every single task there is. And again, some need approval, so make sure that is set. And you know how I said it can get overwhelming? Well, you need to know when to pull the plug. If you're losing control, have a bunch of agents running and it's generating chaos, stop. Revert the task work completely, or to a previous checkpoint that you were like, "Hey, it kind of works right here, but I didn't commit it." Or maybe you did, and revert to that commit and do it.
And look, just to reiterate this, the goal is not to replace your engineering judgment. It's to amplify it. AI is not here to replace you. It's here to help you. At least that's the current state of things. So, take advantage of it. AI won't magically make you a 10x developer, but it will help you with some pain points and code faster while maintaining the quality and explore new code bases without existential dread and write tests without questioning your life choices. The key is to treat it like a very capable intern. You don't just say, "Hey, go make this button toggleable." You, you, you guide them a little bit more than that. You be specific. And that intern, think of them as having brilliant potential, but you still need to know what good code looks like and understand the why behind it, where you're just letting your intern do everything for you. You see how that, that wouldn't really make sense with an intern. So why would you treat AI like that? You see?
So, that is how you code with AI, not vibe coding some way to some production disaster, cuz we've never seen that before. Oh, yeah. And right now, you can try Warp Pro free for 7 days with 2500 AI credits with no card required. Just click the link in the description. Now, if you'll excuse me, I have to go explain to the AI why we can't use blockchain to fix a CSS bug. Y'all have a good one.