I Rebuilt This Whole Site in Agent Mode

The site you are reading was rebuilt from scratch by directing an AI agent, and then moved off shared hosting onto AWS. I did not type most of it. I directed it. That distinction is the whole story, so let me be concrete about what it actually looked like, because the honest version is more useful than the brochure.

The starting point was WordPress on cPanel

Before this, the site was WordPress on cPanel, the way a lot of personal sites are. It worked, in the sense that it was up. It was also slow, heavy, a moving target for security updates, and a place where every change meant fighting a theme and a stack of plugins to do something a flat file could do better. I wanted a static site: plain HTML and CSS served fast, with the content living as files I own instead of rows in a database I have to babysit.

So the goal was two things at once. Rebuild the site on a modern static stack, and migrate the hosting off cPanel and onto AWS. Either one is a project. Doing both, solo, would have been a month of evenings a couple of years ago. It was not.

What "agent mode" actually meant here

Agent mode is letting the AI do the task, not the keystroke. I did not ask it to write a function. I handed it the codebase and a destination: build this in Astro, keep the content as markdown, make it fast, match this design sense. Then it read the existing structure, made changes across many files at once, ran the build, read the errors, and fixed them, and surfaced when it was stuck or when a real decision was mine to make.

My job moved up a level. I was not writing the components. I was deciding what the site should be, reviewing the diffs, catching the architectural choices that would cost me later, and saying yes or no. The cost of producing the code dropped close to zero. The thing that did not drop, the thing that became more important, was judgment: knowing what to build, and knowing when the agent had done something that looked right and was wrong.

That is the part the hype skips. Working this way is not less engineering. It is more of the engineering that matters and less of the typing that does not.

The migration, and the antifragile habit

Moving from cPanel to AWS meant rebuilding the serving layer too: the site is now static files in an S3 bucket, served through a CloudFront distribution, with the caching and the redirects and the security headers all defined as configuration instead of clicked into a control panel. The agent did the bulk of the wiring. I did the part you cannot delegate, which was deciding how it should fail.

That phrase matters more than it sounds. The move taught me as much as it migrated. Doing it well meant naming the failure modes in advance and rehearsing them, instead of discovering them in production. What happens when a deploy is incomplete. What happens when a cache header is wrong. What happens when a path that worked on the old host does not resolve the same way on the new one. The platform itself kept nudging me toward the same habit: assume the part will fail, and build so that when it does, you already know what happens next.

The day a deploy script deleted production

Here is the part I want to keep in, because it is the real lesson and not the marketing one.

An agent wrote a deploy script. It was good. It built the site, synced the files to S3, and cleaned up anything stale so the bucket matched the build exactly. That last behavior, deleting whatever was not in the new build, is correct right up until the build comes up short. One day a build failed partway through, produced an incomplete set of files, and the script did exactly what it was told: it made the live site match the incomplete build, which meant deleting most of the images from production.

Nothing about that was the agent being dumb. The script was logical. The bug was that a destructive operation was coupled to an assumption that the build was always complete, and nobody, human or machine, had questioned that assumption until it failed.

The recovery is the point. The images were never really lost, because the source of truth was the repository on my machine, not the bucket. I pushed them back up with a sync that only adds and never deletes, cleared the cache, and the site was whole again in a few minutes. Then I did the thing the incident was actually asking for: I changed the deploy so a bad build can no longer reach a destructive step, and so asset uploads only ever add. The failure became a permanent improvement to the system, which is the only good thing a failure is for.

I caught it, fixed it, and hardened it, and the agent did most of the typing for all three. That is the loop working as intended. Trust it to do the work. Do not trust it to be right. Keep a source of truth it cannot touch, and keep the irreversible operations behind a gate.

It is still changing

The site is not finished, and I do not want it to be. It is a place I keep rebuilding in the open, because the tools keep getting better and because the practice of working this way is itself the thing I am trying to learn. What used to be a month of evenings is now an afternoon, and the bottleneck has moved entirely to taste and intent and verification, which is exactly where I want it.

If you want the method underneath this, I wrote it down: an AI agent workflow that actually holds up, and the longer version in AgentSpek, free to read here. And if you want the philosophy underneath the method, it is all one idea: making a complex system legible enough to live inside, whether the system is a cloud platform, a codebase, or a life.