"Vibe coding" is the most searched term in developer circles right now. Every conference talk, every dev Twitter thread, every newsletter. I've been doing it for about a year — before it had the name — and I want to give you an honest picture of what it actually looks like in practice, including the parts that went wrong at 11pm on a Thursday when a client's site wasn't behaving in production.
The project: a premium furniture studio in Santacruz West, Mumbai. Homepage, collections page, about, contact, a simple enquiry form with email notification. Client needed it live for a launch event in 5 days. We agreed to start Monday, launch Thursday.
Hour 1 — The build (what the success story version leaves out)
I opened my Next.js starter template, cloned it, and briefed GitHub Copilot agent mode. The brief was specific: "Create a Hero component for a luxury furniture brand. Full-screen image background with a centered headline, subheadline, and two CTAs. The image should use Next.js Image with fill and object-cover. Mobile: headline font-size 2.5rem, desktop: 4rem. CTA buttons in off-white and transparent outlined."
Output: mostly correct. The responsive font sizes came back as arbitrary Tailwind values I'd need to check. The Image component was missing the required parent container with relative positioning and explicit height — a classic Next.js Image mistake that AI tools make often. I caught it in review, fixed it in 30 seconds.
This is the vibe coding workflow at its most typical: the AI produces 85–90% correct output, you review and patch the 10–15% that's wrong or suboptimal, move to the next component. Faster than writing from scratch. Not zero-review.
By the 90-minute mark I had all the pages built, the mobile layout was solid, the contact form was wired to an API route, and the Contentful integration for the collections was done. I deployed to a Vercel preview URL and shared it with the client for review.
What broke in production (the part nobody tweets about)
The client approved the preview. I pushed to the production domain Thursday afternoon. The launch event was Friday. Three things broke:
The OG image: The collections page was generating OG meta images using Next.js's built-in OG image generation. It worked perfectly in the Vercel preview environment. On the production domain, the OG image URL was returning a 500 error. Root cause: the OG image route was using a local font file path that resolved correctly in the preview environment and incorrectly on the production build. This was AI-generated code using a pattern it had seen in training data — a pattern that's subtly broken in certain deployment configurations. I found it in 20 minutes, fixed it in 10.
The contact form email: The enquiry form was posting to an API route that called Resend to send email notifications. In preview: worked. In production: the email was being sent but landing in spam for the client's Gmail account. Not a code error — a DNS/email reputation issue. The From address was using a no-reply address on a subdomain with no SPF record. Took 30 minutes to diagnose and fix the DNS records. Nothing the AI did wrong — infrastructure, not code.
The collections grid on mobile Safari: The furniture collections grid used CSS grid with a specific auto-fill pattern. It looked correct on Chrome mobile, iOS Chrome, and Android Chrome. On iOS Safari — the default browser for approximately 35–40% of Indian iPhone users — the grid was collapsing to a single column regardless of viewport width. Root cause: a Safari-specific CSS grid behaviour difference. The AI-generated CSS was standards-compliant but didn't account for the Safari implementation gap. Fixed with an explicit grid-template-columns override for Safari using a -webkit- prefixed rule.
What I've learned about vibe coding after a year
The advantages are real and the speed gains are substantial. Building scaffolding, boilerplate, and standard components with AI is genuinely 3–5x faster than writing them manually. The time I save in the build phase I reinvest in better testing and more thorough review.
The failure modes are predictable once you know them: environment-specific issues that don't surface in development (deployment configuration, DNS, API keys); browser compatibility issues in Safari and older Android WebView; race conditions in async code where the AI generates correct logic for the happy path but not for edge cases; and security issues where the AI generates functional code that doesn't properly validate input or sanitise output.
The skill shift: being good at vibe coding is not just knowing how to prompt — it's knowing enough about the underlying technology to review the AI's output confidently. A developer who can't read and understand the code the AI generates is navigating blind. The floor for safe vibe coding is "I can read this and catch what's wrong," not "I can output this from memory."
How I test vibe-coded code before it ships
The production failures I described above could have been caught before deployment with a slightly more rigorous testing approach. Here's what I've added to my post-build routine specifically because of vibe coding:
Cross-browser check before every client share: Chrome, Safari mobile (the biggest divergence from Chrome mobile), and Firefox. Not a full QA suite — I'm checking in browser DevTools' device mode, not real physical devices for most projects. But iOS Safari is genuinely different enough from Chrome that skipping this check guarantees mobile Safari issues on any CSS-heavy project, especially grids and animations.
OG and meta tag verification with open graph debuggers: I use opengraph.xyz to check every key page's OG image renders correctly before deployment. The OG image stack (especially Next.js ImageResponse routes) is the single most common source of production-only failures in my vibe-coded projects. Takes 5 minutes, finds roughly 30% of production-specific issues.
Form submission end-to-end test in the production environment: I literally fill in the contact form and check my email. Sounds basic. But the number of times I've handed over a site with a silently broken contact form — because the API route worked in development but the email provider rejected keys in production — is embarrassing enough that I now do this every single time, not just on builds I'm uncertain about.
Security review for any API routes: every API route the AI wrote, I manually review for: is user input being validated before use?, is the database query parameterised (no string concatenation with user input)?, is the response returning more data than needed? AI tools are getting better at this but still generate SQL injection vulnerabilities in tutorial-style code and return excessive data in API responses. Takes 15 minutes to review, saves significant problems.
The meta lesson: what you save in build time with vibe coding, re-invest partly in testing. The failure modes are different but they're not fewer. A 3-hour build that takes 45 minutes to test properly is a legitimate productivity gain. A 3-hour build that ships untested with production failures is a productivity loss disguised as a win.
Version control habits with vibe coding — non-negotiable
One discipline that vibe coding absolutely requires if you don't have it already: commit often, with descriptive messages, before every significant AI-generated change block.
The failure mode: you instruct the AI to refactor a component, it makes sweeping changes across six files, the result doesn't work, and you don't have a commit to revert to. You're now debugging AI-generated code across six files without knowing which of the hundreds of changes introduced the problem. I've watched junior developers spend 3–4 hours in this situation. It's avoidable with a 10-second git commit before each AI work session.
My approach: commit before every AI session that's longer than a small fix. Descriptive messages: "pre-refactor: auth flow working, before AI restructure". Revert is one command if things go wrong. This sounds obvious and was already good practice before AI tools. It's more important now because the surface area of AI-generated changes is much larger than manual changes.
Also read: Stop memorising syntax — prompting is the real skill now and How I build full client websites in under an hour.