I Built a Modern Blog Website Using Vibe Coding

"Vibe coding" has been impossible to avoid the last few months — describe what you want in plain English, watch an AI generate the app, ship it. I'd used AI tools as a coding partner before, mostly for systems-level work in C++, where I'm reviewing generated code line by line anyway. What I hadn't done was hand something a full frontend from scratch and see how much of that same "describe it, review it, steer it" workflow actually held up outside my comfort zone.

So I picked a real project instead of a toy one: my personal blog. Small enough to fully understand end to end, substantial enough that routing, layout, and content structure would actually surface real friction if the tool couldn't handle them.

This is what that process actually looked like — including the parts that didn't just work on the first try.

What Vibe Coding Means to Me

I want to be upfront about the frame I went in with, because "vibe coding" gets talked about two very different ways.

One version treats it like a replacement for knowing how to build software — describe the vibe, get the app, never look at the code. That's not what this was.

The version I actually used treats AI as a fast, very literal collaborator: it can generate a huge amount of working structure from a description, but it doesn't know what "good" looks like for my project, and it doesn't catch its own mistakes. That part's still on me. So in practice:

• I described intent, not implementation details — what the blog should do, not which components to use
• I reviewed what came back before trusting it, the same way I'd review a pull request
• I made the actual architectural calls — what pages exist, how content is structured, what stays out of scope
• I stepped in to fix or rewrite anything that was subtly wrong rather than just "looked" right in the preview

The skill that mattered wasn't typing less code. It was asking clearer questions and knowing when to stop trusting the preview and go read the actual output.

The Idea Behind My Blog

I already write longer technical pieces on dev.to, but I wanted one place that was fully mine — for project write-ups (the kind of deep-dive I did on building a packet sniffer with libpcap) tied directly to how I want to be positioned professionally. The site's tagline sums up the intent pretty directly: Systems Programmer & Security Engineer.

The brief for the blog itself was deliberately narrow: fast, readable, no CMS overhead, nothing that gets in the way of the writing. A blog is exactly the kind of project where the content should be the interesting part, not the platform underneath it — which also made it a fair test case for vibe coding, since I wasn't trying to build something architecturally novel.

The Technologies Used

I built it using Google AI Studio's Build mode, which generates a full React application from a natural-language description. A few specifics about how it actually works, since "vibe coding" tools vary a lot underneath the same marketing term:

• A two-pane interface: a chat panel for describing what you want, and a live code editor + preview pane showing the actual generated project
• An annotation mode that lets you click directly on an element in the preview and describe a visual change, instead of describing "the button in the top right" in words
• A Code tab that shows the real generated source — not a black box, an actual editable React project
• One-click deploy, which is exactly how the site ended up live at a .ai.studio subdomain in the first place

No custom backend — a blog doesn't need one, and keeping that scope small mattered for how well the AI-generated result would actually hold up.

A rough shape of the kind of prompt that kicks off a build like this:

Build a minimal, modern personal blog in React.
Home page: list of posts with title, date, short excerpt.
Post page: full article content, clean typography, no sidebar clutter.
No backend — content should be easy to add as static entries.
Dark, minimal aesthetic. Fast load, no unnecessary animation.

My Development Workflow Using AI

The rhythm ended up being closer to iterative pair programming than "one prompt, done":

1. Start broad — one prompt describing the overall structure and pages, to get a working skeleton fast
2. Iterate conversationally — follow-up prompts to adjust layout, spacing, and typography, using the annotation tool for anything visual instead of describing it in words
3. Actually read the Code tab — periodically stopping to look at what got generated rather than just trusting that the live preview looked right
4. Fix by hand where needed — anything that was subtly off got corrected directly rather than re-prompted into a worse state

[Add here: one specific real example of a refinement loop you went through — e.g. a particular layout tweak, a piece of content structure you had to re-prompt several times to get right.]

Challenges I Faced (and How I Solved Them)

The biggest one wasn't a bug — it was scope. Tools like this are genuinely good at producing a working prototype fast, but the well-documented gap across this entire category (not just this one) is production-readiness: things like persistence, proper error handling, and security hardening aren't there by default. A generated blog looks finished in the preview long before it's actually finished.

Concretely, that meant:

• Treating the first generated version as a draft to review, not a shippable result
• Going through the actual source in the Code tab rather than assuming the preview told the whole story
• Being the one to decide what "done" meant — the tool has no opinion on that, and won't tell you when it's cut a corner

[Add here: the specific challenge or bug you actually hit while building this — what broke, how you noticed, how you fixed it.]

What AI Did Well

To be fair to the tool, a few things about this workflow were genuinely impressive:

• Scaffolding speed — skipping the "blank React project, routing, build config" setup tax entirely and starting from a working skeleton
• Visual iteration — the annotation/click-to-edit flow made small design tweaks fast without hand-writing CSS for every adjustment
• Context retention — it kept track of the whole project across a long back-and-forth conversation rather than losing the thread between prompts, which is where a lot of earlier AI coding tools used to fall apart

For a solo side project, that speed genuinely changed how much I was willing to attempt in a weekend.

Where AI Struggled — and Why Developer Judgment Still Mattered

The flip side of that speed: the tool has no sense of what "finished" means for my specific project. It'll happily generate something that looks complete in a live preview while quietly skipping things a shipped product actually needs — error states, edge cases, the boring-but-necessary parts.

That's not a knock on the tool so much as a description of what it's actually for: fast, high-quality scaffolding, not a substitute for someone who knows what a finished product should look like. Every decision about scope, priorities, and what "good" meant for this specific blog was still mine to make — the prompt doesn't make architectural decisions, it just executes on the ones you've already made, whether or not you've made them well.

• Vibe coding compresses the blank-page problem, not the judgment problem. Getting from zero to something working got dramatically faster. Knowing what "something good" actually looks like didn't get any easier — that part's still entirely on the developer.
• Reading the generated code isn't optional if you're shipping it. The preview can look finished while the code underneath is not.
• Clear, specific prompts beat vague ones, exactly like clear, specific tickets beat vague ones on any team — "vibe" is doing a lot of work in "vibe coding," but specificity still wins.
• The fastest path to a good result is still knowing roughly what good looks like before you start prompting — the tool amplifies direction, it doesn't supply it.

Final Thoughts: Would I Use Vibe Coding Again?

Yes — specifically for this category of project. Personal tools, prototypes, low-stakes frontends where I want to get from idea to something real fast, and where I'm going to review and finish the result myself rather than ship the first output verbatim. I wouldn't treat it as a blanket replacement for writing code by hand, especially anywhere production-readiness, security, or genuinely novel architecture actually matters — that's exactly where the gap between "impressive demo" and "finished product" shows up.

What it did change is how much I was willing to attempt for something like a personal blog, where the writing was always supposed to be the point, not the frontend plumbing underneath it.

If you've tried vibe coding yourself — whether it was AI Studio, or something else entirely — I'd genuinely like to hear how it went for you. What worked, where you had to step in and take over, and whether it changed how you think about your own workflow. Drop it in the comments; I'm curious how consistent this experience actually is across different tools and project types.