How I Rebuilt This Site With AI in a few hours

This site used to be a Hugo blog. The theme was fine, the posts were fine, but the stack didn’t let me build the parts I actually wanted: a smart-home dashboard, an interactive chat about me, things that needed React and a real component model.

I rebuilt it in a few hours. Hugo → Astro 5 + React 19 + Tailwind, plus access-restricted dashboards backed by serverless functions. I wrote almost none of it by hand. The whole thing was shaped through conversation with an AI assistant.

Some of that experience surprised me. This post is what I learned.

What I actually did

The starting point was a hugo.yaml, a PaperMod theme, a content/posts/ directory, and a few custom shortcodes. The end state was an Astro site with React islands, a content collection for posts, Tailwind for styling, and serverless functions for the gated parts.

The migration roughly looked like this:

1. Scaffold an Astro project with the right integrations.
2. Port the content collection (posts) and rewrite the schema.
3. Recreate the layout (homepage, post page, navigation) as Astro components.
4. Add interactive React components for the dashboards and chat.
5. Wire serverless functions for the API proxy.
6. Tune typography, dark mode, syntax highlighting.

I drove all of it from a chat window. I described what I wanted, the AI proposed code, I reviewed and edited, we iterated. For most of those few hours the loop was: state the next thing I want, read the diff, run it locally, react.

Where AI actually saved me time

A few categories where the leverage was real:

• Boilerplate scaffolding. Setting up Astro integrations, Tailwind config, content collection schemas, TypeScript path aliases, all the fiddly setup that takes an afternoon if you’ve never done it. The AI knew the current versions, the right imports, the conventions. I would have spent hours just reading docs.
• Layout-by-description. I’d describe a UI (“a terminal-style frame with three colored dots and a path”) and get a working component. Iterating visually was faster than writing the JSX from scratch.
• One-shot conversions. Migrating frontmatter, rewriting Hugo shortcodes as React components, converting CSS rules between conventions. Mechanical work that’s tedious to do by hand and reliable to do with AI.
• Stack questions. “Does Astro 5 still need this thing?” “What’s the idiomatic way to do X with the new content collections API?” Faster than searching, and the answers were usually right.

The thing that stood out wasn’t any single moment, it was the cadence. Normally a side-project rebuild dies somewhere around the third yak-shave. With AI in the loop, the yaks shaved themselves. I stayed in flow.

Where it didn’t help (and where it hurt)

Not everything worked. The categories that needed real attention:

• Anything stateful or specific to my setup. AI doesn’t know my Cloudflare config, my DNS, my actual content. The first attempt at the serverless function got the auth shape wrong. Fine, normal, but the AI’s first suggestion looked confident and wrong.
• Subtle CSS bugs. “Make this card look like X.” The AI would produce something that mostly looked like X but had a layout bug at a specific viewport. Debugging that visually is still on me.
• Outdated patterns. Astro changed its content collections API between major versions. Half of the suggestions I got initially were for the old API. I had to call that out explicitly, and even then a couple of code paths slipped through.
• Over-eager rewrites. Ask for a small change and sometimes get a refactor of the surrounding file. You have to read every diff carefully or you’ll accept changes you didn’t want.

The pattern is consistent: AI is great at things that have lots of public examples and clear conventions. It struggles with things that depend on context only I have, or with new APIs that the public web hasn’t caught up on yet.

The skill is review, not generation

The interesting realization is that the bottleneck moved. Generating code became cheap; reviewing it became the thing that mattered. You’re reading more code per hour than you ever did, and your judgment is what keeps the codebase coherent.

A few habits that helped:

• Read every diff. Not skim. If you can’t explain what changed and why, don’t accept it.
• Push back on shape. When the AI proposes a structure that doesn’t match the existing conventions, say so. Otherwise you end up with three different patterns in the same file by the time you’re done.
• Commit small. Each “feature” I asked for got its own commit. If something went wrong, I could revert one piece without losing the rest.
• Have an opinion. AI will happily generate whatever you describe. If you don’t have a clear preference about state management, naming, file structure, it’ll pick something. That something will be a coin flip.

The flip side: the AI is not your code reviewer. It will write code that runs. It will not always write code that’s good. The “is this the right abstraction?” question is yours.

What I’m fascinated by

The thing that keeps me coming back is the pace. The model I used a year ago could not have done what the current one did in a few hours, not in scope, not in quality, not in how naturally the conversation flowed. Anyone working in this space sees the floor moving up every few months.

I also like that AI lets me build the kind of thing that wasn’t worth building before. A custom personal site with smart-home integration and a chat widget is a lot of code. As an afternoon project it would have been laughable two years ago. Now it’s reasonable. The bar for “worth it” has dropped, which means the set of things I’ll actually ship has grown.

Practical takeaways

If you’re thinking about doing something similar, a few things I’d do again:

• Pick the stack first, deliberately. Don’t ask the AI “what should I use?”. Pick the stack you want, then ask the AI to help you with it. Otherwise you’ll end up with whatever the AI defaults to, which won’t be what you’d have chosen.
• Have a working example to point at. “Make it like Astro’s blog starter, but with this layout” is a much better prompt than “build me a blog.”
• Keep a real local dev loop. The faster the inner loop (save → see result), the more iteration you can afford.
• Trust your gut on architecture. The AI is excellent at filling in implementation. It’s mediocre at high-level design. Do the architecture yourself.

The site you’re reading was built this way. It’s not perfect; I can already see things I’d change. But it exists, and it does what I wanted, and it took a few hours. That trade-off is hard to argue with.