Rebuilding my homepage with Claude Code

My old homepage was a Hugo Blox academic template I set up in 2025 and then mostly ignored. When I finally looked at it again, it was in worse shape than I thought. Over a few sessions in October 2026 I rebuilt it from scratch with Claude Code. This post is a record of how that went and what I would do the same way next time.

Where I started

I opened by asking Claude Code to check the project and the live site and tell me whether they were in sync. The audit was more useful than I expected:

• The live site had not been deployed since August 2025.
• My local environment could not build it at all — the theme needed an older, “extended” Hugo than the one installed.
• Template demo content was still public: sample blog posts, a teaching page, project pages, and a resume.pdf that turned out to be Lorem ipsum.
• Small but embarrassing bugs: the GitHub icon linked back to the homepage itself, a “Read Thesis” button pointed to example.com, and a NeurIPS entry was an empty placeholder.

I wanted more than a fix. I wanted a personal site, not just an academic one: a blog, English and Chinese, and comments that readers can leave without a GitHub account.

Plan first, then design, then code

I asked for a plan before any code, and I approved it explicitly. That turned out to be the most important habit of the whole project. Each decision — framework, URL structure, how languages are chosen, where comments live — got settled in plain language before anything was written.

A few decisions that shaped the site:

• Astro instead of a theme. Every page is my own code, so a future framework update cannot quietly break the build the way the old theme did.
• Bilingual by device language. English by default; visitors whose browser prefers Chinese land on /zh/, and the EN/中 switch remembers an explicit choice. I write both language versions of a post myself — I tried the idea of automatic translation and decided I would rather own the wording.
• Comments on my own server. I didn’t want readers to need a GitHub login, so comments will run on a small self-hosted service. That part is the next step.

For the design, I asked for three mockups before building anything real. I picked one, changed its colors, then changed my mind completely and asked for something closer to apple.com.

Why Apple? Simply because I think Apple has good taste — clean layouts, generous whitespace, type that does the work — so I borrowed its style. I hope Apple’s taste stays this good for a long time, so I can keep borrowing from it. To be fair, Claude’s own interface has good taste too, and I like it a lot.

Show, don’t describe

“Make it look like Apple” got me a decent first pass. What actually got it right was sending screenshots: a support page with white cards on a gray background, a product page with a large title on white and dense content on gray, a list that used plain text instead of boxes. Each screenshot fixed something that a paragraph of adjectives would not have. The current layout — introduction on white, information-dense content in a gray band of white cards — came directly from one of them.

The same applies to small things. “This title is too big” or “remove this line, it looks unprofessional” are fast, concrete corrections, and iterating on them is cheap. The favicon went from my initials, to a waveform, and back to my initials in a few minutes.

Let it verify, and check the facts

Two things made me trust the result more.

First, Claude Code tested its own work: it built the site, opened pages in a browser, checked phone widths, and fixed what it found. One bug was subtle — the automatic language redirect sent local previews to the live site instead of staying on the same host. Another was an article page that came out wider than a phone screen, forcing sideways scrolling.

Second, the content is grounded in sources. Publication details were checked against Crossref rather than typed from memory. At one point it filled in two patent co-authors’ full names from initials; it then checked Google Patents, found both guesses were wrong, and corrected them. That episode is the best argument I know for asking an agent to look things up instead of trusting what sounds plausible — and for reading what it writes about you before you publish it.

Guardrails worth keeping

Some moments where slowing down was the right call:

• Deleting files. When it came time to remove the old Hugo files, the safety check in auto mode blocked the deletion. Claude Code stopped, explained what it wanted to do, and gave me the exact command to run myself.
• Private information. My full CV includes a phone number. The public cv.pdf is compiled from a copy with the number removed, and the PDF’s text and metadata were checked before it went on the site.
• Memory across sessions. Decisions such as the color palette, the bilingual rules, and where the server details live are saved, so a new session does not have to rediscover them.

What I would tell myself next time

1. Ask for an audit before asking for changes.
2. Agree on a plan in words, and approve it, before any code is written.
3. Look at mockups before building pages.
4. Send screenshots, not adjectives.
5. Ask it to verify facts against real sources, and read every claim about yourself.
6. Keep destructive or public actions — deleting, publishing, sharing personal data — as your own decisions.

The site is now built with Astro, deployed to GitHub Pages by a GitHub Action, and written in Markdown and YAML that I can edit by hand. Comments are coming next. If you spot something broken, email me.