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.
How I Vibe-coded My Blog
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 as a Headless CMS 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: Fixing AI Hallucinations in Next.js 15
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: How to Stop AI From Hardcoding API Keys.
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 independently 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.tsxwas 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.tsto explicitly whitelistcdn.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.










Top comments (31)
I don't trust AI. It once destroyed my entire codebase/.
I think the idea is to gently guide the AI/agent you're using, and not just giving them direct, unmonitored access to an entire code base.
I didn't give it access but it was just uncommitted files where the agents added a hell lot of files, and my initial code broke!
Oh my. That must have been a lot to fix.
yes!
use CLI tools like Codex -- it won't run without a git repo (so you can always go back)
codex is shit. 🙂
lol i know that -- but it's good for a couple of use cases (maybe not vibe coding)
which cases?
anything local. personally I use it to understand complex codebases .. very accurate and works well
Why did it fail in my case? It just provides a superficial overview, which, as a developer, you're not interested in.
it might need detailed prompts and what things you want .. otherwise it would give you an ultra trimmed version (which is so bad)
indeed!
I think vibe coding works as long as you approach in the right way -- like system prompts, in-depth guidelines and verifying everything. for most of my projects, I have used AI to figure out the best architecture/project structure before starting (at the very least, it gives me a direction).
for 90% of use cases (which are not hardcore engineering projects), vibe coding works tbh. I trust perplexity cuz I have pro version and can see the sources clearly :)
(finally found time to read this -- I have a habit of opening in a tab and forgetting lol)
Thank you for taking the time to read it.
I am not really a core software dev/engineer, so a lot of the best practices to expect are lost on me.
But this is the most seamless vibe coding experience I have had so far.
I used Gemini. 3 (pro) to achieve this.
I vibe coded my current portfolio, and it looks great. Https://eunit.me
Broooo, this is so cool!
Thank you @dumebii . Here is a technical piece detailing how I built it: eunit.me/blog/building-a-modern-di...
Woah. This is really cool. I enjoyed reading it.
I still got a lot to learn. 😅
I don't know if this makes me excited or anxious 😅
Fantastic piece btw
😅😅 It's giving "AI is coming for your job."
Fr 🥲😅
Very interesting. Commenting here to get notifications for other people's opinions.
I'm waiting too! 🤞
I would have liked to get a look at your code base, to sufficiently verify the grade of the code written.
I'd share the GitHub Repo link when I'm done with the entire project.
Good post, but for "professional" software engineering practices, I would have expected even more, including static code analysis beyond linters, unit tests, continuous builds with some integration test, and emotional discussions about clean code patterns during merge requests. Because that's what you do with juniors. And that's what I do with AI code generators.
I'm not a software engineer. And all the times I tried to be one, I failed so badly at it; especially when it came to testing.
It's something that I'm learning is a necessary part of building anything.
I used to believe that "once it works, then it's okay."
But, I will share these updates with you in coming articles.
What made me understand better what good code is was reading and watching what Uncle Bob (Robert C. Martin) has produced. It is full of wisdom. And currently I come to the conclusion that it still holds even in the ages of code generation.
I am curious about your upcoming articles - keep them coming :)
Thank you!
I'd also check out Robert C. Martin.
I find that AI is very good at achieving fancy things with very simple ingredients. I have been a pro developer for over 15 years. When I specify a new AI project, I use Django, HTML, Bootstrap and vanilla JavaScript. I once vibe-coded a huge React mess that had to be rewritten. TO be fair, I am not good with react and did not know how to get the project back on track.
What I found:
No "build" processes (no node, C#)
No dependencies unless very specifically required (like for writing .pdfs)
All styling done within Bootstrap.
Django is an opinionated framework, but AI loves Python and "knows" how to use Django well.
Use text data files as long as possible. Instead of a database of "categories," just make a plain text file and tell AI to use it as an array.
Then transition to SQLITE if necessary.
Use tech that you understand as much as possible. (don't use Firebase for the first time in an AI project)
Remind AI to use "best practices."
Ask AI to summarize what it did in a documentation.md file.
With plain JavaScript and HTML, you can do anything on the front end. React, TypeScript, jQuery and Vue are essentially wrappers for JavaScript. They are also far slower than native JS. I am consistently amazed by how quickly JS can sort, move, build, etc.