Vibe Coding a Blog Migration: Ghost to Astro in One Night with Claude Code

10 PM and a Terrible Idea

It’s September 27th, 2025, around 10 PM. I’m trying to update a blog post in Ghost’s in-browser editor. For the third time tonight, I’ve lost my train of thought switching between my code editor and the Ghost admin panel. I’m thinking: “There has to be a better way.”

Then it hits me: What if I just… converted the whole thing to Astro?

Five hours later at 3 AM, I pushed a commit with 87 files changed and 11,614 lines of code. My Ghost blog was now an Astro static site with a cyberpunk theme, custom components, and a deployment pipeline. Memory usage dropped from 1GB to 256MB, dropped the database and persistent storage for good measure. And most importantly: I could finally edit my blog posts in the same environment where I write code.

This is what “vibe coding” with AI assistants looks like. Not blindly trusting the output, but staying in flow while you make the decisions that matter.

Why I Migrated

The breaking point wasn’t Ghost’s features, it was the context switching. Browser admin panel → Ghost editor → VS Code for testing → back to browser → upload images → publish. I wanted to edit posts in the same environment where I write code.

The wins:

• Performance: Static generation = instant loads
• Cost: 1GB → 256MB RAM (75% reduction)
• Workflow: Open file, edit markdown, commit, push, deploy
• Portability: No database, no CMS lock-in, just git

The Process: Vibe Coding with Claude Code

Here’s where it gets interesting. This entire migration happened in one session, and I didn’t write most of the code myself.

What is “Vibe Coding”?

It’s a term that captures the experience of coding with AI assistants like Claude Code, Cursor, or Codex. Instead of:

• Googling error messages
• Reading documentation
• Copy-pasting Stack Overflow answers
• Context-switching between tools

You just… talk through what you want to build. The AI understands your project structure, your existing code, your constraints, and helps you implement solutions in real-time.

It’s not about the AI writing all the code (though it does a lot). It’s about staying in flow state while tackling a complex project.

How It Happened

Five hours from Ghost to production. The workflow: spec the vision, Claude Code asks clarifying questions, we iterate on a plan. Then execute: export Ghost content, set up Astro + MDX, convert HTML to markdown, migrate images, configure Docker + nginx, set up GitHub Actions for auto-deploy. Claude Code maintained context throughout using CLAUDE.md project memory.

The technical stack ended up being: Astro static site generator, MDX for rich content, multi-stage Docker build (Node → nginx), cyberpunk redesign (#ec4899 pink + #a855f7 purple), and push-to-deploy via GitHub Actions.

The Experience: What Vibe Coding Feels Like

The Shift in Workflow

Instead of googling “How do I configure Astro for MDX?” and reading docs, I said: “Set up Astro with MDX support and content collections.” Got working code with explanations. No Stack Overflow, no documentation hunting.

Claude Code understood my project structure, Ghost migration context, design preferences from earlier in the conversation, and deployment setup. When I said “add a Note component,” it knew where to create it, what styling system I was using, and how to export it for MDX.

Design iteration was conversational: “Make these feel more cyberpunk” → gradient borders and glow. “The hover animation is too subtle” → increased glow, added glitch effect. Each iteration took seconds, not rounds of CSS fiddling.

The Flow State

For five hours, I stayed in flow. No context switching, no getting stuck on configuration, no frustration with unfamiliar APIs. Just: building, testing, refining, shipping.

I focused on what I wanted: components, design feel, user experience. The AI handled how: Astro syntax, Docker config, GitHub Actions setup, CSS animations. It felt like pair programming with a senior dev who knows every framework.

What Vibe Coding Doesn’t Solve

But let’s be clear about what this isn’t:

• You still need to know what you’re building. I could specify what I wanted because I’ve built blogs before, deployed to Fly.io before, and understand static site generators. Claude Code didn’t make those architectural decisions. I did.

• AI can generate bad code that looks good. I caught several instances where the implementation worked but wasn’t optimal. A few overly complex components, some inefficient image handling, CSS that could have been simpler. I had to review everything and refactor.

• The debugging gap is real. When something broke, I hadn’t written the code. Understanding what went wrong took longer than it would have if I’d written it myself. You need enough knowledge to debug AI-generated code, which sometimes means understanding it deeply anyway.

• Over-reliance is a risk. I could feel myself starting to trust outputs without fully reading them. That’s dangerous. You’re still responsible for what ships. Bad dependencies, security issues, performance problems: those are on you, not the AI.

• Not a replacement for fundamentals. If you don’t know web development, Docker, or deployment workflows, Claude Code won’t make you productive. It accelerates people who already know what they’re doing. It’s a multiplier, not a replacement.

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

— Tom Cargill, Bell Labs

AI gets you to working code fast. But the ninety-ninety rule still applies. The refactoring, debugging, and polish? Still necessary. The honest truth: this worked because I knew enough to guide it, critique it, and fix it when needed. The AI didn’t make me skilled. It made my existing skills go further.

One Technical Win Worth Sharing

Same day as migration, I added automatic Open Graph image generation. Every blog post now gets a custom OG image with cyberpunk styling: pink/purple gradients, Press Start 2P font, title and description rendered at build time. Zero manual image creation.

This is the kind of thing that sounds tedious (and would have been, five years ago). With Claude Code: “Add OG image generation with the cyberpunk aesthetic.” Twenty minutes later, done.

The Results

By the Numbers

• 5 hours from Ghost to production
• 87 files (11,614 lines of code)
• 9 posts migrated from HTML to MDX
• 1GB → 256MB RAM (75% reduction)
• ~$8 → ~$2/month hosting costs

The Real Win

I actually want to write now. Open file, write markdown (with Claude’s help to refine it), commit, push. Live in 2 minutes. No admin panel, no context switching, no friction.

Lessons Learned

• You’re the architect, AI is the builder. I made every decision about structure, design, and tech stack. Claude Code executed those decisions fast, but it didn’t have opinions about what would work best for my use case. When I was vague, I got generic solutions. When I was specific, I got exactly what I wanted.

• Review everything, trust nothing blindly. I spent the next day refactoring overly complex components, simplifying CSS, and fixing inefficient patterns. The code worked, but not all of it was good. AI optimizes for “does it work?” not “is this the best approach?” You need to catch that.

• Design through iteration still works better. Started with “#ec4899 pink and #a855f7 purple, cyberpunk vibes.” The rest emerged from conversation: “Let’s try an 8-bit font” → Press Start 2P for headings. “What about terminal cursor effects?” → blinking cursor. The cohesive design came from iterating, not from specifying everything upfront.

• The real win is staying in flow. Not the speed (though 5 hours vs. a week matters). It’s that I didn’t lose momentum. No Stack Overflow rabbit holes, no config frustration, no switching contexts. I built something I actually wanted because the friction was low enough to stay engaged.

Try It Yourself

Want to experience this? Pick a small project (portfolio site, blog migration, landing page) and use Claude Code or Cursor. Start with something you understand well enough to judge the output. The iterative approach works best: build one piece, test it, refine it, then move to the next.