Vibe coding is useful and fast. Nearly a quarter of the YC W25 batch apparently has codebases that are almost entirely AI-generated. This is a giant leap in speed and capability. But there is a point of no return. This is a problem when software has to process real customer transactions, handle credentials, maintain payment channels or survive live attacks. That boundary becomes an asset, with major obligations, code that no one in your organization truly understands. Legacy code is code that you depend on that you can no longer safely explain, change, or defend. If code isn’t verified after it’s generated, then it’s legacy code before it even ships.
Understanding sets the limit
The shift is popularly referred to as the “spectrum of comprehension” in the classic Val Town essay. On one side you have deep understanding, where you get every line. At the far end of the spectrum you have vibe coding where you write very little yourself and understand even less what’s going on under the hood.
Simon Willison says there’s a hard line between coding with AI assistance and pure vibe coding. The real value of AI in programming is when you actually review, test and master every bit of the implementation generated by an LLM. You are vibe coding when it looks like it’s working. AI is a powerful assistant if you own the system and understand its limitations. If you are just guessing that those boundaries are there, you are shipping pure luck.
Production makes ownership unavoidable
This is really a simple software idea at its core. This is often quoted online, e.g. in the HN discussion about vibe coding, where Peter Naur’s point that programming is not about producing lines of text is quoted. Programming is the art of building a human theory of how a system works. It’s the mental model that allows a developer to debug a critical bug under pressure at 2 a.m., ship major changes without breaking nearby behavior or explain security models to an auditor. Replace understanding with a vibe code and you can get working files but no internal theory. That's fine for quick-and-dirty but risky in production.
The only way you own a system is production. Some code paths deal with real transactions. Some deal with customer identities. Some get handed off to next year’s engineering hires. Someone has to own them. There's a great story in another HN thread that shows the exact boundary. A founder coded a complete working SaaS app, launched it and demonstrated that there is real demand from real users. But no one owned the system and production fell apart. Attackers hit the system with XSS injections, a user list leaked, and a Stripe key was obtained and used to refund customers. The prototype proved the product was worth it. The mistake was to run a validated prototype as a live service, without real ownership.
Generation is cheap; ownership is not
The math of development is changing fast. Average code is almost free to write, but the same human effort is required to verify and own that code.
According to Sonar’s 2026 State of Code survey, AI now writes 42 percent of committed code and developers believe it will reach 65 percent by 2027. But a staggering 96% of those developers say they do not fully trust what the AI is producing, and only 48% say they always verify the output before committing it.
The absence of verification is in line with studies of security. Veracode’s benchmark testing shows nearly 45 percent of the AI-generated code samples have security issues. LLMs have gotten shockingly good at generating running code. But security improvements are lagging behind. A 2026 update indicated syntax compilation rates had leapt to 95 percent since 2023, but security pass rates were in the 45 to 55 percent range. The code is cosmetically correct but it is not the code you want to have.
This tension creates a lack of confidence. According to the most recent Stack Overflow 2025 Developer Survey, 46 percent of developers don’t trust the accuracy of AI, up from 31 percent last year. Only 29 percent trust AI outputs to be accurate, down from 40 percent in 2024. In other words, developers are using more AI, but they have less trust in it.
Tests only help when the code is understood
You could say that vibe-coded software is covered by a robust test suite. If you give your AI high quality automated tests and it writes application code, you should be able to edit and refactor it forever. But tests are only as good as the person who interprets their meaning. If you don’t understand what the test guarantees, or you just generate superficial tests with some other LLM and discard them when they break, then you haven’t solved the ownership problem. Good tests are a form of documentation. They show intent. Tests without human understanding are just a black box testing a black box.
Similarly, people argue that AI can just explain its own code when things go wrong. AI can quickly summarize files, or suggest bugs to fix, but a human has to check that the explanation is actually correct, not just a plausible hallucination. Ultimately, the developer has to decide if a change will keep the company's business rules in effect and not hurt other areas.
AI works when ownership stays human
AI-powered development is a great upgrade. It lets us build, test and ship faster than ever before. But the breakdown is never about the tools, it’s about process, incentives and the illusion that we can skip the cost of verification. Vibe coding is a valid phase for experiments, wild ideas and fast validation, but when your creations start to interact with real money, real customer identities, real production systems, the vibes have to stop. We have to stop just passively consuming and start validating what we ship and start owning the code we run to make sure systems are safe and maintainable.
What I'm building
Delegate tasks. Get software.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.comI respect your privacy. Unsubscribe at any time.