I’ve seen this firsthand: Vibe coding fails when you can’t tell the difference between a "best practice" on paper and real-world experience. Real experience means factoring in all the trade-offs, from speed and cost to safety, and making the pragmatic choice, which even the best models can’t do. Here are some examples: 1. Data migrations. The model proposed a fleet of parallel cloud functions and new insert endpoints, adding endpoint, invocation, logging, and telemetry costs. The database was the bottleneck anyway, so a single remote server would have been enough. An agent could run the migration script there, detect unexpected data formats, update the script, and continue migrating as it encountered edge cases. It would have shipped and run twice as fast at half the cost. 2. Database constraints. Models love putting every business rule and enum constraint in the database. That sounds robust, but it can make shipping painfully slow. Every new enum value or business rule change becomes another database migration. Application-level validation is usually enough. Otherwise, monitor for inconsistencies and alert. 3. Missing variables. Models often add fallback values when an environment variable is missing. It keeps the app running, which feels convenient, especially during local development. But if infrastructure forgets to set a required variable or uses the wrong name, the app can silently run in development mode. The safer behavior is to fail loudly at startup so the deployment will halt. Knowing how to code matters because you need to recognize when the model’s "best practice" is wrong and override it.