Dusting off the room because it has been a minute or two since I was in here last!

Through last year, I ran a lot of vibe-coded projects. Most were for writing demos, others were simply for the fun of it. However, with each new vibe-coded project, I kept getting super frustrated and super stuck with debugging AI’s badly written (spaghetti) code.

"Vibe Coding" has been the trend of the moment. The idea to me was basically, "Describe your app in plain English, and the AI handles the syntax." This was the approach I kept using that kept failing until now.

Why Vibe Coding is Ineffective

VIbe coding is ineffective because most people treat AI like it’s magic. They ask it for a feature, paste the code, and hope for the best. Usually, they get a messy file structure, insecure code, and a maintenance nightmare. The application might work on localhost, but it lacks the rigor required for the real world.

The Goal I wanted a technical blog that was "up to standard and safe." Coming from Wordpress, where I built my blog (The Handy Developer’s Guide) and lived on for the better part of a year and half, I wanted a platform I could own completely, built with modern engineering standards.

The Solution I didn’t just ask the AI for code; I managed it. I adopted the mindset of a Senior Architect and treated the AI as my junior developer. By enforcing strict constraints and architectural patterns, I used vibe coding to build a secure, production-ready application. The image below is where I started with Gemini. But it gets better down the line.

Steps to Vibe Code a Production-Ready App

Step 1: Defining the Architecture of Your Project

Before writing a single line of code, I had to define the stack. A standard AI prompt might suggest a generic React app or a rigid site builder. That was not enough.

The Decision I chose a Headless Architecture:

• Frontend: Next.js 15 (App Router)

• Backend: Sanity (Headless CMS)

• Styling: Tailwind CSS (v4)

Why I used Sanity to Build My Blog

Separation of concerns is critical for long-term survival. With this architecture, I own the code, and I own the content.

• Portability: If I want to change the design next year, I don’t lose my posts. They live safely in Sanity’s database.
• Security: There is no exposed database or admin panel for hackers to target on the frontend.
• Performance: Next.js allows for Static Site Generation (SSG), meaning my pages load instantly, together with Sanity.

Key Takeaway I did not let the AI pick the stack; I picked the stack, then told the AI how to build it.

Step 2: The "System Prompt" Strategy

The quality of the output depends entirely on the constraints of the input. I didn’t just say, "Make a blog." I assigned a role and a standard.

The Trick I used a "System Prompt" strategy to set the ground rules before any code was written.

The Prompt

The idea was to have one tab of Gemini 3 acting as the senior developer/project manager, while another tab acted as the engineer/dev on ground. So, I got tab A to give me the high-level prompts after already explaining i=to it its role.

The Result The AI didn’t dump files in the root directory. It set up a professional folder structure (lib/, components/, types/) and automatically created a .env.local file for credentials. By explicitly banning any types, the AI was forced to write interface definitions for my Post and Author schemas, preventing runtime crashes later.

Step 3: The "Schema-First" Build

Initially, I spun up a standalone Sanity Studio. I quickly realized this created redundancy—I didn’t want to manage two separate projects. I directed the AI to refactor the architecture, merging the CMS directly into the Next.js application using an Embedded Studio. This is how we managed it.

The Result I had a working CMS living at /studio before I even had a homepage. This allowed me to write and structure content immediately, giving the frontend real data to fetch during development.

Step 4: Using AI to Fix the Errors it Generated

AI is not perfect. Even with a great prompt (I’d know), "hallucinations" happen. I had to do my fair share of debugging, but they were more minor than I remember vibe-coded errors to be. We hit two major roadblocks.

Bug 1: The Route Group Conflict I moved my layout files into a (blog) route group to organize the code (this was totally my choice, by the way; even though the Project Manager tab suggested it, it said it was optional). Suddenly, "the internet broke." In my terminal, I got error messages about missing tags.

• The Issue: The AI had created a layout hierarchy where the root layout.tsx was missing the essential <html> and <body> tags because I had moved them into the child group.
• The Fix: We refactored the hierarchy. I established a "Root Layout" for the HTML shell and a "Blog Layout" for the Navbar and Footer.

Bug 2: The "Broken Image" Saga The homepage rendered, but every image was a broken icon. The URL looked correct, but the browser refused to load it.

• The Issue: I already knew this was a security feature, not a bug. Next.js blocks external images by default to prevent malicious injection.
• The Fix: I didn’t panic. I just checked the configuration. I prompted the project manager tab to update next.config.ts to explicitly whitelist cdn.sanity.io. One server restart later, the images appeared.

The Lesson AI writes the code, but you have to check the config. And sometimes, you just have to turn it off and on again.

Step 5: Refining the UI in a Vibe Coding Project (current phase)

Design We moved from a sort of skeleton UI to a professional UI. We implemented a "Glassmorphism" navbar with a blur effect and switched to a high-quality typography pairing (Inter for UI, Playfair Display for headings).

How to Check If Your Blog is Up To Standard

SEO "A blog that doesn’t rank is a diary," said someone really famous. I had the AI to implement Dynamic Metadata. We used the generateMetadata function to automatically pull the SEO title, description, and OpenGraph images from Sanity. Now, every link shared on social media looks professional.

Analytics I wanted to know if people were reading, but I didn’t want to invade their privacy, so we integrated Vercel Analytics, a privacy-friendly tracker that gives me the data I need without the cookie banners users hate.

The Proof I ran a Google Lighthouse audit on the production build to verify our "Senior Architect" standards. The results spoke for themselves:

• Accessibility: 100
• Best Practices: 96
• SEO: 100

My project manager assured me that this was a good score, especially seeing as my blog is not yet live. Getting it live will increase the score.

Conclusion:

I haven’t launched the blog yet because I still have some work to do on it. I haven’t properly tested it yet. Having been writing articles recently on Playwright, I have learnt how to do extensive searches, simulating different browser and network conditions. In due time, though, the blog will be launched. I wrote this article because I wanted to share an update on one of the things I have been working on so far and how AI has helped me.

Let me know what you think of my journey so far. Do you have any Vibe coding best practices? Do you think I am wasting my time and should learn actual programming skills?

No matter your opinions, we want to hear them!!

Find me on LinkedIn.