The tech influencer demo took five minutes. Your project is taking weeks. Both are real. Only one of them is the whole story.
The clip is always the same. A developer sits down, types one sentence into an AI tool, and two minutes later a fully functional app appears on screen. The influencer leans back. “That’s it,” they say. The comments flood in. This changes everything. Everyone takes note of the tool name. Nobody asks what happened next.
What happened next is usually three weeks of prompting, confusion, broken state and a credit card bill that surprised them.
You are not imagining things. The demo was real. But the demo showed you something the influencer built before recording. A simple project, already scoped, already thought through, sometimes already partially built. They pressed record for the final five minutes. You saw five minutes. They want you to believe the whole project took five minutes.
This is the gap nobody talks about. Let’s talk about it.
Fireship’s “The vibe coding mind virus explained” (March 2025) — 3 million views in a month. This is what the hype looked like at peak contagion.
Where This Started and What the Guy Who Started It Actually Said
On February 2, 2025, Andrej Karpathy posted a tweet that got 4.5 million views and became Collins Dictionary’s Word of the Year. He called it “vibe coding.” He described giving in fully to the vibes, barely touching his keyboard, just talking to an AI until things appeared on screen.
Here is the part of the tweet that did not go viral.
Karpathy said it himself in the original post: vibe coding is “not too bad for throwaway weekend projects.” He said the code grows beyond his usual comprehension. He said sometimes the AI cannot fix a bug and he just works around it or asks for random changes until it goes away.
The person who coined vibe coding told you exactly what it was for. Weekend. Throwaway. Not production. Not a full system. A prototype you might delete on Monday.
The influencers took the first half of his tweet and left the second half on the floor. Then they made content about building fully functional systems in one prompt. Some of them built their own audience. Some of them sold courses. Some of them are still posting today.
Karpathy’s full keynote at YC AI Startup School (June 2025): “Software in the Era of AI.” At 14:30 he walks through actually vibe coding a project — and explains where the speedups disappeared.
The Research Nobody Puts in the Thumbnail
July 2025. A nonprofit research organization called METR ran a randomized controlled trial on real developers doing real work. Sixteen experienced developers. Two hundred forty-six actual coding tasks. Projects they had worked on for an average of five years with over a million lines of code.
Before the study, developers predicted AI tools would make them 24% faster. During the study, they estimated they were 20% faster. The objective measurement told a different story: they were 19% slower with AI than without it.
Read that again. The same developers who felt faster were measurably slower. The same tools being sold as 10x productivity boosters were adding time to their work.
And there is a detail buried in the data that explains a lot. Developers accepted less than 44% of AI-generated code. More than half of what the AI produced was reviewed, tested, then thrown away. The time cost did not disappear. It just looked like reviewing instead of coding.
The METR study is not a fringe opinion. It was a rigorous randomized controlled trial, rare in AI research. Developers used Cursor Pro with Claude 3.5 and 3.7 Sonnet, the frontier tools of that period. The methodology was real. The result was inconvenient.
One developer who replicated the study personally found he was 21% slower with AI, mirroring the METR numbers. He then tried to find the productivity boom everyone claimed was happening. He analyzed publicly available data on new apps, website registrations, GitHub project growth. He spent hours on it. He found flat lines everywhere. “Shouldn’t this be going up and to the right?” he said. “Where’s the hockey stick on any of these graphs?”
The Google DORA report from 2024, based on responses from over 39,000 professionals, found that every 25% increase in AI adoption correlated with a 1.5% drop in delivery speed and a 7.2% drop in system stability. Not a boost. A dip.
The MIT Technology Review reported a separate study in 2025 where 95% of businesses that tried AI found zero value in it. Not most. Not many. Ninety-five.
None of these numbers are in the thumbnails.
Here is an example of what is in them instead. YC partners on camera, quoting a startup in their batch claiming a 100x speedup in coding performance compared to the previous month. The analysis of why that number cannot possibly be true is worth the four minutes it takes to watch.
What “Fully Functional System” Actually Means
When a tech influencer demos a “fully functional app,” they usually show you a landing page with some buttons that mostly work, a form that submits, maybe a database that stores a row. It loads. It looks good in a screen recording. That is real. That part works.
A fully functional system for actual use is a different thing entirely.
It handles errors. Every kind of error. The user who submits an empty form, the user who submits 10,000 characters, the user who pastes emoji into a field that expects a phone number. It has authentication that cannot be bypassed with simple tricks. It has rate limiting so someone cannot hammer your API a thousand times per second. It has email verification that actually sends and actually confirms. It has a password reset flow that works. It has logging so when something breaks at 2am you can figure out what happened. It has tests so when you change one thing you know what else broke.
It loads in three seconds not thirty. It works on mobile not just a laptop screen. It works in Firefox not just Chrome. It handles the user who has slow internet. It handles the user who opens it in two tabs. It handles the session that expired three hours ago.
None of this appears in the demo. The demo shows you the best path through a perfect scenario. Production software is the other ten thousand paths.
Microsoft Azure CTO Mark Russinovich said it clearly in June 2025: AI coding tools work well for simple web applications, basic database projects, rapid prototyping. For complex projects that span multiple files and folders where different parts of the code rely on each other, they often break down. He predicted that even five years from now AI would not be independently building complex software at the highest level.
This is the CTO of Azure saying this. Not a skeptic. Not someone with an incentive to downplay AI. Someone who sees the actual results at scale.
What Is Actually Happening With Your $100 Plan
Claude Code Max 5x costs $100 per month. For someone who read that developers are using AI to build full systems in days, $100 sounds reasonable for the tools to do the same.
Here is what you get in practice.
The $100 plan gives you roughly 50 to 200 prompts every five hours, depending on the model and message length. That window resets every five hours, not every day. At the $100 tier, the system automatically switches from Opus to Sonnet at 20% usage. Your budget across Claude Code is shared with your regular Claude.ai usage. Every file attachment, every long conversation, every context-heavy prompt costs more than a short one.
A complex project means long context. Long context means each message consumes more of your allocation. A codebase with fifty files, an active conversation history, attachments for error messages and documentation: each message is expensive. You hit the five-hour wall faster than the numbers suggest.
Then there is the context window problem. The model does not remember your entire project. You have to re-explain. You have to re-attach files. The longer the conversation, the more the model starts working from a compressed version of what you told it, which means it starts drifting from your actual intent. Experienced Claude Code users manage this with the /compact command and regular session restarts. That is not a trick a new user knows. It is not in the demo.
The research site for Claude Code rate limits acknowledges the reality directly: Pro users at $20 per month report 10 to 40 prompts every five hours. Most professional developers doing real work find they need at least the $100 plan. And even then, users hit limits mid-project. Regularly.
One developer building a solo project wrote: “After trying the $100 plan and hitting limits within a week, upgrading became a no-brainer.” He upgraded to $200. That is also a real outcome.
The influencer demoing a full project in one prompt is usually not on the $20 plan. They are sometimes using free API credits from early access. Sometimes they are on enterprise plans. Sometimes the project is small enough that it does not hit limits. They do not show you their billing page.
The Demo Is a Different Kind of Project Than Yours
There is a structural reason demos look easy. The person recording owns the mental model of what they are building. They have already thought through the scope. They know exactly what one prompt needs to contain to produce a working result because they have thought about the result for hours or days before recording.
When you watch the demo and try to replicate it, you are starting from a blank mental model trying to communicate a vague vision to an AI. The AI cannot read what you have not articulated. Vague in, vague out.
This is the specification problem that software engineers have dealt with for decades. The hardest part of building anything is not writing the code. It is knowing precisely what you want. AI does not solve this. It surfaces it faster. When the AI produces something wrong, you discover that you did not know exactly what right looked like.
The developer in the METR study who spent 21% more time with AI described a pattern that will sound familiar: start a task, use AI for what should be a straightforward feature, receive code that technically runs but complicates everything, spend an hour untangling logic that went in a direction you would not have chosen. The AI solved the wrong problem. Or solved the right problem in a way that breaks three other things.
This is not a failure of skill. It is the current state of the technology.
The Security Bill You Did Not Budget For
One cybersecurity firm analyzed Fortune 50 companies and found that AI-assisted developers produced three to four times more code but generated ten times more security issues. Not ten percent more. Ten times more.
These were not minor bugs. Exposed credentials. Privilege escalation paths. Architectural design flaws that could haunt a codebase for years. AI generates plausible-looking code. Plausible and secure are different things.
A developer using vibe coding to build something with user data, payments, authentication, or any sensitive function is building on a foundation that has not been reviewed for security. The AI does not know your threat model. It does not know what your users’ data is worth to someone who wants to steal it. It generates patterns from training data, and training data includes a lot of insecure code.
The influencer does not demo the penetration test.
What Actually Works: The Part They Skip Over
This is not an argument that AI coding tools are useless. They are not. Used correctly, they are genuinely useful for real work.
The correct use looks different from the demo.
Define precisely what you are building before you start prompting. Write it down. Not a paragraph, a specification. What does each screen do. What data goes in, what comes out. What happens when something fails. The more precisely you can articulate the system, the more precisely the AI can build a piece of it.
Build in pieces. One component at a time, tested and understood before you add the next. Do not ask for a full system. Ask for the authentication module. Review it. Ask for the database schema. Review it. Ask for the API route. Review it. Each piece you understand becomes context you can actually verify.
Use AI where it is genuinely fast: boilerplate, repetitive patterns, documentation, converting a design to markup, writing tests for logic you already understand. These are places where AI output is reviewable and the cost of a mistake is low.
Keep your context clean. Start new sessions for new problems. Use /compact before context gets bloated. Describe the full current state at the start of each session instead of relying on the AI’s compressed memory of an earlier conversation.
Read the code. This sounds obvious. It is not practiced. The METR developers who were accepting less than 44% of AI output were doing the right thing. They were reviewing. The ones who accept all and move fast are the ones who discover three weeks later that their codebase is a set of contradictions they cannot debug.
The actual productivity gain from AI is real. The studies that show gains tend to find them in greenfield projects, unfamiliar codebases, tasks that are slightly outside the developer’s comfort zone, documentation and boilerplate. These are gains worth having. They do not look like building a full system in one prompt.
What to Do With the Week You Have Already Spent
If you have been at this for a week and the project is not done, the answer is not a better prompt. The answer is a clearer specification.
Stop and write down exactly what the system needs to do. Every screen. Every user action. Every edge case you know about. Every piece of data that needs to be stored. Write it like you are handing it to a contractor who knows nothing about you and will build exactly what you wrote. Then break it into the smallest deployable pieces you can. One piece at a time, with tests, with review.
The $100 plan is not a magic budget. It is a tool budget. Like any tool, it performs well when you know exactly what you are using it for and poorly when you are using it to solve a problem you have not defined.
The influencers are not lying in the sense of fabricating results. They are showing you their best five minutes and framing it as the whole story. The whole story includes the hours of planning before the recording, the scope constraints that made the project small enough to demo cleanly, the prior experience that lets them write a prompt precise enough to produce something usable.
The full video is much longer. Now you know what is in it.