Everything You Need to Know About Coding with AI // NOT vibe coding

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 goes in a

repo file like warp.md or claw.mmd or

cursor rules. that is your text 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 subm modules may need

different rules. So have a specific

rules file for that subm module. Now

with rules every AI interaction knows

your preferences and starts with guard

rails 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 at context or I just highlight

whatever code and then rightclick 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 autopick 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-con 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 GPT5 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 GPT5 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 cuz 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 clawed 4.5 sonnet and

then the planning model is GPT5 high

reasoning. I can also specify it to

create 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

oftent times 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 uh

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 code base, 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

cherrypick the aux fixes. Warp code

handles the git operations without you

memorizing command 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 code bases,

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.