Building a Personal Website with Multi-Agents and Antigravity

July 18, 2026

A few months ago, my personal website was a simple Go server (web2) running on Google Cloud Run. It did everything in one place: rendered Markdown files into HTML templates, served static assets, and sent emails whenever someone left a message on the contact form.

It worked fine, but it felt overly heavy for what was mostly a static site. Every time I wanted to update an article or adjust a CSS tweak, I had to redeploy the whole Go binary to Cloud Run. I decided it was time to decouple things: split the frontend into static pages deployed on Cloudflare Pages, and keep the backend focused strictly on light API endpoints.

Instead of building all of this by hand from scratch, I decided to test out Google Antigravity and a multi-agent workflow to do the heavy lifting.

Moving Away from the Monolith

The original setup had a simple file structure: a few Go files handling routes, a templates/ folder, and markdown files stored in content/.

When I started the migration, I wanted to change two main things:

  1. Frontend: Move to Astro 4 with Tailwind CSS. Static Site Generation (SSG) means zero client-side JavaScript by default, super quick page loads, and free hosting on Cloudflare Pages triggered automatically on git push.
  2. Backend: Strip down the Go server to just handle API calls like /api/contact, deployed to Cloud Run under api.yichen.io.

How the Multi-Agent Setup Worked

Instead of prompting an AI to dump a wall of code and hoping it worked, I used Antigravity’s multi-agent workflow with process plugins like superpowers. This allowed me to split up the work between specialized subagents:

  • Frontend Subagent: Handled the Astro scaffolding, created BaseLayout.astro and ArticleLayout.astro, migrated all Markdown posts, and built the layout for pages like /games.
  • Backend Subagent: Extracted the contact form logic from the old Go monolith into a clean standalone API under backend/, using standard library HTTP routing and Gmail SMTP.
  • Testing & Verification Subagent: Wrote Go unit tests (handlers_test.go) for the API handlers, testing edge cases like missing email fields, honeypot spam checks, and CORS preflights.

My role was mostly reviewing design decisions, setting project rules, and approving code changes before they hit the repo.

The Realities: What Broke and How We Fixed It

Using agents doesn’t mean everything works on the first try. Here are a couple of actual bugs we hit during the rebuild:

1. The CORS Issue

As soon as the Astro frontend was deployed on Cloudflare Pages (yichen.io), submitting the contact form failed. The browser was blocking requests to api.yichen.io because the Go server didn’t handle HTTP OPTIONS preflight requests properly.

The agent checked the request logs, spotted the missing headers, and added a proper CORS handler in backend/handlers.go to explicitly allow requests from the frontend domain.

2. Keeping the Style Simple

Initially, the agent suggested a dark theme with complex dashboard widgets and glowing command palettes. I asked it to dial it back: keep the clean light theme, use simple card layouts, and focus on fast readability rather than flashy gimmicks.

The Final Architecture

Here is how the website is set up today:

  • Frontend Repository: Built with Astro 4 & Tailwind CSS. Pushing to main triggers a Cloudflare Pages build, serving static HTML globally via CDN.
  • Backend Repository: A small Go service containerized with Docker and deployed to Google Cloud Run, mapped to api.yichen.io.
  • Contact Form: The frontend sends a JSON POST request to api.yichen.io/api/contact, which validates the honeypot field and sends an email via Gmail SMTP.

Thoughts on Building with Agents

Writing code with a multi-agent system feels very different from traditional coding or simple chat prompts. Instead of fighting with boilerplate or writing repeatable glue code, I spent most of my time thinking about architecture, edge cases, and user experience.

It didn’t replace the need to understand how web applications, Go, or DNS work—but it made going from idea to a clean, tested production setup dramatically faster.