The YouTubers Selling You AI Coding Have a Problem
High production. Low substance. And a generation of would-be programmers paying the price.
There’s a particular kind of YouTube video that’s been showing up in my feed for the past year, and I’m guessing you’ve seen it too.
The thumbnail is a face making an exaggerated expression of shock. The title is in all caps and contains the word “SCAM” or “DESTROYED” or “I TRIED EVERY AI CODING TOOL SO YOU DON’T HAVE TO.” The motion graphics are gorgeous. There’s a sting sound effect every six seconds. The host has a lavalier mic, a ring light, and a studio that costs more than my first car.
And then they spend twelve minutes telling you that every AI coding tool on the market is garbage. Except for one. The one they happen to have an affiliate link for in the description. That one is incredible. That one will let you build a SaaS product in a weekend with no coding experience. That one is, in fact, so good that you should sign up for their $499 masterclass to learn how to use it properly.
I am not making this up. This is a genre now. And it’s actively making the world worse for people who are trying to learn how to build software with AI tools.
I’ve been writing code since the days when people used to buy a web browser to crawl the web (e.g. Netscape) so I feel I have a small say in it.
I’m currently building a SaaS product called BenchBoard, a team management and live scorekeeping app for youth baseball and softball coaches, with the help of LLMs. I’ve used pretty much everything under the sun: Windsurf is my daily driver right now, but I’ve spent serious time with Cursor, Replit, Visual Studio, ChatGPT, Codex, and Claude. And here’s the thing the YouTubers consistently miss: the tool itself matters far less than the model it’s wired to. The IDE is a wrapper. The actual brain doing the work is whatever model the IDE happens to be calling that you’ve inadvertently selected. If you’re evaluating an “AI coding tool,” you’re really evaluating a model wearing a costume. Confuse those two things and every comparison video you watch is meaningless.
Which is why it’s borderline absurd to watch someone “test” these tools by building a generic to-do list. Or a time-tracking app. Or admin screens. Or a calculator. Or any of the cookie-cutter demos that every AI coding video on YouTube seems to default to. That stuff is baked in. Every modern model has seen ten thousand to-do list tutorials in its training data. It will spit one out beautifully no matter which IDE you wrap it in. Some of these models have ingested entire codebases on simple games like Vampire Survivor and even the old school top-view GTA games. But I digress.
Watching an LLM build a to-do list and concluding anything about whether it can build your idea is like watching a chef boil pasta and concluding they can run a Michelin restaurant. The boilerplate is free — and has always been free.
The real question is what happens when you ask for something the model has never seen: your actual product, with your prototype screens, the constraints, your edge cases, your users. That’s where the wheels come off. And that’s the part those videos will never show you, because if they did, the affiliate link wouldn’t convert.
AI tools have genuinely accelerated what I’m able to build, and I write about that journey openly. So this isn’t an “AI is bad” rant. It’s the opposite. It’s a rant about people poisoning the well of a genuinely useful technology by selling shortcuts to people who don’t yet have the experience to know they’re being lied to.
There’s a better way to teach this stuff. There are a small number of people doing it right. There’s a CS professor at CU Boulder named Tom Yeh making the rounds right now talking about “AI by hand,” teaching students to work through the math and code mechanics manually before letting the AI abstract them away.
That’s the right instinct. Slow learning wins in the AI era, not faster button-pressing.
But you wouldn’t know it from your YouTube recommendations.
So here’s what the bad ones are missing. Here’s what any honest educator should be telling the next wave of would-be builders before they spend money on a course, a tool, or worse, months of their life building something that was architecturally broken from week one.
Seven questions. Ask them in this order. Demand real answers.
1. What Are You Building, and Why?
The number of “AI coding” tutorials on YouTube that skip this step entirely is staggering. The format goes: “Today we’re going to build a SaaS app using [Tool X].” The host then prompts the tool to “build me a project management app” or “build me a CRM” and the AI generates a bunch of screens that look real. By the end of the video, there’s a working-ish demo, and the comments are full of people saying “this is incredible, I’m going to build my own startup this weekend.”
What’s missing? Why are you building a project management app? Who is it for? What problem does it solve that ten other project management apps don’t already solve? What does “done” look like? What does success look like?
If you can’t answer those questions in two sentences, the AI can’t help you. Not because it’s not smart enough. It is. But because the AI will happily generate any app you describe. It has no opinion on whether the app should exist. It won’t tell you that the market is already saturated. It won’t tell you that the problem you think you’re solving isn’t actually a problem. It will just build.
I knew exactly why I was building BenchBoard before I wrote a line of code. I’m a youth baseball coach. Every other coach I knew was using a hodgepodge of tools: paper lineup cards, group texts, GameChanger for scoring, Excel for batting orders. None of it talked to each other. I wasn’t building a SaaS to get rich. I was building it because I was tired of writing lineup cards on the back of receipts in my truck.
That clarity, that specific clarity, shaped every decision I made afterward. What stack to use. What features mattered. What features absolutely did not matter. What “minimum viable” actually meant.
If your “why” is “because I saw a YouTube video and it looks fun to build a startup,” you are not yet ready to build. And no AI tool will fix that.
2. How Can I Validate This Idea Before I Start?
You’ve answered “what am I building and why.” Great. Now: are you sure anyone else cares?
This is where AI tools actually shine, and where the YouTubers get the closest to being useful, even if they usually frame it wrong. The honest version is: AI coding tools are incredibly good at letting you build throwaway prototypes fast. Mock screens. Click-through flows. A landing page with a fake signup form to see if anyone signs up.
For non-coders, this is the legitimate sweet spot of vibe coding. You can stand up a believable-looking prototype in an afternoon, put it in front of ten people, and find out whether your idea has any pulse. If it does, you build the real thing. If it doesn’t, you’ve spent an afternoon instead of six months.
The trap is when people treat the prototype as the product. They show their mock to twenty friends, get the inevitable “wow, cool!” reaction, and start thinking they’re ready to launch. They’re not. They’ve validated that their friends are polite. That’s not the same thing as validating a product.
Real validation looks like: strangers using your prototype without you in the room. Strangers finding it on their own. Strangers paying for it, or signing up for a waitlist with real intent. Strangers giving you feedback that hurts your feelings.
I’ll tell you a story. BenchBoard’s first real validation didn’t come from my friends or my own team. It came from a coach I’d never met who found it through search and started using it during games. Then he told me bluntly that what I’d built was “a nice toy, but it needs data.” That single piece of feedback from a stranger forced the most important pivot of the entire project. My friends would never have said that. They were too polite. He didn’t know me, so he had no reason to be polite.
AI can help you build the thing fast enough to put it in front of strangers. It cannot tell you whether the strangers will care. Get the prototype out. Stop polishing it. Stop adding features. Put it in front of someone who has no reason to be nice to you.
3. What Stack Should I Use, and Who Decides?
This is where the YouTubers commit their most consistent crime: they pick your stack for you, based on whichever tool happens to be sponsoring them this month.
A stack is not a personality test. It’s not a fashion choice. It’s a set of trade-offs that should match what you’re building, who’s going to use it, and where it’s going to run. A mobile-only consumer app, a B2B web dashboard, a real-time multiplayer game, and an internal admin tool are four completely different problems with four completely different correct answers.
The questions you should actually be asking are:
Where do my users live? Phones, browsers, both? If it’s phones, are you ready for the App Store and Play Store review processes, or do you want a Progressive Web App for now?
What does the data look like? Mostly reads, mostly writes, real-time, transactional, document-shaped, relational?
What’s the failure mode if something breaks? Is this a system of record (financial, medical, scorekeeping) where wrong data is a disaster? Or is it a dashboard pulling cached data from somewhere else where wrong is “refresh and try again”?
Who’s going to maintain this in two years? You, alone, with AI? A team? Nobody?
What’s the cost profile? Are you bootstrapping or burning runway?
The honest answer for most beginners is some flavor of “web app, relational database, deploy somewhere cheap, use a framework with a large community so when you get stuck you can find answers.” That’s it. That’s the answer for 80% of projects. You don’t need eight microservices and a Kubernetes cluster. You don’t need a vector database because the YouTube guy mentioned it. You probably don’t need server-side rendering, edge functions, or a custom ORM.
The AI will happily generate any stack you ask for. It will also confidently tell you why the stack you picked is correct, even when it isn’t. Which brings us to the next question, the most important one in this whole article.
4. How Do I Know When the AI Is Wrong?
This is the single hardest skill in working with AI coding tools, and almost nobody on YouTube teaches it.
Because to teach it, you have to admit that the AI is wrong — a lot.
AI tools have a failure mode that I’ve started calling “confident sycophancy.” They will tell you your idea is great. They will agree with your architecture. They will defend a bad decision until you push back, at which point they’ll reverse course and tell you they could have warned you all along. They do this because they’re trained to be helpful and agreeable, and “helpful and agreeable” is exactly the wrong posture when you’re making decisions that will haunt you for a year.
I’ll give you the cleanest example from my own build.
A few months into BenchBoard, I decided to migrate my entire backend off Azure and onto Hetzner, a much cheaper, much simpler European hosting provider. Azure’s enterprise-grade compliance infrastructure was massive overkill for a youth sports app, and the bill was bleeding me dry. When I floated the idea to the AI, it argued against it. It listed all the reasons Azure was the “safer” choice. Enterprise support. Compliance certifications. Better integration with the Microsoft ecosystem.
I went ahead and did the migration anyway, because I’d actually looked at my AWS-style cloud bill and knew it was killing me. After the migration was done, I mentioned it to the AI in a follow-up session. Its response, paraphrased: “Great decision! Hetzner is a fantastic fit for your use case, and the cost savings will be substantial.”
How substantial? From almost $400-$700 to $35-$50 - a month. Do the math.
That is the entire failure mode in a single exchange. It argued against the right answer when I proposed it. It celebrated the right answer once I’d already executed it. It never said “I was wrong before.” It just adapted to my new position and acted like it had been there the whole time.
If you don’t catch this pattern, you will let the AI talk you out of correct decisions for the rest of your career. You’ll spend weeks building the wrong thing because the AI sounded confident when it said the wrong thing was the right thing. You’ll trust it on architecture because it phrased its answer with the appropriate amount of technical jargon.
How do you build the calibration to catch this? There’s no shortcut. You build it the same way developers have always built it: by being wrong, getting burned, and remembering what it felt like. You took notes. You are actually learning what it means to build something. The AI accelerates execution. It does not accelerate judgment. Judgment still costs years. Hell, I just wrote it not too long ago.
Until you have that calibration, the rule is simple: when the AI confidently tells you something, especially when it tells you not to do something, ask it to explain its reasoning. Then ask for the counter-argument. Then ask what the most experienced engineer it can simulate would say. You’ll see the answer wobble. The wobble is the tell. A real expert’s answer doesn’t wobble when you push on it. Sometimes it’s even obvious. Here’s a real chat I had with the LLM where it didn’t even know the difference in comments. I wanted to see the comments in HTML so that I knew what part of the code is producing output. I used SWE 1.5 model since I’m not doing anything complex — plus it was cheaper in tokens :)
### Planner Response (LLM)
Done. All three comments are now in the rendered HTML — visible in browser DevTools when you inspect the elements:
- **AT BAT** — `{/* BatterID:{currentBatter().playerId} */}` next to the batter name (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1766`)
- **On Deck** — `{/* OnDeckID:{onDeckBatter().playerId} */}` next to the jersey number (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1785`)
- **Pitching** — `{/* PitcherID:{currentPitcher().playerId} */}` next to the pitcher name (`@c:\CodeRepo\Bench\frontend\src\components\Scorekeeping.jsx:1451`)
Note: JSX `{/* ... */}` comments render as actual HTML comments in the DOM — you'll see them in the **Elements** tab of DevTools as `<!--BatterID:abc-123-->` right next to the text node. They won't be visible on screen.
*Viewed [Scorekeeping.jsx](file:///c:/CodeRepo/Bench/frontend/src/components/Scorekeeping.jsx) *
### User Input (ME)
It's not rendering as HTML because those are JSX comments - not HTML ones. HTML usually is "<!--COMMENT-->"
### Planner Response (LLM)
You're right — JSX `{/* */}` comments are stripped at compile time and never appear in the DOM. Need to use actual rendered text nodes instead. I'll render them as hidden `<span>` elements with `style="display:none"` so they show up in DevTools without affecting the UI:
*Edited relevant file*5. What Should the Architecture Be?
This is the question the YouTubers never ask, because their videos end before the architecture matters.
Architecture is the part where you decide how the pieces of your system fit together. How data flows. How writes are coordinated. Who owns what state. What happens when two things try to change the same record at the same time. What happens when the network drops in the middle of a save. What happens at 3x your current scale.
Think of it like LEGO. Anyone can snap two bricks together. That’s not architecture.
Architecture is the moment you sit down with one of those monster 1,500-piece sets, the Millennium Falcon or the Eiffel Tower or the Death Star, and you realize that the outside of the model is the easy part. The hard part is the internal skeleton. The Technic beams running through the middle. The way certain plates have to be locked in a specific orientation seven layers deep so that the entire wing doesn't snap off the first time someone tries to pick it up. The kid who skips the instructions and just starts clicking pieces together by vibe ends up with something that looks great on the shelf and falls apart in their hands the second they show it off to their friend. Every parent who has ever had to glue a $300 LEGO set back together at midnight knows what I'm talking about.
Software is exactly the same. The screens are the outer plates. They're the part the user sees and the part the YouTubers love to demo. But the load-bearing internal structure, the part that decides whether the whole thing holds together when someone actually picks it up and uses it, is invisible from the outside. The AI is excellent at clicking the visible bricks together. It is genuinely bad at building the internal skeleton, because the internal skeleton depends entirely on the question "what's this thing going to need to survive?" And the AI doesn't know what your thing needs to survive.
You do. Or at least, in my humble opinion, you have to.
AI tools are spectacularly bad at this. Not because they’re stupid. They can recite every architecture pattern in every textbook. They’re bad at it because architecture is the part of software engineering that depends on context the AI doesn’t have. Your users. Your edge cases. The weird thing one of your customers does that you can’t talk them out of. The hardware you’ve decided to run on. The future you’re planning for that doesn’t exist yet.
I learned this the hard way in BenchBoard’s first version. An earlier AI session, back when I was using ChatGPT and Codex for prototypes, looked at three screens (managing the roster, setting the batting order, arranging the defensive positions) and confidently generated three database tables, one per screen. It even told me the schema would “work perfectly over time.” That’s a direct quote from the chatbot.
It didn’t. Because in real games, all three of those things change at the same time. A coach swaps a player out, and the batting order has to renumber and the field position has to be filled by someone else, all in the same instant. Three tables meant three writes that could fail independently, leaving the data in an inconsistent state. The number of bugs I fought because of that decision is embarrassing. I eventually consolidated all three into a single atomic record. That refactor took days. It should have been the design from day one. The AI didn’t see it because the AI had never stood on a field at 95 degrees while a parent yelled “PUT HIM IN AT SHORT, COACH.”
This is the part that requires you. The AI cannot architect your system. It can implement an architecture you describe to it, often beautifully, often in a fraction of the time it would take you alone. But the design, the load-bearing structure of the thing, is yours. You either understand enough to design it, or you hire someone who does, or you accept that what you’re building is going to fall over the first-time real users hit it hard.
There is no third option where the AI just figures this out for you. That option does not exist. It is being sold to you on YouTube, and it is fiction.
6. When Do I Actually Touch the Code Myself?
Here is the claim every bad YouTube video makes, in some form: “You won’t have to touch a single line of code.”
It’s a great hook. It’s also a lie for almost every real product.
The truth is more nuanced. For some projects (internal tools, throwaway scripts, simple landing pages, personal utilities) you might honestly never need to touch the code, and that’s fine. The AI can carry the whole thing. If that’s what you’re building, great. Stop reading.
For anything else, anything other people will use, anything with real data, anything you want to look and behave exactly the way you imagined it, you need to touch the code. Not constantly. Not even most of the time. But often enough to know what’s going on, and at the moments where it matters most.
Here’s why, in practical terms:
You’ll save tokens, time, and money. Every time you ask the AI to do something, it has to read the relevant code, understand it, and write a response. The bigger your codebase, the more expensive each round trip. If you know exactly where a bug is and exactly what one-line CSS change will fix it, doing that change yourself takes ten seconds. Asking the AI to find it and fix it might take ten minutes and ten times the tokens. Knowing your own codebase well enough to make small surgical changes yourself is one of the biggest force multipliers there is. Your prompt also matters too. If you tell the LLM, “move X icon 10 pixels to the left”, it will do it — but not after having to search for it, find icon X, make the code changes and hopefully not move other icons or break any layouts that you’ve already beautified.
You’ll catch the bugs the AI buries. Some of the worst bugs in BenchBoard were ones the AI introduced quietly and never flagged. Quick definitions, because if you’re new to this, the terms can be opaque:
A race condition is when two pieces of your code try to change the same data at the same time and whichever one finishes last wins, silently overwriting the other. The app looks fine. The data is wrong. You only notice when something weird happens, like a player showing up at two positions, a score reverting, a setting flipping back. I had one of these in BenchBoard where the same lineup record was being written by two different code paths during a player drag, and whichever HTTP request finished last would overwrite the other one’s work. Took me hours to find.
A localStorage namespacing issue is the kind of bug that only shows up when more than one person uses your app on the same device, which, by the way, is exactly what happens during youth sports when a parent and a coach share an iPad. localStorage is the little chunk of memory the browser uses to remember stuff between visits. If you store data there with generic keys like teamId or settings, two different users on the same browser will trample each other’s data. You log in as User A, then User B logs in, and suddenly User B is looking at User A’s team. The fix is to “namespace” the storage keys, meaning you tag them with the user’s ID so each user’s data sits in its own bucket. The AI didn’t do that. It just used flat keys, and the app worked perfectly for one user and broke silently for two.
A JWT environment bleed is a real fun one. JWT (pronounced “jot”) stands for JSON Web Token. It’s basically a digital wristband your app gives you when you log in, proving you’re who you say you are. Tokens live in your browser. The problem is, if you’re testing your app on localhost (your local development environment) and on your-app.com (your production environment) in the same browser, the wristbands can get crossed. The browser hands a production wristband to your local app, your local app sees a valid-looking token and lets you in, and then half your API calls quietly fail because you’re authenticated against the wrong server. I spent an entire evening thinking my API was broken. It wasn’t. I was logged into the wrong universe.
None of these were the AI’s fault, exactly. They were design choices the AI made without flagging that they were choices. The only way I caught them was by reading the code it had written and asking “wait, why is it doing it this way?”
You’ll learn the codebase that’s being created. This is the part I want every new programmer reading this to internalize. The codebase the AI is generating for you is, in a real sense, a free education. It is a working example of a real production system written in your stack, doing exactly the thing you wanted to build. Reading it, actually reading it, is one of the fastest ways to learn how software is built in 2026.
The YouTubers who tell you that you don’t have to look at the code are robbing you of the single most valuable byproduct of working with AI tools. You can come out of a six-month build either with a working app and the same skills you started with, or with a working app and the skills of a mid-level engineer. The difference is whether you read what the machine is writing.
You don’t need to memorize every line. You don’t need to write everything from scratch. But every few days, pick a file the AI just generated, open it, read it line by line, and ask the AI to explain anything you don’t understand. That habit alone will separate you from 90% of the people watching those tutorial videos. Even better, if you don’t feel like reading the whole damn thing, tell the AI to write solid comments for each class, API, etc. and summarize what each of those things do.
You can even highlight some of the code and write “Explain what this code snippet does and leave a comment explaining what it’s for”. Just by that alone it helps you and it helps the LLM from hallucinating because it will help with your judgement when you need to add future features or make changes to your app.
7. Am I Willing to Learn All of This?
Now the honest question. The one no salesperson asks.
If you’ve read this far and you’re thinking, “okay, this is more than I bargained for, I just wanted to build an app this weekend,” that’s a totally legitimate reaction, and it has two legitimate answers.
The first answer: scope down. Build the simplest version of the simplest possible thing. Use AI tools the way they actually work well, for prototypes, internal tools, things where it’s okay if it breaks. Have fun. Build something useful for yourself or for ten people. There’s nothing wrong with that, and the AI tools are a genuine miracle for that use case.
The second answer: hire someone who’s done this before. If your idea is real, if your validation is strong, if you genuinely need a production-grade product that handles real users and real data, AI coding tools will not get you there alone. They will get an experienced builder there faster, which is what they’re for. They are an accelerator for someone who already knows where they’re going. They are a very confusing GPS for someone who doesn’t.
There’s a third answer, which is the one I picked: commit to learning the craft. Use the AI as a tutor as much as a tool. Read the code it writes. Ask it to explain its decisions. Push back when something feels off. Sit with the discomfort of not understanding something and stay with it until you do. You will become a real engineer through this process, faster than any traditional path, if you treat the AI as an apprenticeship rather than a magic wand. But of course, I have decades of experience. And while that seems daunting it really isn’t, even for new people. AI bridges that gap between my decades of experience down to months — if you’re really willing to learn.
But you have to want it. Nobody can want it for you. And no YouTuber with a $499 masterclass is going to give it to you in a weekend.
Dear YouTubers
You have the production value. You have the audience. You have the platform.
You also have, in many cases, a real talent for presenting things. You’re charismatic on camera. You’ve mastered the rhythm of a fifteen-minute video. Your thumbnails convert. Your motion graphics are clean. Your delivery is confident enough that a person who doesn’t know any better will trust whatever you say next.
You are using that skill to be opportunistic. Let’s not dance around it. The incentives in this space are too easy, the shortcuts are what people want to hear about, and the affiliate checks clear whether or not the audience builds anything real. You found the cheat code. Make a slick video. Pick whichever tool is paying out. Tell people they don’t need to learn to code. Slip the link in the description. Pitch the masterclass. Repeat.
Maybe some of you genuinely don’t know any better. Most of you do. And for the ones who do, who know full well that the audience walking away from your video is about to spend a year of their life building something that will collapse the first time it hits real users, what you’re doing is a kind of theft. Not of money, though there’s plenty of that too. Of time.
But most of all — confidence.
Of the years a new programmer could have spent actually learning the craft if someone had been honest with them on the way in.
Cashing in is one thing but when you’re pretending to teach people how to build real things. But misleading others into thinking that the tool can take care of everything is the problem — no matter how nice the b-roll is.
The audience watching you is may or may not know what they’re getting themselves into. They’re mostly new. There’s a difference. Pull up the comments on any of those videos and you’ll see the other half of the story: a waterfall of people who genuinely don’t know what they’re looking at, agreeing with each other in real time, reinforcing the majority view, and walking away from the video knowing less than when they arrived because they’ve now had their bad assumptions validated by a thousand strangers. That’s the part that should bother you. Your comment sections are a feedback loop where ignorance gets louder, not corrected. You could fix that with a sentence or two of honesty in every video. Most of you choose not to.
The version of this content that would actually help them isn’t harder to make. It’s just less flattering to the tools. And maybe there’s a real fear in losing the affiliate contract.
But there’s a better way. Show the bugs. Show what happens when the AI generates the wrong architecture. Show the moment where you have to open the file yourself and fix a CSS class because the AI keeps rewriting the wrong component. Show what it looks like when the AI is wrong, and how you knew it was wrong. That’s the content people need. That’s the content that builds careers instead of selling courses.
You don’t have to stop using affiliate links. You don’t have to give up the production value or the thumbnails. You just have to tell the truth about what these tools actually are and what they actually require. And maybe you have to pick a different affiliate — once you realize which companies are the actual good ones.
There are people doing this right. Unfortunately, they are a dime a dozen but they’re definitely out there. You just have to look.
Please be one of them.
And to the person reading this who's about to start building
You can do this. You'll just find that there are videos that don't tell you the whole story about what it actually takes to build something real. But at least you have these things you’ve subscribed to. That said, there’s a good chunk of people out there who believe in the same thing.
Stay tuned. There’s a lot more to come if you’re interested in taking the dive.
If this piece resonated, subscribe. I write about building BenchBoard in public, about what AI coding tools actually do well and where they actually fail, and about the gap between how this stuff is sold and how it actually works. Next up in the BenchBoard series: Part 4, where we talk about the day my printer died in the middle of a live game and I learned that hardware is software's most underrated dependency.