AI coding tools are genuinely impressive. They can scaffold an application, write complex logic, and produce clean, readable code faster than most engineers. The problem isn't the code they write. It's the code they can't write, because nobody told them what they were actually building.
What AI doesn't know about your product.
When you prompt an AI to build a feature, you give it a description. What you don't give it is everything that surrounds that feature in the real world.
Regulatory requirements
If you're building in fintech, your payment flows need to comply with AFSL obligations, AML/CTF requirements, and in some cases open banking standards. If you're in health, there are strict rules around how patient data is stored, accessed, and shared. If you're building for enterprise, your customer's procurement team will eventually ask for an ISO 27001 report or a security questionnaire you can't answer.
AI builds what you describe. It doesn't build for the regulatory environment you're operating in, because you didn't put that in the prompt, and even if you did, it doesn't have the contextual understanding to translate it into architecture decisions.
Third-party integration requirements
Every major payment provider, identity verification service, and enterprise API has specific implementation requirements. Stripe has webhook signature verification patterns. Xero has OAuth flows with specific scoping requirements. Some government APIs in Australia require client certificate authentication.
AI generates a plausible integration. It doesn't necessarily generate the correct one. The difference only surfaces when you try to go live or when something fails under conditions the demo never hit.
Your specific business logic
Your pricing model has edge cases. Your user roles have exceptions. Your data has constraints that aren't obvious from the schema alone. This knowledge exists in your head, in Slack messages, in a Notion doc nobody has updated in six months.
AI builds from what's in the prompt. The institutional knowledge of how your product actually works: the exceptions, the edge cases, the things that are "everyone just knows that". None of it is in the prompt.
Enterprise and B2B requirements
If you're selling to businesses rather than consumers, your buyers will have requirements your B2C-oriented prototype doesn't meet: SSO integration, audit logging, role-based access control, data export, SLAs. These aren't features you add later. They're architectural decisions that need to be made early, because retrofitting them into a system that wasn't designed for them is expensive.
Why this matters more than it used to.
Ten years ago, the gap between a developer-built prototype and a production system was mostly about polish and performance. The core architecture was usually sound because a human engineer had made deliberate decisions about it.
Vibe-coded prototypes skip that deliberate decision-making step. The architecture is whatever the AI defaulted to based on the prompt. For many products in many industries, that default is fine. For anything operating in a regulated environment, serving enterprise customers, or handling sensitive data, it usually isn't.
The question to ask.
Before you scale or raise, it's worth asking: does anyone actually know what constraints this system needs to operate under, and has anyone verified the code meets them?
That's not a code review. It's a context review. Understanding the gap between what was built and what the environment requires.
Often the gap is smaller than expected. Occasionally it isn't. Either way, knowing is cheaper than finding out when it matters.