Y Combinator reports that 25% of its W25 project has codebases that are 95% AI-generated. This article discusses the real trade-offs: speed vs. technical debt, prototype vs. production, and why senior engineers report development hell. There's a new way of building software that is taking Silicon Valley by storm, and honestly, I've been watching it with a mix of fascination and horror. In February 2025, Andrej Karpathy coined the term "vibe coding," and within weeks, it became the hottest buzzword in tech. By March, Y Combinator reported that 25% of its Winter 2025 batch had codebases that were 90% AI-generated. Twenty-five percent of the most promising startups in the world are shipping products where As someone who has built infrastructure-level software like Sayna, I can tell you that this statistic keeps me up at night, but probably not for the reasons you would expect. What is Vibe Coding exactly? Let me quote Karpathy's original tweet because it perfectly captures the essence of what we are dealing with: It is a new kind of coding that I call 'vibe coding' in which you fully give in to the vibes, embrace the exponentials and forget that the code exists. I 'accept all' in, I don't read the diffs anymore, when I get error messages I just copy paste them in with no comment, usually that fixes it." It is a new kind of coding that I call 'vibe coding' in which you fully give in to the vibes, embrace the exponentials and forget that the code exists. I 'accept all' in, I don't read the diffs anymore, when I get error messages I just copy paste them in with no comment, usually that fixes it." This is coming from a former OpenAI researcher and Tesla AI director who has helped to build some of the most advanced AI systems on the planet is telling us to just... buzz with it. And here's the thing: for throwing away weekend projects as originally described by Karpathy, this actually makes a lot of sense; the problem is that startups took this philosophy and ran it straight into production. The Y Combinator Reality Check When YC's managing partner Jared Friedman announced these statistics, he was quick to clarify something important: these weren't non-technical founders struggling with ChatGPT, but highly skilled engineers who, a year ago, would have built everything from scratch - they chose not to, because AI got good enough. Garry Tan, YC's CEO, put it bluntly: "This isn't a fad. This isn't going away. This is the dominant way to code, and if you are not doing it, you may just be left behind." But here is what caught my attention in this conversation: Tan warned what happens when a startup with 95% AI-generated code hits 100 million users: "Does it fall over or not?" The first versions of reasoning models are not good at debugging; so you have to go into the tatters of what's happening with the product. That's the hangover nobody wants to talk about. The hangover is real Over the past months, I've been watching discussions from senior engineers and CTOs and the stories are starting to pour in: One senior engineering manager at Navan raised a crucial point that most vibe coding discussion misses entirely: "Is AI extending or refactoring features or are it all greenfield projects?" The answer matters more than most people realize: Building something from scratch is fundamentally different from sustaining systems that have accumulated years of tribal knowledge, patterns and yes, technical debt. Here's what is actually happening in production: The Debugging Nightmare: When you don't understand the code you've exported, debugging becomes an exercise in frustration. One disillusioned developer shared: "I was trying to create my little project but every time there are more and more errors... I am working on it for about 3 months but every time I want to change a minor thing, I kill 4 days debugging other things that go south" The Debugging Nightmare The trust debt problem: A software architect described what he calls "trust debt" after a junior developer gutted a user permission system that passed tests, survived QA and successfully launched. Two weeks later, they discovered that deactivated accounts could still access backend tools because of an inverted truthy check that "seemed to work at the time". A senior engineer spent two days debugging the mess. The trust debt problem We're seeing a split in the industry: there are "AI Native Builders" who can deliver features fast but who struggle with debugging, architecture and long-term maintenance; and then there are "System Architects" who understand the implications of technical decisions and can navigate AI-generated complexity. Guess which group is becoming more valuable? Problem: Two Engineers creating the debt of fifty There is a joke making rounds in engineering circles: "Two engineers can now create the tech debt of fifty." It's funny because it is painfully true. Unchecked AI-generated code amplifies technical debt in ways we've never seen before. The joking complaint contains a grain of reality that's crippling engineering teams. The code looks perfect on the surface, but beneath it is what some call "house of cards code" – it looks complete but collapses under real-world pressure. This manifests in several distinct ways: First, inconsistent coding patterns emerge as AI generates solutions based on different prompts without a unified architectural vision and you end up with a patchwork codebase where similar problems are solved in completely different ways. Second, documentation becomes sparse or a nonexistence because the focus shifts to prompt engineering rather than explaining code functionality. The developer who wrote the prompts might understand what they asked for, but actual implementation logic remains a mystery. Third, and this is the scary one, security vulnerabilities creep in at alarming rates: a study found that AI models introduce known security vulnerabilities into code 45% of the time. When you accept all changes without review, you are basically rolling dice on your application's security. Where Vibe Coding Actually Makes Sense I'll be honest, I'm not here to tell you that the vibe coding is evil and should be banned. That would be hypocritical because I use AI assistance all the time in my development workflow. The question is about boundaries. Vibe coding works great for: Prototypes and proof of concepts where you need to quickly validate an idea Weekend projects and experiments where the cost of failure is low Learning new languages and frameworks where the AI serves as an accelerated tutorial Boilerplate code that follows well-established patterns UI components and simple CRUD operations Prototypes and proof of concepts where you need to quickly validate an idea Weekend projects and experiments where the cost of failure is low Learning new languages and frameworks where the AI serves as an accelerated tutorial Boilerplate code that follows well-established patterns UI components and simple CRUD operations Where it falls apart is anything that requires: Deep understanding of system behavior under load Security-critical components handling user data or authentication Infrastructure code where reliability and latency matter more than development speed Complex business logic that needs to evolve over time Real-time processing systems where milliseconds matter Deep understanding of system behavior under load Security-critical components handling user data or authentication Infrastructure code where reliability and latency matter more than development speed Complex business logic that needs to evolve over time Real-time processing systems where milliseconds matter The Infrastructure Exception This is where I have to talk about what we're building: When you work with infrastructure software, the tolerance for "it mostly works" drops to zero; when you're handling real-time voice processing, WebSocket connections or audio streaming, there is no "Accept All" At Sayna we are building a unified voice layer for AI agents, that means handling voice-to-text, text-to-speech, and real-time audio streaming with subsecond latency requirements. Every buffer management decision, every WebSocket message routing choice, every audio optimization has consequences that compound over time. Could I code some of this? Maybe the simpler parts, but the core architecture? The noise filtering pipelines? The provider abstraction layer that needs to switch between Deepgram, ElevenLabs, Google Cloud and Azure without dropping frames? Absolutely not. The reason is simple: infrastructure code is the foundation that depends on the products of other people. When this foundation is built on vibes rather than understanding, everything on top becomes fragile. What Senior Engineers Are Actually Doing Here's the interesting paradox: Senior engineers are getting MORE value from AI coding tools than juniors - the reason is clear if you think about it: Seniors have the knowledge to steer AI correctly and repair its mistakes - they deal AI output like code from a new hire, inspecting every line, ensuring they understand it before it ships. One CTO described the new reality perfect: vibe coding is an excellent method of advancing an idea from 0 to 0.7 but that last 0.3, the part that makes software actually work in production, still requires human engineering. The most successful teams I've seen treat AI assistance like having a super-speedy but junior developer on the team – the AI might crank out the first draft, but a senior engineer still reviews it with a critical eye, refines it and ensures that it meets quality standards. This is why "vibe coding is dying" isn't quite right; what's dying is the fantasy that you can ship production software without understanding what you're shipping. The Irony of Karpathy's latest project In October 2025, Karpathy released a new project called Nanochat. Someone asked him how much of it was AI-generated and his response was: "I tried to use Claude/Codex agents a few times but they did not work well enough and made the net unhelpful." The godfather of vibe coding doesn't trust the technique for his own serious projects, let that sink in for a moment. Building for the Long Term If you're starting today a company or project, here's what I'd suggest: Know Your Boundaries: Use AI support aggressively for prototypes and MVPs, but have a plan for the transition from "vibed code" to "production code". This transition will require engineers who actually understand the systems they are building. Know Your Boundaries Invest in Architecture: The startups that survive the vibe coding hangover will be those who invested from the start in proper architecture: AI can help you write code faster, but it can't help you design systems that scale. Invest in Architecture Build critical infrastructure correctly: For everything that handles user data, processes payment, manages authentication or needs to run 24/7, take the time to build it right. Your future self will thank you. Build critical infrastructure correctly Create learning loops: If you're using AI to generate code, ensure that your team is learning from it, not just accepting it. Developers who understand what AI is producing will be infinitely more valuable than those who don't. Create learning loops For us at Sayna, this means building in Rust for performance guarantees, implementing proper testing, maintaining clear documentation, and designing systems that evolve as the requirements change - it's not as fast as vlogging our way through development, but it's the only approach that makes sense for infrastructure that other people depend on. The future is hybrid The future of software development is not pure vibe coding any more than it is pure manual coding, it's somewhere in between, where AI accelerates development and humans deliver quality. The companies that figure out this balance will win: They'll ship faster than traditional development shops while avoiding the technical debt tsunami that pure vibe coding causes; they'll have engineers who can debug problems because they understand what they shipped; they'll build systems that scale because someone actually thought about architecture. The hangover is real, but it's also avoidable: You just need to know when to stop drinking the AI Kool-Aid and start engineering. If you're building the next big thing and 95% of your code comes from AI prompts, I have one question: do you really understand what you are shipping? Because if not, this hangover is coming. And from what I'm hearing from CTOs across the industry, it's going to be brutal. Don't forget to and share if you find this helpful! and if you are dealing with your team with Vue coding technical debt, I'd love to hear your stories in the comments.
