From Hugo to Nuxt: Why I Switched to Vibe Code My Blog

Last year I was running this blog on Hugo. It was fine. Hugo is fast, reliable, and battle-tested. I have nothing bad to say about it. But over time, I kept running into a wall. I wanted to be able to spice things up a bit with theming, animations/transitions and other features I didn't know I wanted (looking at you RSS feed). I found myself fighting the framework rather than building with it because of this.

Over the last year I tried the vibe code my new blog on various occasions. The last time was October 2025. Although it brought me further, I still was correcting a lot of output. But then Opus 4.6 (and now Sonnet 4.6) hit the market. What a difference, everything changed. I wanted to try it again. With this website as a result.

What "Vibe Coding" Actually Means to Me

I want to be clear about what I mean by vibe coding, because it gets thrown around a lot. For me, it is not about blindly pasting AI output and hoping for the best. It is about having a fast, creative back-and-forth with a model where I describe what I want, in plain language or by pointing at code, and the model helps me realize it. I stay in control. I understand what lands in the codebase. But the friction between "idea" and "working thing" drops dramatically.

For that to work well, I wanted a framework that has a lot of online presence and the model knows deeply. Hugo is a niche static site generator. It has its own templating language, its own directory conventions, its own quirks. When I asked a model to help me extend something in Hugo, I spent a lot of time correcting misunderstandings. The model knew Go templates and Hugo's data pipeline at a surface level, at best.

Vue and Nuxt? The models know those inside out. Every pattern, every composable, every Tailwind class. The conversation just flows a lot better.

Why Nuxt Specifically

I considered a few options. Next.js was an obvious candidate since React is everywhere and models are very strong with it. But I have always preferred Vue's approach to component design. The single-file component format, the reactivity model, the way templates stay readable. It suits how I think.

Nuxt builds on Vue and fills in everything you need for a real content site: file-based routing, server routes, auto-imports, a content layer built around Markdown. It is not a toy framework. Companies ship production applications with it. That maturity matters, because it means the patterns I learn and the things I build are not throwaway experiments. They are transferable.

The Nuxt Content module in particular was the deciding factor. My posts are Markdown files, and they always will be. Nuxt Content treats them as a first-class data source. I can query posts, filter by tag, sort by date, and render MDC components inside Markdown, all without reaching for a CMS or a third-party API.

The Migration

Migrating the actual content was straightforward. Hugo and Nuxt both expect Markdown with YAML frontmatter, so my posts moved over without changes beyond a few field name adjustments.

The real work was building the site itself: the layout, navigation, search, tag pages, and RSS feed. And this is exactly where vibe coding paid off.

In Hugo it would cost me a lot more time. In Nuxt, I described what I wanted, iterated in short loops with AI assistance, and had something I was proud of within a weekend. Not every suggestion landed perfectly. There were moments where I needed to read the Nuxt docs or dig into how a composable actually worked. But that is a healthy part of the process. I understand this codebase. I just built it faster than I ever could have on my own.

It's true what they say: understanding a language is easier than speaking it. You could say the same about programming languages. I understand variables, arrays, loops, if/else statements. But in every languague you have to get to know the syntax properly before you can start flying. With my Copilot, I found this part to be particularly fast-tracked.

What Changes When You Use a Mature Framework

There is an underappreciated advantage to using a framework with a large ecosystem: the guard rails are already built. Nuxt handles code splitting, hydration, SEO meta, image optimization, and TypeScript out of the box or with a single module install. I do not have to invent solutions to problems that have already been solved a hundred times.

This matters even more when working with GenAI. When I ask for help with something in Nuxt, the model can suggest an idiomatic solution, one that fits the framework's conventions. In a niche tool, the model improvises. In Nuxt, it suggests useAsyncData, definePageMeta, a server/routes/ file. Things that actually exist and work the way they are supposed to.

The result is that my blog is now more capable than it ever was on Hugo. It has live search across all post content, tag filtering, a proper RSS feed, dark and light mode, and responsive design. The code is clean enough that I can keep extending it with confidence. Now the only thing that is missing is... Content.

Exploring GenAI as a Daily Tool

I want to be honest: I am a Cloud Architect by trade, not a frontend developer. JavaScript frameworks are not my primary home. What surprised me most about this project is how much I learned by doing it this way. When the model explained why a particular reactive pattern works in Vue, or suggested a server route instead of a client-side fetch, I paid attention. I looked things up. I built a working mental model.

GenAI is at its best when it accelerates genuine learning rather than bypassing it. If I had just accepted every code block without reading it, I would have a site I could not maintain. Instead I have a site I understand well enough to keep improving, and a framework I am now genuinely comfortable with.

That feels like the right way to use these tools.

My approach was simple:

• Start anew with an empty Git repo.
• Don't let AI build you scaffold: build it yourself following official documentation.
• When I had the starter website working and running, I commit this code. This is now my baseline.
• From here on out I started iterating:
  • First I set the theme colors. Is it to my liking? Commit!
  • Then I started working on the various pages. Commit!
  • Menu bar. Commit!
  • etc.

What's Next

Now that the foundation is solid, I want to keep pushing on what a personal tech blog can be. A few things I am thinking about:

• Reading progress indicator on long posts
• Related posts suggestions based on tag overlap
• Newsletter signup without a third-party service, handled by a Nuxt server route
• Automated post metadata, meaning generating descriptions and reading time during build

All of these are things I would not have touched on Hugo (although provided out of the box) In Nuxt, with good tooling and GenAI on my side, they feel totally within control.

If you are sitting on a static site generator that is starting to feel limiting, I would encourage you to take a serious look at Nuxt. The migration effort is real but manageable, and what you get on the other side is a full-stack web framework backed by a huge ecosystem, paired with the most capable AI coding tools we have ever had. That is genuinely exciting.

Happy to answer questions. Find me on LinkedIn.