AI Mistakes You're Probably Making  I have a feeling I can guess what yourstance is on AI right now. It seemspretty useful and especially helpful insmall projects, side projects, and earlystage startups. But when it comes toreal problems in real codebases, thesetools just aren't that useful. And youdon't understand why everybody's gettingso hyped and excited about them.If that's your perspective, Iunderstand. There are a lot of reasonsmost people should feel that way, and Ifelt the same way just a few weeks ago.But the harsh reality is that things arechanging, and I want to talk a bit aboutthat. More importantly, I want to discussthe mistakes that you might be makingwhen using these tools that result in thelackluster experience you’rehaving. This technology has transformed so muchand my understanding of how to use ithas changed too. I keep seeing others whoare struggling, and when I talk to them,I find this set of mistakes that almostall of them seem to be making. Oncecorrected, these mistakes can lead to really, really goodoutcomes using these tools. Sowhether you're a skeptic who doesn’tsee any value in these tools yet, oryou're someone who's deeply engaged,Weeds using them every day, and you justwant to double-check you're not makingobvious mistakes. Hopefully, this videowill be helpful. I have a ton of sources and things I want to talk about here,and I'm really excited to do all ofthat. But the first thing I want to tellyou guys about is today's sponsor. It's2026. Everything about how we codechanged last year, yet nothing about howwe hire did. That's kind of insanebecause hiring is worse than ever nowthat we're getting swarmed with terribleAI-generated resumes constantly. Ifyou're tired of reading that AI slop,check out G2I. These guys have itfigured out. They have a network of over8,000 engineers ready to go. And thesearen't just people who are fresh out ofcollege. These are experienceddevelopers, many of whom have worked atFANG companies in the past. And they'veall been onboarded with the best modernAI tools. So, you're not going to haveto catch them up the whole time thatthey're employed. They even offer 7-daywork trials to make sure that theemployee you get is a good fit forthe company. Do you know how much easiermy life would have been when I was doingJob hunting: what if I could have tested acompany for 7 days? I honestly thinkboth sides benefit from this. Nobodywants to work somewhere that isn’t agood fit. Nobody wants an employee thatisn’t either. It just makes sense to me. And if you don’t think 7 days is a lot,I have good news for you. Their processto get them to file their first PR fromwhen you start can take as little as 7days. After you sign up for G2I, you’llmeet with their team. You’ll set up ashared Slack channel, decide how oftenyou want to meet in chat, and withinfive or fewer days from that point, youwill have your first candidates, many ofwhom are ready to go on the spot. Anddon’t worry, you get to interview thecandidates yourself, too. They do afirst pass. They’ll even take questionsthat you write for them to ask thecandidates and send you video responsesso you can see how the candidateactually interacts. This is a personyou’re going to be employing. You wantto know what they’re like, not just whattheir credentials are on a piece ofpaper. It’s 2026, guys. Stop hiring likeit’s 1995. Fix it now at soyv.link/2i. So the first thing I want to talk about,One of the biggest mistakes I see isselecting the right problem. So we startwith, "I have a problem." Step one, youvalidate the problem. Is it really aproblem? Maybe this is a thing Imisunderstand or doesn't matter. Butonce you've decided that this is reallya problem and it does matter, the nextthing you probably do is the obvioussolution, if there is one. If you'relooking at this problem and it's a spaceyou understand and the solution seemsobvious, you can go try that. But ifthat fails, you have to do the hardersolution, which is something lessobvious. Maybe you have to debug more toget more information. Maybe you have tothink about it more, read more code,check more logs, find some way toreproduce it. You have to put more time in. But once that fails, you go to stepfour, which is try something new. Thisis the point where once your existingsolutions, your existing way of doingthings has failed you, you then go trysomething else to see if that will solveit. So let's say you have a databaseperformance problem. Maybe when you dotoo much throughput on your database,people start having errors in theirExperience. The first thing to do is makesure it's really a problem. Are theerrors actually happening? Are they onlyhappening when there is too muchthroughput? Are they happening for someother reason? Are they occurring becausethe user has a weird extension, or did theyship something wrong? Once youvalidate the problem, you look at theerror. You see what line of code is on. Then, you go make the obvious fix.You ship it. Nothing changes. You neverreproduce the issue because you couldn'tfigure out how to. So then, you sit down,put in the effort, and try toreproduce it. You think you find therepro for it. You ship some changes. Youput it out. Still have the same issue. At this point, you've concluded thisdatabase I'm using just cannot handlethe things that I'm doing. So, you goexplore new solutions. Maybe you look ata different database. You look at othertechnologies or systems, or you trysomething else. Or maybe you ask the AIfor help at that point. This is aproblem I see a lot. Most people don'ttry a new solution for a problem theyalready know how to solve. If you knowhow to solve the problem, you just solveYou don't use another tool to try to solve it. And this is a very commonmistake I see. People aren't using these tools to solve problems they alreadyknow and understand. They are using them as almost like a safety net type thingonce everything else they've tried has failed. And that's often the first timethey try the thing. This is not meant to pick on Adam, but I think he's actually a really good example of this particular problem here. Come on AI, give me that 10x power that I saw out of Davis 7.Ben Davis is my channel manager, also a fellow YouTuber, and is having a ton of fun building with all of these things.He wants to see how powerful this stuff can be. Here's the example he gave asking a question to Opus 4.5 in cursor.There's a hydration error in this app. I traced it to thisfile provider.tsx; can you help me find the problem? This is, for a lot of different reasons, the wrong way to use AI.Thankfully, I'm already seeing people in chat realizing they're doing the same thing. They aren't reaching for these tools to solve known problems more easily.They're reaching for them when they've exhausted the other things. Within reach, and then they're giving themodel something that's really, reallyhard or poorly understood enough to seemreally, really hard. This is a reallyimportant thing I want to push. I talkedabout this a little bit in the "You'refalling behind" video, and I'm going totry to not let these things overlap toomuch; but one of the best things to trythese tools on is problems you alreadyknow how to solve because then you cancompare your solution to the solutionthe tool would have done. If I know howI would fix this hydration error or thisdatabase error, and I'm curious if the AIcan do it too, start there. It's a great place to test these things out. Oranother way of thinking about it: whatcontext would you give another engineeron your team? When I am handing problemsout to early-career engineers at mybusinesses, I'm not giving them theproblems that I don't understand. I'mgiving them the problems that I alreadyunderstand and know how to write thecode for, knowing that if I give it tothat employee, it's going to take longerand maybe come out worse, and maybe haveto do some back and forth with them toget it in the right shape. That is knowingly to get it off my plateand to spread the knowledge of thecodebase around the team. Learning howto do that with AI is a skill you'llpick up over time, and you'll get anintuition not just of what problems theAI can solve, but also what it needs to know to solve it right. A fun thing you can do here is give it abit and automate it a bit. If you have aproblem and you know how to solve it,you can give it to the agent with the sameinformation you have. For instance, if you saw a logthat referenced a specific line of codethat you're pretty sure is the problembecause of this blog post you read, giveit all of that information, all thethings that led you to the solution. Maybe just go through a PR where you fixsomething. Check out the commit beforethat fix, hand all of what you knew tothe agent, and see if it can solve that.Chances are it will. And if it doesn't,you have something that is as good asgold: you have a reproducible test tosee the capabilities of the model. If you have a pull request that fixes aproblem that an agent was unable to fix,go grab the code state before you pushthat fix, freeze it somewhere, grab allOf the information you need to solve it,put it in a markdown file in that place,and then every time a new AI tool comesout, throw it at that problem with thatfrozen state and see if it can solvethat. Those types of tests are goldbecause benchmarks are often insufficient. Now, if you can collect a handful of these types ofproblems, the few things that the modelscan't do, but you can, you have acombination of things that are useful. Youhave a real-world reproduction test. Youhave the information needed to solve theproblem, and you have knowledge of whatthe right solution looks like and a wayto validate that the solution is correct. That is a hard combination of things toachieve, and you should be hunting for asmany of those as you can find because ifyou can sit on them and use them to runevaluations, you can tell your team orpeople on Twitter or the company thatmade the model, "Hey, this update made itso these five things that the AIcouldn't do before, it can now." That ishuge. If you can confidently sayit still can't solve any of theseproblems, that is even better. That is really useful. And if you can hit meUp and share some of that with me. Iwill gladly pay you to have thesereproductions that I can use to validateand test new things when they come out. That is as good as gold. That said, whatI think you'll discover when you do thisis that when you have the right contextand the right instructions and you haveenough information to solve the problem,if you give the same exact informationto the AI, it will solve the problem inroughly the exact same way. But that'sjust the top of it. That's justselecting the right problem. I wastouching on context management a bitthere. So I'm going to go deeper on thisfor the next piece. This is a projectcalled Repo Mix. Its goal is to take agiven codebase and flatten all of itinto a single AI-friendly file so thatyou could include it as context withchatbots. This project is a scourge andshould be wiped off of the internet. Notonly has this project personally cost meand T3 chat in the entrance, we are running probably multiple hundreds of thousands ofdollars, it also virtually guaranteesyou're going to get garbage output. Itturns out that AI shouldn't have accessTo your whole codebase at once in thecontext. I feel like I have to talkabout this multiple times a day at thispoint because it happens so often, butall AI is autocomplete. If you handit the capital of the US is and thenstop, it is doing a bunch of crazy mathacross a bunch of things calledparameters and those parameters linksome text to other text. When you havethe early text of the capital of the USis, it increases the likelihood that thenext pointer is pointing towardsWashington, DC. The whole model that weuse for LM is next token prediction. Based on everything currently incontext, all of the information passedto the model, what does it think thenext most likely 3 to 6 charactersare? And it does that over and overagain. The fact that these things cangenerate real, meaningful contributionsto real, meaningful code bases thateffectively, through this autocompletestrategy, is genuinely unbelievable andis an accident that it was discovered inthe first place. But you have to beconscious of this when you use thetools. If you hand a model too muchcontext so that the majority of theContext is just nonsense about yourcodebase; it's just going to generatemore nonsense. Sure, there are somemodels that can handle way more tokensthan others. Like Opus 4.5, I think, iscapped at 100, maybe 200k tokens, butGemini can do 1 to 2 million. We shouldjust all use the models with highercontext windows. No, we shouldn’t. The more the model knows, the dumber itgets. The problem isn’t that it needs toknow everything because the more itknows, the less likely it is toautocomplete the solution. Ifthe problem exists in the codebase,giving it the whole codebase does notgive it the solution. If you get tothe context limits, even with somethinglike Opus, once you break 50k tokens ofcontext, the model starts to performworse. There is a very important conceptof context rot, which is when you havetoo much context, and it distractsyou from the thing that matters. Tovisualize it, this is the average scorethat the models get for finding thingsin a set of repeated words. As youincrease the number of tokens the modelhas, the success rates plummet fast. For example, Sonnet 4. Up to a certainAt this point, it's 100% successful. And thenonce you have too much context, it goesdown to less than 60%. If the model hastoo much information, it will performworse. Stop doing this. Imagine if inevery Jira ticket or linear issue youreceived, the actual thing you cared about,like the problem the user had was stuckin the middle of paragraphs uponparagraphs of [ \_\_ ]. And you have togo deep into all of it to just find theactual problem. That’s effectively whatyou’re asking the AI to do when youcompress the whole codebase into thehistory. If you copy and paste your codebaseinto a chat product like T3 chat orChatGPT or anything like that, it'sgoing to confuse the hell out of it. It's not going to perform well. Don't dothat. The reason all of these new toolslike Cloud Code, Open Code, and even toan extent things like Cursor are doingso well at this is because they don'tgive the whole codebase to the model.They give the model tools to find whatit's looking for in the codebase. Thingslike an agent MD or a Claude MD filethat briefly describes what exists wherein the codebase. Things like a GP toolto find the specific line that matters. So that it can address that and onlypull in the section that matters insteadof the whole codebase. Just imagine howyou solve a problem. If you see sometypo on a web page, you don’t go readevery line of the codebase trying tofind the typo. You use a search tool,like Command Shift F, to find it in the codebase andthen you go fix it. Models aren’t thatdifferent from people. If you give it asearch tool, it will use it. If youdon’t and you expect it to read everyline of the codebase, you’re just as badas the junior engineer who would go anddo that. People often ask, “How do youlearn a codebase?” I tell them to gocheck the pull requests. Now, mythoughts are a little different. But youcertainly shouldn’t do it by readingthrough it file by file. You should doit by searching around the codebase,doing things in the app, trying tofigure out where the thing you’re doingexists in the code, in building themappings and the relationships betweenthose things because you can’t keep thewhole codebase in your brain. Don’t expect the model to do it. They don’twork that way. So, we’ve establishedthat giving it your whole codebase isBad. But what is good context? This is amore complex question that you'll getvarying answers about. Generallyspeaking, less is best. If you cansimply describe the thing that is wrongand what needs to be done, you canusually trust the model to go find whatit needs to from there. This is actuallyone of the things that makes Codeexslightly better than Opus right now withcloud code, as Codeex will do a verygood job of reading all of the filesthat might be relevant, only pulling inthe ones that matter, and then going andsolving the problem. It is slower as aresult because it'll spend a ton of timelooking into each potential file thatmight be relevant, but once it does,it'll make a precise change withconfidence. Whereas a model like Opusisn't quite as eager to search thecodebase and is more eager to change it. As soon as it finds something that itthinks is the problem, it immediatelygoes into editing mode. So withsomething like Opus, it is better to puta little more time up front to say theproblem is here. Don't touch this. Don'ttouch that. Just solve here. This isalso an important thing to do with yourClaude MD file or agent MG if you'redoing other tools. I'm very thankfuleveryone else is following a standardand anthropic is just a special snowflake. They are what they are. They'll neverembrace standards that they didn't create.It's how they are. One of the mostinteresting things I learned about theClaude Code team is that whenever theynotice the model doing something poorlyin the Claude Code codebase, theyimmediately go and change the Claude MDfile to help steer the model in theright direction. I actually just madesome changes to the T3 chat codebase forthe same reason. I noticed a couplemistakes that were happening as a resultof this file not steering the model inthe right direction. There are certainthings that we do every day as developers thatthe model probably shouldn't. One of theones that frustrates me the most is PNPMdev. I don't want the model to run a devserver. I have a dev server running. Iwant the model to recognize that I have a devserver running and to just run a type check when it's donewith its work. So I updated this filewhere I describe the PNPM scripts andspecify now, note: don't use this unlessOtherwise, I was told to. All of a sudden,the model randomly running dev commandsstopped entirely. I also wanted it to beable to check the types from Convex,because if I wasn't running a dev serveror it was running in a cloud environmentwhere I didn't have the dev serverrunning, it would make changes to theConvex files and then not have the typesupdated, which would lead to confusionabout the type errors. So I addedanother command here, "pnpm generate," andtold it to generate Convex types afterschema changes. Now it knows when itmakes a schema change, it should runthis command, and then the types will becorrect again. Constantly changing thisfile based on the mistakes you see it make seems like you're babysitting thething. It feels like you're doing waymore work than you have to. I promiseyou it's not. This took five seconds, andit's already saved me hours. It alsohelps with building the intuition forwhat these can and can't do. Funnyenough, when I was at Twitch, Iexperienced very similar things, eventhough this was pre-AI. When I onboardedinto the codebase for the web app whenwe were rebuilding it in React, I wasStill learning React and TypeScript, Iput up my first two PRs and had somedumb mistakes in them. Another engineerwho was much more experienced hit me upand asked me, "Hey, I'm not trying to pickon you or anything, but why did you do thisthough? Why did you write this thisway?" So, I showed him the page inTwitch's docs that made me thinkincorrectly that I should do things aspecific way. I don’t remember what itwas; I just remember this order ofevents. I linked him the docs page thatled to me doing it this way. He said,"Oh, I see why it would make you thinkthat. I'm going to go fix it." Before myPR even merged, they hadupdated the docs to make it less likelythat the next person would make themistakes I made. The issue with AI isthat it doesn't remember things when itmakes mistakes. That's your job. Youhave to build the memory for it, not inthe sense that you have to manage everysingle parameter inside of the model,but in the sense that when you notice itmaking stupid mistakes, like a newengineer might in your codebase, youneed to document that so it's lesslikely to happen to the next person. Because the AI agent is a new engineerevery time it runs. The role of thisfile is to take this really skilledengineer who just joined your companyand make sure they know all of thethings that are special about yourcompany and your codebase. If you'recopy-pasting a CloudMD file fromsomebody else or some template reposomewhere, you're doing it wrong. Evenif you're running the init command thata lot of these CLIs have, you'reprobably doing it wrong. The role ofthis file isn't to describe every singlething about the codebase. It's not justdocs. It is specifically a "gotchas" pile,almost like listing the things you'veseen it do wrong to steer it away fromthat. This file should start reallysmall and simple and slowly have smalladditions and tuning done to it to steer the model away from the things youdon't want it to do. And this file isalways included as context. So it'sbasically guaranteeing that everythingin it will or won't happen depending onhow you describe it. So less code, moremarkdown. This is one of the mostimportant pieces for the big code bases,too. By the way, if you're noticingProblems with agents in really big codebases, the problem isn't the size of thecodebase so much as the number ofopinions and expectations that have beenencoded. As a result, as the codebasegets bigger, the things that are weirdabout that codebase increase, too. Yourexpectations around how people operatein that codebase grow. So, you need toencode those. Another fun side effect of this is I've noticed when I look at anew codebase and I read through thiscloud MD or agents MD file, I learn alot about how the team builds and howthey think about the codebase. It'sactually a really useful way to learn. Honestly, context management is complexenough that I could do a whole series ofvideos on it. It's not complex in thesense that it's super hard tofigure out. It's complex in the sensethat there are many different solutionsto the weird set of problems, and you canfor the most part ignore them and befine. So don't overthink this one. Don'ttry to hack this one either. It's acommon mistake. That's kind of that stupid repo mix thing I was sharingearlier. It's kind of the problem withthings like this. It's trying to hackThe context instead of using the context. Hacking the context doesn’t work.Don’t try to work around this reality.Try to embrace it; recognize the factthat these problems shouldn’t requireknowing everything about the codebase.Again, to go back to selecting theright problem, if you had a reallysmart friend that you were giving accessto this codebase, what informationshould they have in order to solve theproblem that you’re describing? Assumingthey know nothing about the codebase,what is the smallest amount of information youcan give them for them to meaningfullyunderstand and solve the problem? Thatis what you should give to the agent. We’ll probably talk a little more aboutcontext management in other pieces hereand I might even do more videos about itin general in the future. But you haveenough of an idea now about the commonmistakes I see. Hopefully that’ll helpout enough that you can get more valuefrom these tools. Speaking of which, oneof the biggest problems I see is usingoutdated tools or, even worse, holdingyour perspective based on experiencesyou had with outdated tools. Let’s bereal. Coding is based on your experienceusing Sonnet 3.5 in Windsurf in theearly days of agentic coding, where youhanded it the whole codebase contextand didn’t have a cloud.md or an agent.mdfile to help it out. You’re in adifferent world than us. That’slegitimately like comparing notepad.exeto Vim. The gap here is insane. Tobe fair to the people who feel this way,this is not just a cope. This is alearned behavior from a history of doingstuff with software in thedevelopment world. If you tried adoptingGraphQL right when it started gettinghype and it went poorly for you,then you tried again four years later, it didn’t get much better. Andthat’s the case a lot of the time. Thereare things that have a lot of hype thatyou go try, and they just don’t work wellfor you. Going back a few yearslater is very unlikely to changeanything. That has been the case in thedev world for a while. If you triedReact a couple of months after it droppedand you just hated the syntax, the wayit worked, and no matter how hard youtried, you couldn’t get over it, comingback a year later isn’t going to be anyBetter. As much as React haschanged, it hasn’t changed in ways thatwould turn a skeptic into a supporter. It just improved in ways that takesupporters and make them more powerful.So, if you used these tools two yearsago and got nothing out of it, and you’vebased your evaluation on how you’ve evaluated them your wholelives, chances are this thing isn’tgoing to be any better. I understand whyyou’re avoiding it. Things are changingabsurdly fast. I had problems thatnothing in the AI world could solve sixmonths ago that started being solvedthree months ago. They went from,"Oh, haha, AI can never solve this," to,"Wait, what the heck?" in literally a three-month window. That is insane. Thislevel of novelty has not happened in thesoftware development world almost ever beforewhere a tool could go from incapable ofsomething to beyond capable in the exactsame category in months. So if you’re notusing the state-of-the-art stuff, youdon’t know where it is today. And I knowa lot of you aren’t using itbecause I’ve seen the numbers. Not thenumbers of how much you’re using certainmodels or how many tools you’re using. And when you use them, I’m just talkingabout my subscriber count. Did you know that lessthan half of you are subscribed tomy channel? How are you expecting tokeep up on all of this? I canbarely do it, and it’s my job to. If youwant good summaries of what’s going onand what the hot topics are, and what youcan learn from it and whether or not totry it, hit that red button. It costsyou nothing and it helps you a ton withkeeping up. I guarantee you that theengineer on your team who is way ahead,killing it with all these AItools, they’re probably subscribed andyou’re not. Fix it. Anyways, I could sithere and tell you what the hottest toolsare right now, but I want this video tostay useful for a while, so I’m notgoing to do that. You can go checkTwitter or you can go to my channel andsort by most recent to get a rough ideaof what is good enough today. I will saychances are it’s probably not Co-Pilot. And also an important thing, if yourcompany doesn’t let you try the new coolhot things, this is harder to do. And Iactually do empathize with that. If youapplied to get Co-Pilot approved at thestart of 2024, and it finally gotApproved halfway through 2025 andeverybody's moved over to Cursor, Cloud Code, and Codeex. You now have towait a year and a half for it to beapproved again. That sucks. There arereasons that you're on outdated toolsthat aren't your fault. If that'sthe case, first off, I'm sorry. Secondoff, you should start ignoring thoserules and doing it anyway. If you getfired, you have an awesome story. Askforgiveness, not permission. And third,you can probably find a better companyto do these things at because this stuff— don’t fall behind because yourcompany doesn’t let you try new things. You’d also be amazed how many bigcompanies are embracing this. There aremedium-sized companies like Sentry thatare big enough to buy Super Bowl adsthat will let you bring in whatevertools you want. And then there are giantcompanies like Microsoft that will alsodo the same. I can't tell you how manyof the startups I've invested in thathave Microsoft as a customer becausethey're actually willing to try outthese new tools. I think that's reallycool, especially because they competePlaces like Amazon are constantly being told they can't usethese tools because they really want tomake their vibe coding and PRDbuilding better. I think it's called Kira,which is their VS Code fork. There are a lot ofpeople at Amazon who are forced to usethat and can't use better tools becauseAmazon really wants the information inorder to make their tool better. So thatsucks. And if you're in one of thosesituations, figure it out. I'm sorry. Itsucks. I get it. But the fact that yourcompany is forcing you to use worsetools does not mean the tools areuseless. The ones you're using might beuseless. And I know you guys don’t knowmany people using Kira, but all the Kirausers I know are my ex-coworkers who arestill at Amazon and Twitch because they're all forced to use it. So ifthey're skeptical of AI tools, I get it,but you should findopportunities to try the best things. Iam regularly amazed. Like when I startedusing Cloud Code with Opus, after usingcursor with Opus, my brain just keptopening to the things you could do withit. Next common mistake, and I reallyhope people aren't making this, butHonestly, I know you are because I'veseen it a whole bunch, and I've made thismistake myself too in a handful ofplaces. Broken environments—this one isso common. Good example here: I've beenin code bases that are mono repos whereif you open the repo at a root level inyour editor, the type system breaks. Youhave to open the sub packages in orderfor the TS config to work. That's abroken environment. If I can't run a type checkcommand at the root of the project and know that everything in theproject is handled properly, yourenvironment is broken. This is avery common thing. I've seen this somany times. If your type check involvesa CD, an actual directory change, yourenvironment is broken. You can try to teach the agent about all ofthese things through the MD files,through agent MD or cloud MD, but it'smuch better to just fix your environment. I just had this in a Vibecoding project. I was working in theVibe canban codebase, and they had amistake in their ESLint config thatmeant that whenever you opened a file inthe editor and you were in the root, notthe subpackage, every single fileWouldn't be type checked and threw anerror on the first line because itexpected you to be using it at the root. Fix those things. Not just for theagents, but for your co-workers, too. IfI open up your project in my codebaseand I go to a file and it's getting atype error from main because yourconfiguration is bad, fix it. A goodrule of thumb here is if you have a goodengineer who has never touched yourcodebase and you ask them to spin up onit and they run into these types ofthings, you shouldn't tell them whythey're wrong or how to fix it. Youshould go fix the codebase so thesedon't happen at all. Especially because again, these agents effectively havetheir memory wiped every time you runthem again. So if you have this type oftype error where every file has a badESLint config, every single time theagent runs, it's going to see the error.It's going to try and fix the error.It's going to realize the error isn'tbecause of their changes. And I can tellyou how many times we've seen this. Theagent finds the file that it needs totouch to fix the problem. It makes thechanges. It fixes the problem. Verifies the fix. It runs the typecheck. It gets a type error. It freaksthe [ \_\_ ] out. It tries a billion randomthings to fix it. Eventually, it revertsthe change. It sees the same error. Itthen says to itself, "Oh, I guess thiserror already existed and is unrelatedto my changes." It reapplies the changeand then it finally ships. And then yourun the agent with a different problemand the exact same thing happens overand over and [ \_\_ ] over. If you tellan AI agent about a ghost, it will chaseit forever. You need to get rid of theghosts. You need to get those skeletons out of the closet. And do you knowwhat's really crazy? If you see theseissues, you can tell the agent aboutthem and it'll fix them really well. Doyou know how I fixed the problem in theVibe canband codebase? My issue wasthat when I went into a file, I had a typeerror. To solve this problem, I didn’tfeel like dealing with the TS config. Iliterally clicked the little button thatappears that says "one-click fix thiserror." I asked the agent to fix the error. Iclicked that. It put this in the texthere. Following error: parsing error. Cannotread the file tsconfig.json. Fix it.Verify, and then give a conciseexplanation. And it did it. It realizedthe problem is that the project expectedthe tsconfig to be at dot slash. Sowhere we currently are, but it's a monorepo,so it doesn't actually exist thereif you're using it at the top level. IfI had opened my editor in the front-endfolder, it would have been fine. But Iopened my editor at the root, so itwasn't. So what we need to do is use thepath helper to figure out where we areso we can actually link it correctly.And it did this with no issues in oneshot. I then pushed it up, got itmerged, and now the agents will behavebetter when they work in this codebase. So the very problem you are givingagents can actually be solved by thosevery same agents. You need to fix yourenvironments. I have played in far toomany big codebases that have lots ofproblems like this. You can fix themyourself. You can fix them with anagent, but please fix them. Thenext time I see somebody who can't getAI to solve their problem because theirenvironment is broken, I'm going to flip. Obviously, if you have typeerrors everywhere because you struggle withsetting up the environment, things aregoing to break. Fix it. The nextmistake I see is actually one I’m concernedabout because I have a feeling thisvideo might contribute to it. I almostwant to put this earlier, but I’m goingto put it here because this is where itstarts to matter. MCP Helen overconfiguration. I cannot tell you howmany times I have seen this. Peoplespend so much time trying to set theagents up to succeed that they lose theplot. They bloat the context with dozensof MCP servers, and then nothing works. As you know, I’ve been using Cloud Codea lot. Want to see all the MCP servers Ihave configured? Oh, literally none.Zero. Same deal with cursor. Same dealwith every other tool I use. Stoploading up your agents with theseuseless things. Just don’t. It’sso common, too. I’ve seen this a ton.Chad immediately says, "Now, let’s seeyour skill section." Okay, I have oneskill. The front-end design skill. Doyou know what the front-end design skilldoes? It is a single markdown file thattells the model to not create low-quality AI responses. Literally, it says exactly that. This skillguides the creation of distinctiveproduction-grade front-end interfacesthat avoid generic AI slop aesthetics.Implement real working code withexceptional attention to aestheticdetail and creative choices. Never usegeneric AI aesthetics like overused fontfamilies, clichéd color schemes,particularly purple gradients on whitebackgrounds. This is all that skill is.That's all I have for configuration incloud code. I have a custom runner CCthat is a one-line addition to my zishfile that adds a specific environmentvariable in front to hide my emailaddress and also appends thedangerously skip permissions. I am tempted to give a piece of advice: always use modeand dangerously skip permissions, butyou'll get there yourself. I don't needto tell you this. Stop adding all ofthis [\_\_] to your stuff, though. Skillsare literally just markdown files andthey're often way longer than theyshould be. They are for the most partcontext bloat and context rot. Avoidthem unless they solve very specificproblems that you are specificallyHaving tried solving themother ways. And I've talked enough aboutwhy MCP servers are problematic. You should alreadyunderstand that by now. If not, go watchmy other videos. If you are skeptical ofAI being useful in your day-to-day workand you are working with MCP at all, you aremissing out. If you don't see the valuein these tools yet, don't configureanything. Don't go into MCP. Don't add awhole bunch of skills. Don't addhundreds of rules to a cursor. Make subtleadjustments to your cloud MD and your agent MD file. And try to give a bitmore clarity in your prompts as you talkto the model. One more thing, and I feelbad calling this out because it seems like apretty good and very well-intentionedproject. Oh, my open code. This seemsfine if you're already deep in opencode, getting a lot of value from it,and you want to see what it looks liketo thoroughly configure it. That's thepoint of oh my open code. But we'realready seeing in chat that oh my open codeis bloated and messy. Yes,it's a mixed bag at best. You don'tsolve problems with AI coding tools byadding more elements to them. Morefeatures, more MCPs, more plugins, moreSkills, none of that's going to make yougo from this thing is useless to thisthing is useful. If anything, they'regoing to make it feel worse. I promiseyou if you take somebody who isn't sureabout these tools and you clone them. You give one version of this personstock CLA or codecs and tell them tosolve problems; you give the other one asuper customized open code setupwith all the fancy MCPS, all of theskills built in and everything. Theperson with stock codec is going to havea much better time and going to enjoy ita lot more. These things can be usefulin small doses once you have specificproblems that they solve, but nobodytalking about them is there. Everybodytalking about this [ \_\_ ] is just AImaximalists trying to squeeze everysingle possible thing. It's the samepeople who would buy Android phonesbecause they cared so much about everysingle line in the specs. I'm sayingthis because I was one of those people. Iused to tell you very excitedly how manygigahertz were in my phone. I was sohyped when I got my first dual-corephone back in the day. I don't even knowhow many [ \_\_ ] cores my iPhone has. I have literally no idea. I know it's fast. I know the GPU is even faster, butI have no idea what the specs ofthis phone are. I have better things todo, and you do, too. Stop adding allthese unnecessary tools. The tool maximalistpeople are the same ones who care toomuch about specs when your grandma isbuying a computer. It's the exact samepeople. Ignore them and go get real workdone. I feel like Pete comes up inalmost all of my videos at this point,but there's a reason why. He is buildingan absurd amount of things in parallel,all for free and open source, becausehe's already made his money, and he'skilling it. He's doing really cool thingsand he's vibe coding almostall of it. He's vibe coding so hardthat he's putting out 500 plus commits aday regularly. He must be maximizingall of this stuff, right? All thecustomization, all the MCPs, all theskills, all the things. He's probablyrunning his own forked version ofwhatever. No. Ready to see what he uses? He uses stock codecs. Here is his configfor codecs. Defaults to GBD 5.2 Codeexhigh. Defaults to high reasoning, has aHas a model autocompaction limit, andthen in the features, ghost commits areoff, unified exec is true, free formpatch is true. It's just a tool theyhave for doing patching better. I thinkit's on by default now. Web searchrequest is true because, for whateverreason, the search tool forsearching the web is off by default inCodeex. This is like the only part inhere that really matters. Skills is truebecause he's playing with skills. And thenthe shell snapshot is true. I don't evenknow what that does. This allows themodel to read more in one go. Thedefaults are a bit small and can limitwhat it sees. It fails silently, whichis painful and something they'lleventually fix. Also, web search isstill not on by default. Yeah, theunified exec apparently replaces usingT-mucks for handling execution. Notmuch, but like that's it. No crazyplugins, no crazy forks, no absurdorchestration stuff. Keep it simple. Ifthe thing isn't useful in the simpleform, it's not going to magically getuseful by adding a bunch ofPlease stop. I actually really like thisarticle he did called Just Talk to It. This is as people realize over time whatthey can do with these things. Theystart with "Please fix this," and as theyget more into it, they do crazy things—eightagents running at the same time, complexorchestration with multiple checkouts,chaining agents together, custom subagent workflows, libraries with tons ofslash commands, full stack featuresbeing built in MCPs. All that [ \_\_ ]. Once you get through all that, yourealize the best thing to do is justsay, "Hey, look at these files," andthen do this thing. Life is much betterwhen you realize that's all you need.That said, even he admits he'llsometimes just take a screenshot of aproblem that's wrong, paste it to themodel, and say, "Fix this," and it will.Last important piece here: plan mode anditeration. A very common mistake I willsee is someone asks the agent to dosomething, usually compounded with theother mistakes, like with a bunch ofweird tools on, nowhere near enoughcontext on the problem, and then itstruggles. And rather than fixing thecontext, they keep asking for more thingsand adding on. They keep appending morestuff as the mistakes compound. Remember, this is all autocomplete. Soif the history that it has is a badinstruction, incorrect implementation,and then a correct instruction, there isstill more bad information than good. Ifthe whole thing is autocomplete based onthe history, having a bunch of badthings in the history is going to resultin bad output. Even if you put a good thing atthe end, obviously, it can work throughthis, and there are plenty of examples ofit doing it. But it is significantlybetter to not do this this way. When younotice that the output came out bad,rather than trying to fix it with a betterinput being appended, revert, go back,and make the better input the start. Becauseif you have a better input as the start,the likelihood that the output is bettertoo is much higher. The more goodcontext exists in your history, the morelikely the next thing is good as well. Obviously, there's a limit here. If youhave too much context, chances are thecontext has become less relevant, whichmakes it worse, which makes the outputworse, too. Fix it. And you know what?One of the best ways to fix this is planmode. Plan mode is great because insteadof the bad input resulting in a badThe output will be a confusedoutput. In fact, it'll be confusedquestions where instead of it doing awhole bunch of things it shouldn't, itwill add a little bit of additionalcontext. That is, "Hey, I'm not sureabout these three or four things. Canyou answer these questions for me?" Andyou might realize, "Oh, I should have putthat at the start." You can kill itand restart if you want, or you cananswer the questions. Those answers tothose questions result in betteranswers. Then the model can output agood plan. Now, the majority of your context andthe majority of your history is useful.So the likelihood that it buildssomething good is much higher. This iswhy plan mode is good. It gives theright relevant context instead ofhanding the model your whole codebase ora bunch of tools to find things in thecodebase. The plan mode creates aperfect prompt almost. The goal of planmode is to write the exact thing youwant to hand to the model that it canthen go use to solve the problem. But areally important piece here is whathappens if it goes wrong. This plan, you think it's good. You runit with the model and it comes out witha bad output. If it's just a few thingsthat are wrong, sure, tell it that. Tellit to go fix those small things and itwill. But if it gets the whole thingwrong, reflect on why. Read a little bitof what it did. Read the reasoningtraces for why it made the change youdon’t like or the thing that you don’twant. If it's something that was wrongwith the plan, go fix the plan. If it’ssomething that was wrong with theunderstanding of the code base, go fixyour Claw MD or your Agent MD file. Thisis the delicate balancing act you haveto do. And it's an intuition you buildas you do it more. You'll write a plan. The model will start executing on it.You catch something it's doing wrong andyou'll just know where to go to fix it.Just to go back to my example earlier inthe T3 recheck codebase when I ran aplan and it got the code right, but thenit ran a dev server and it couldn'tverify things because the dev serverwent to the wrong port, caused errors,and broke. I knew the solutionwasn't to add to the plan. Don't run devcommands. I know that because I used to doInstead, I went and put it in theagent MD file and then cloned it as thecloud MD file, and the problemdisappeared. Figuring out where to putthe thing to stop the bad behavior is anintuition you'll build, and you'll buildit way quicker than you think. The sameway you build intuitions about how touse a tool. Right? Like in React, youdon't put hooks after an early return. You just understand why after you use it for abit. Those types of things areintuitions you build as you use thetools, but you have to build them, notjust keep saying "fix it" over and overagain. Generally speaking, ifyou're not oneshotting things often,that's because there are problems inyour prompting, problems in your contextmanagement, problems in your agent MDand cloud MD files, problems in theenvironment you have given the model tosolve things in. And as you catchmistakes on the other side, there aremore solutions there, too. If you noticethe model makes code that works but thetypes are always erroring, go give it acommand to check the types so that it knows they are good. A lot of things nowhave type-checking plugins built in withThe LSPs. I've had mixed success withthose personally, but giving it atype-checking command can solve almostall of these problems. Don'tover-engineer it. Just identify thecommon mistakes and fix those in theagent MD or in a given plan. If amistake happens, don't tell it tocorrect it. Go back and adjust the planand rerun it. So, to wrap things up, Iwant to go back to this tweet from Adamin the back and forth we had on it. Hecouldn't get it to solve this error. Hehad done a little bit of work. He foundthe file that it is likely coming from. He knew it was from this provider tsxfile, but he couldn't figure out why. Healso wasn't very clear in the ask. Hehad an ask mode and asked it if it couldhelp him find the problem. It's not abig deal. Models can work through thattype of thing, but being more conciseand specific about what you want from ithelps a lot. The bigger problem herethough is that he didn't know what theproblem was and hadn't found the rightcontext for it. The feedback I gave wasthat he should copy-paste the exacterror, give it any useful context, likedoes it happen when logged in or logged out? Out users' other information that couldmake it easier to root cause the bug,especially with a case like this, because it'shappening in the browser. A tool that Ican use to verify its fixes, likePlaywright or access to the browserdirectly, can be really helpful. I alsospecified putting in fewer qualifiers insteadof "Can you help me find it?" It's "What isthe cause of this error?" And if you thinkthe model can fix it, just skip straightto build mode. It turns out the reason thatAdam couldn’t do this is because hedidn't know that there was an exacterror. His immediate response was, "Thereis no exact error." Isn't there theonly framework that manages to actuallygive you a diff when the HTML is brokenwith a hydration error? And this isagain to go back to the start; why he wasusing the model. He was using a model tosolve this problem because he had triedall of the other things he knew of, andthey didn’t work. So he was using themodel for the first time as a lastfallback, and that’s not going to workwell. If you’re only using these modelsbecause you don’t have enoughinformation to solve the problem, you’renot using them right. And what made thisOne really funny thing is that I effectively played the role of what you wantedthe model to do here. I told it thatthis was added in React 19, that you havetraces that now show you in React wherethe hydration error occurs. I'm anidiot. The diff was right in front of myface. What's crazy though is that itappeared to understand perfectly what ahydration error is, but it diagnosed thecause wrongly, even absurdly — almostexactly backwards. Yeah, because itdidn't have enough context, because youalso didn't have enough context. Andonce it found the right error and handedthat to the model, sure enough itcould solve it perfectly. So again, ifyou apply the lessons from what I justexplained here, you have to select theproblem well. You have to not select aproblem that you don't know how tosolve. Ideally, you have to give theright context and find the context if itdoesn't exist. Help the model work on itwith you if it doesn't, and you want tobuild it. It wasn't using outdatedtools. All that stuff was fine. Theenvironment was kind of broken in thesense that there was no way for it toknow the right way. If he adds everything, he would quickly end upin MCP hell. So finding the rightbalance is a hard thing to do, but ifyou do it right, it's great. Withthe right application of a handful ofthese tips, he would have had a muchbetter time. After that back andforth, he is now enjoying these toolsmuch more. I hope I've done a decent jobof explaining why I like these thingsand the mistakes that I've seen othersmake with them. And maybe, just maybe,you'll become more of a vibe coder asa result. At the very least, you have awhole new set of things to critique me forin the comments. Let me know how youfeel about this one. And until nexttime, peace nerds., AI Mistakes You're Probably Making, YouTube, 01kfrjaz1tp8earx7xqwvp008b.