# Vibe Coding Is Real. So Is the Bill. > Vibe coding is great for prototypes. The research on speed, code quality, security and junior jobs shows what it costs later, and the 8 skills that pay it. - Author: Tai Pham Phu - Published: 22 Oct 2026 - Tags: Vibe Coding, Software Design, Career, AI Coding - URL: https://phamphutai.com/2026/10/22/vibe-coding-is-real-so-is-the-bill/ On 2 February 2025, Andrej Karpathy posted a short note on X about a new way he was writing software. He called it **"vibe coding."** He described talking to Cursor's Composer by voice, asking for small changes like halving the padding on a sidebar, and clicking "Accept All" every time. He said he no longer read the diffs. When an error appeared, he pasted it back in with no comment, and usually that fixed it. In his words, you "forget that the code even exists." It was a funny, honest post. It was also careful in a way most people skipped. Karpathy wrote that the code grew "beyond my usual comprehension," and that this approach was "not too bad for throwaway weekend projects." Within weeks, "vibe coding" had become the name for a whole movement. Tools like Cursor, Claude Code, Copilot, Lovable and Replit let people who had never written a loop ship a working web app in an afternoon. That's real, and it's wonderful. Then, eight months later, Karpathy released nanochat, a small but complete project for training a ChatGPT-style model. Someone asked how much of it the AI had written. His answer, on 13 October 2025: it was "basically entirely hand-written (with tab autocomplete)." He said he had tried Claude and Codex agents a few times, but on that codebase they "just didn't work well enough at all and net unhelpful." Same person. Same tools. Two very different kinds of work. That gap is what this series is about. --- ## What vibe coding is actually great for I want to be clear before the rest of this post sounds like a warning. I use AI coding tools every day. I've led teams and reviewed a lot of code, and I would not go back to writing everything by hand. Vibe coding, in the strict sense of "accept everything, don't read it," is a great fit when **the cost of being wrong is close to zero**: - **Prototypes and demos.** You want to see if an idea feels right before you invest in it. If the code is ugly, you throw it away. - **Personal tools.** A script that renames your photos. A page that tracks your gym sessions. If it breaks, you're the only one affected. - **Exploring something new.** Asking for a working example in a library you've never touched is a fast way to see what's possible. - **UI fiddling.** "Make this button bigger." "Try a darker header." The result is visible the moment it runs. - **Glue and boilerplate.** Config files, a first draft of a CRUD page, a test scaffold. What these have in common: **you can see whether it works just by looking at it**, and nobody else depends on it. The trouble starts when the same habits move into work where neither of those is true. Customer data. Payments. Logins. Anything with users you've never met, running at 3 a.m. when you're asleep. In that world, "it runs" is the start of the question, not the answer. --- ## Why it feels faster than it is The most surprising piece of evidence about AI coding isn't about bugs. It's about how we judge our own speed. ### The METR study (July 2025) In early 2025, the research group METR ran a randomized controlled trial with **16 experienced open-source developers** working on their own projects. These weren't toy repos. They averaged over 22,000 GitHub stars and over a million lines of code. The developers brought **246 real issues** from their backlogs, each about two hours of work. Each issue was randomly assigned: AI tools allowed (mostly Cursor Pro with Claude 3.5 and 3.7 Sonnet) or not allowed. The result: - Before starting, the developers **predicted AI would make them 24% faster**. - With AI allowed, tasks actually took **19% longer**. - After the study, the developers **still believed AI had made them about 20% faster**. Read that last line again. Experienced engineers, timing their own work, felt faster while being measurably slower. ### The update (February 2026) METR has since marked those results as out of date, and it's worth being fair about why. In February 2026, it published an update on a larger follow-up that started in August 2025 (57 developers, 143 repositories, over 800 tasks) using late-2025 tools. The new point estimates pointed to a speedup, not a slowdown: about 18% faster for returning developers and about 4% faster for new ones. But the confidence intervals crossed zero, and METR said the study had broken down in an interesting way. Many developers no longer wanted to work without AI at all, and 30% to 50% of those surveyed said they were holding back some tasks because they didn't want to do them by hand. METR called its new data "only very weak evidence" for the size of the improvement and said it was redesigning the experiment. So the honest summary, at the time of writing (October 2026), is: **the tools have probably got faster, nobody has measured by how much, and our gut feel is a poor stopwatch.** That last part is the lesson for you. If you can't tell whether a tool is speeding you up, you definitely can't tell whether the code it wrote is correct just by how good the session felt. --- ## What happens to the code Speed is only half the bill. The other half is what the code looks like six months later. ### More copying, less cleaning (GitClear, 2025) GitClear, a company that sells code analytics tools, analyzed **211 million changed lines of code** written between 2020 and 2024, from its customers and open-source projects. As AI assistants spread, it found: - **2024 was the first year copy-pasted lines outnumbered "moved" lines.** Moved lines are a sign of refactoring: someone reorganizing code so it can be reused. - The number of **code blocks with five or more duplicated lines rose about eightfold during 2024**. - Moved lines fell by about **40%**. Two caveats. GitClear sells tools that measure this, so it has a reason to find a problem. And the data is correlational: it shows code changing as AI tools spread, not proof that AI caused each change. But the pattern matches what I see in code review. An assistant that only sees a few files will happily write a fresh `formatPrice()` instead of finding the one that already exists. Duplicated code runs fine. The cost shows up later, when you fix a bug in one copy and the other three keep it. ### Security holes by default (Veracode, July 2025) Veracode, an application security company, gave **more than 100 language models 80 coding tasks** in Java, JavaScript, Python and C#, each with a secure and an insecure way to solve it. Its report, published 30 July 2025, found: - In **45% of cases**, the model chose the insecure option and introduced a vulnerability from the OWASP Top 10 (the industry's standard list of the most common web security flaws). - Java was the worst, with a security failure rate **over 70%**. The other languages were between 38% and 45%. - Models failed to defend against cross-site scripting in **86%** of relevant tasks and log injection in **88%**. - Newer and bigger models wrote more code that compiled, but **were not better at writing secure code**. The code worked. It just also let someone else in. ### Developers know it (Stack Overflow, 2025 and 2026) The people using these tools every day are not naive about this. In Stack Overflow's 2025 Developer Survey (about 49,000 responses, fielded in May and June 2025): - **84%** used or planned to use AI tools. - But more developers **distrusted** the accuracy of AI output (46%) than **trusted** it (33%). Only about 3% "highly" trusted it. - The top frustration, picked by **66%**, was "AI solutions that are almost right, but not quite." - **45%** said debugging AI-generated code takes more time. The 2026 survey asked the question differently, and the answer is telling: the most common position, at **48%**, was that AI is fine to trust **when they can easily validate the answer**. That's the whole series in one statistic. AI output is trustworthy in proportion to your ability to check it. --- ## What happens to the people This is the part that matters most if you're early in your career. Economists at the Stanford Digital Economy Lab (Erik Brynjolfsson, Bharat Chandar and Ruyu Chen) used payroll data from ADP, the largest payroll provider in the US, covering millions of workers. Their paper, "Canaries in the Coal Mine?", first came out in **August 2025** and found: - Workers aged **22 to 25** in the most AI-exposed occupations saw a **13% relative decline in employment** after generative AI spread, even after controlling for company-level shocks. - For **software developers aged 22 to 25** specifically, employment by July 2025 was down **nearly 20% from its late-2022 peak**, while older developers' employment kept growing. The authors revised the paper in **August 2026** with data through June 2026. Young workers in AI-exposed jobs now sit **19% below** where they'd be if they had kept pace with less-exposed peers. Experienced workers show no comparable gap. The effect comes mostly from **fewer young people being hired**, not more being fired. The authors are careful, and so should we be. They call these "early, descriptive indicators," not proof that AI caused the drop. The pattern weakens when you control for education, and some trends started before ChatGPT. It does hold up when they exclude tech companies and control for interest rates, but they still stop short of calling it cause and effect. But one finding is hard to ignore: the declines are concentrated in jobs where AI **substitutes** for the work, while jobs where AI **complements** the worker are flat or growing. Put plainly, the junior work that's disappearing is the work an AI can do on its own: write the first draft of a feature from a clear ticket. The work that's holding up is the work that needs judgment about what the AI produced. **If your only skill is prompting, you're competing with the tool. If you can read, debug, secure and ship what it writes, you're the person the tool needs.** --- ## The bill, drawn Here's how I think about it, as someone who has reviewed a lot of code and now builds with these tools daily.
time and size of the project total effort spent the bill arrives fast start vibe only bugs, breaches, rewrites AI + skills gentle slope Throwaway prototype? Stop before the crossing. Vibe coding wins here.
An illustration, not measured data: vibe coding is cheapest early, and the extra cost of reading and checking pays off once a project lives long enough.
Vibe coding wins the first week. It often wins the first month. If the project dies before the crossing, vibe coding was the right call. But real products don't die on schedule. They get users, then data, then a payment form, then a second developer. Somewhere along the way, the bill arrives, and it comes in a few familiar shapes: - **The bug nobody can find**, because nobody understands the code well enough to know where to look. - **The breach**, because a database was left open or a secret was shipped to the browser. I collected a few real cases in ["Built With AI in a Weekend": What Happened Next](https://phamphutai.com/2026/10/22/built-with-ai-in-a-weekend-what-happened-next/). - **The migration that eats data**, because the schema was never really designed. - **The change that breaks three other things**, because there were no tests to say so. - **The rewrite**, because adding one more feature to the tangle costs more than starting over. None of these are new problems. Software teams have been paying these bills for fifty years. What's new is how fast you can now run up the tab. --- ## The 8 skills this series covers Each skill below is one that vibe coding lets you skip. Each one has its own post, with a real story, plain explanations, short code examples, and a practice routine you can do **while still using AI every day**. 1. **[Reading code](https://phamphutai.com/2026/10/22/you-cant-fix-what-you-cant-read/).** The core skill. If you can't read what the AI wrote, you can't review it, fix it, or explain it. How to trace a request through a codebase you've never seen. 2. **[Debugging](https://phamphutai.com/2026/10/22/debugging-when-the-ai-is-out-of-ideas/).** What to do when pasting the error back stops working. Reproduce, shrink, guess, test, and `git bisect`. 3. **[Security](https://phamphutai.com/2026/10/22/security-holes-ai-writes-every-day/).** The handful of holes AI writes again and again, and how to spot them in a diff. 4. **[Data](https://phamphutai.com/2026/10/22/data-outlives-code/).** Your code will be rewritten. Your data won't. Schemas, migrations, backups and the decisions that are hard to undo. 5. **[Tests](https://phamphutai.com/2026/10/22/tests-are-how-you-talk-to-the-ai/).** Tests aren't paperwork. They're the clearest spec you can give an AI, and the only proof its change didn't break something. 6. **[Architecture](https://phamphutai.com/2026/10/22/from-prompting-to-architecture/).** Where code should live, what should talk to what, and how to keep a codebase that an AI (and a human) can still work in after a year. 7. **[Shipping and running software](https://phamphutai.com/2026/10/22/shipping-is-half-the-job/).** Deploys, logs, monitoring, rollbacks. Getting it live is half the job. Keeping it alive is the other half. 8. **[The roadmap](https://phamphutai.com/2026/10/22/junior-developer-roadmap-2027/).** How to put the seven skills together into a plan for getting hired, and staying valuable, as a junior developer in 2027. You don't need all eight before you build anything. You need them roughly in that order, and you need to start on the first one now. --- ## How to use AI while you build these skills The good news: the same tools that let you skip these skills are excellent teachers, if you use them that way. Anthropic ran a small randomized study in January 2026 with 52 mostly junior developers learning a new Python library. The group using AI scored lower on a follow-up quiz than the group coding by hand, with the biggest gap on debugging questions. But how people used the AI mattered more than whether they used it. The participants who asked it conceptual questions, or asked for explanations alongside the code, scored about as well as the hand-coders or better. The ones who handed everything over, or kept pasting errors back, scored lowest. I'll come back to this study in the next two parts. So the habit to build is simple to say and hard to keep: - **Before you accept code, explain it.** If you can't say in one sentence what a function does, ask the AI, then check its answer against the code. - **Predict before you run.** Guess what will happen. Then run it. Every wrong guess is a lesson. - **Write one piece by hand each day.** A small function, a query, a test. Then ask the AI to review it. You learn more from its review of your code than from reading its code. - **Read the diff, every time it matters.** Not for the CSS tweak. Always for anything touching data, money, logins or permissions. - **Keep a "things I didn't understand" list.** Each item is tomorrow's ten-minute study session. --- ## A quick self-check Pick the project you're most proud of building with AI. Can you answer these without asking the AI? - [ ] Where does a request from the browser first enter the code? - [ ] Where is user data stored, and who can read it? - [ ] Which secrets (API keys, database passwords) exist, and where do they live? - [ ] If the database disappeared tonight, how would you get it back? - [ ] If a user reports a wrong number on their screen, which file would you open first? - [ ] Is there a test that would fail if someone broke checkout or login? - [ ] How do you know if the app is down right now? If you ticked all seven, you're already past vibe coding. If you ticked two, you're normal, and the rest of this series is for you. --- ## Key ideas - **Vibe coding is real and useful** for prototypes, personal tools and exploring. Karpathy himself called it fine "for throwaway weekend projects." - **We misjudge our own speed with AI.** METR's 2025 trial found experienced developers 19% slower while believing they were 20% faster. Newer tools are probably faster, but the data is weak. - **AI-assisted code shows more duplication and less refactoring** (GitClear), and **insecure choices in 45% of security-relevant tasks** (Veracode). - **Developers trust AI output when they can check it.** That makes checking, which means reading, the core skill. - **Entry-level hiring in AI-exposed jobs has fallen** (Stanford, 2025 and 2026), most where AI substitutes for the work rather than complements it. - **The bill comes later**: bugs nobody can find, breaches, lost data, rewrites. The eight skills in this series are how you pay it down. *Sources: Andrej Karpathy's [vibe coding post on X](https://x.com/karpathy/status/1886192184808149383) (2 February 2025) and his [nanochat reply](https://x.com/karpathy/status/1977758204139331904) (13 October 2025). METR, ["Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) (10 July 2025; [arXiv 2507.09089](https://arxiv.org/abs/2507.09089)) and ["We are Changing our Developer Productivity Experiment Design"](https://metr.org/blog/2026-02-24-uplift-update/) (24 February 2026). GitClear, [AI Copilot Code Quality 2025 research](https://www.gitclear.com/ai_assistant_code_quality_2025_research), as reported by [DevClass](https://devclass.com/2025/02/20/ai-is-eroding-code-quality-states-new-in-depth-report/) (20 February 2025). Veracode, [2025 GenAI Code Security Report press release](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/) (30 July 2025). Stack Overflow [2025 Developer Survey, AI section](https://survey.stackoverflow.co/2025/ai) and [2026 Developer Survey, AI section](https://survey.stackoverflow.co/2026/ai). Brynjolfsson, Chandar and Chen, ["Canaries in the Coal Mine?"](https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recen) (Stanford Digital Economy Lab; first version 26 August 2025, revised [August 2026](https://digitaleconomy.stanford.edu/news/canariesaug26/)). Anthropic, ["How AI assistance impacts the formation of coding skills"](https://www.anthropic.com/research/AI-assistance-coding-skills) (29 January 2026).* *Related: next in the series, [You Can't Fix What You Can't Read](https://phamphutai.com/2026/10/22/you-cant-fix-what-you-cant-read/), the series finale [The Junior Developer's Roadmap for 2027](https://phamphutai.com/2026/10/22/junior-developer-roadmap-2027/), and ["Built With AI in a Weekend": What Happened Next](https://phamphutai.com/2026/10/22/built-with-ai-in-a-weekend-what-happened-next/).*