Rebuilding a website is easier than you think — my agent did my test site in a couple of days

philwheat.net was built the hard way on purpose: a C#/WebAssembly single-page app talking to Cosmos DB through an Azure Functions API, with Microsoft login for editing. It was a learning project, and it learned its lesson. By mid-2026 the site was effectively invisible — crawlers got a loading spinner and nothing else, no post had a real URL, the built-in web editor was painful, and nothing else in my toolchain could touch it.

The fix took four days, and I wrote almost none of it by hand. My Hermes agent (Hermes Agent, from Nous Research) did the rebuild while I made the decisions. The point of this post is that the same pattern works for any “my old site is a pain” situation, and that re-implementing an existing site is dramatically easier than building a new one, because you already know exactly what it has to do.

Step 1: Have something look at what you actually have

I pointed the agent at the two repos (site + API) and the live site and asked for a review and a plan. What came back was better than an audit — it was a diagnosis:

• curl of a post URL returned a <title> of StaticSiteusingWorkspaces, no meta description, no Open Graph tags, no sitemap, no RSS. Objectively invisible to every crawler and every link preview on every social site.
• The content itself was tiny: 6 posts and 3 interest links in Cosmos. The architecture weighed several orders of magnitude more than the content.
• The audit found real bugs too, including a live Cosmos connection string committed in launchSettings.json — that got rotated first, before anything else.

Lesson one: measure before you mourn. The gap between “my site is a mess architecturally” and “my site is 9 pieces of content” was the whole insight. Migration cost scales with content, not with architecture.

Step 2: One decision does most of the work

The plan boiled down to a single sentence: content becomes files in git; the site becomes a build artifact.

Everything else followed from that. Markdown in a repo means Obsidian, VS Code, git history, and AI agents are all instant editors with zero custom code. A static build means every URL is prerendered HTML — the crawler problem, the link-preview problem, and the “dated feel” problem are solved by the same switch. The web CMS, the API, and the database don’t get replaced; they get deleted, which is cheaper.

Generator choice was Hugo — a single binary, no npm toolchain, first-class RSS/sitemap/taxonomies out of the box. The rule I applied: it has to be a tool I run, not a language I have to stay fluent in.

Step 3: Prove the pipe before you move anything

The plan had an explicit gate that saved the project from the failure mode that killed my previous half-attempt at this: nothing migrates until a curl of a post URL over HTTPS returns full HTML without JavaScript plus a valid RSS feed. Pipeline skeleton first, end to end, on a staging URL. Once the pipe was proven, migration was mechanical.

What the agent actually did

Roughly, day by day:

Monday — surveyed both repos and the live site, ran the audit, wrote the plan, and on my go-ahead built the Phase 1 skeleton: hugo.toml, about 90 lines of hand-written templates (no theme), a small stylesheet, the GitHub Actions workflow, and a 17-check build gate script. Migrated the 6 posts and 3 links out of Cosmos into Markdown with front matter, keeping a cosmos_id field in each for traceability.

Tuesday — hit and fixed the deploy plumbing: the gate script had to resolve paths relative to the repo root and tolerate minified HTML; the Azure-provisioned workflow kept trying to build with Oryx, whose bundled Hugo needs a newer glibc than the runner has, so the agent pinned Hugo itself via peaceiris/actions-hugo and set skip_app_build. Also discovered GitHub Free private repos can’t use branch protection, so the human gate moved to the deploy boundary: pushes and PRs build and preview, but production publish only happens on a manual workflow dispatch. That turned out to be a better design anyway. Wrote the first real automated pipeline: a ~150-line C# exporter that reads my InfoMonitor Postgres and writes daily “what I’m paying attention to” rollups into the repo on a nightly cron — 249 items backfilled on day one.

Wednesday — weekly digest job drafting from the attention rollups (a gate check now forces every URL in a digest to appear verbatim in the source rollups, so an agent-written digest can’t invent citations), the 301 redirect for the old /interestlinks route, DNS cutover at the registrar, and verification that every section served real HTML under the new engine while the old app stayed untouched as a rollback.

Total of my hand-written code across the whole project: zero production lines. Total of my decisions: all of them — the architecture, the merge of each PR, the deploy button.

Why re-implementing is the easy direction

People overestimate this kind of project because they price it like a new build. It isn’t. When re-implementing an existing site you start with three advantages you never have from scratch:

1. The spec already exists. You know exactly which pages, posts, and routes matter, because they’re sitting there. No design-by-schelling-point.
2. The content is already data. Export, review, prune, commit. Our entire content migration was a one-time script and an afternoon of merges.
3. The failure modes are known. Four days of operation, several live deploys, and a real cutover — the lessons (pin your Hugo, point app_location at the built artifact, keep machine-facing contracts in a README) came from the system telling us the truth, and got written into the gate scripts so they can’t recur silently.

And with an agent in the loop, the mechanics — repo scaffolding, template code, exporters, workflow YAML, migration scripts, the 29-check build gate — are the part agents are best at, while the parts that need judgment (what to keep, what to publish, when to flip the DNS) stay with you. If you’ve been sitting on an aging site you’ve been meaning to fix: point something capable at it, ask for an honest audit, and be surprised by how small the content side is.

The repo is PhilWheat/philwheat-site (private at this time - let me know if you’d like access) on GitHub; the full architecture plan lives in my notes vault, and this post itself was drafted in the same pipeline it describes.

(This was an experement in having the Agent summarize the interaction thread into a post.)