A few months ago, my website was running on WordPress and Etch.
There was nothing particularly wrong with it. I know WordPress well, and the site did what I needed it to do.
But when I came back to rebuild it properly, I realised its requirements were actually quite simple: content pages, some structured data for the services I offer, a writing section and a contact form. I’m the only person publishing content.
None of that particularly needs a traditional CMS.
I’d also been experimenting with Astro and wanted a substantial project to understand it properly. More importantly, I wanted to see what happened if I combined Astro with the increasingly agentic way I’d started working.
So rebuilding my own website seemed like a useful experiment.
I expected to learn more about Astro. What interested me far more was what happened when I let AI agents write almost all the code.
The first problem wasn’t building the website
One of the advantages of having worked with WordPress for a long time is that I can get an environment running almost without thinking about it.
Spin up a local server from a known blueprint and start building.
Astro initially felt quite different.
The biggest challenge wasn’t HTML, CSS or components. It was the setup around them: project structure, folders, Git repositories, conventions and understanding where everything should live.
Some of that was simply unfamiliarity.
My background is in software engineering, so the underlying workflow wasn’t alien to me. I’m used to working in an IDE, changing code, waiting for a build and then seeing the result, although with this site there wasn’t much waiting involved.
Once I understood how an Astro project fitted together, I found I actually preferred working that way again.
With the project open in Visual Studio Code, I could see the entire codebase while running the AI coding agent alongside it in the same environment. That felt surprisingly natural.
With a visual WordPress builder such as Etch, the workflow is different. The site is running in a browser, the builder is connected there, and the coding agent is typically running in a separate window. There’s nothing inherently wrong with that, but I found myself preferring having the code, agent and repository together.
There was another significant difference: I wasn’t actually writing much of the code.
The agents wrote almost all of it
Pretty much 100% of the code for the new site was written by AI agents.
That doesn’t mean I didn’t look at the code. Quite the opposite. I wanted the code visible. I wanted to understand the structure the agent was creating and see how it solved problems.
Occasionally my old instincts got the better of me.
If I spotted a small copy change, it seemed ridiculous to ask an AI agent to make it when I could edit the file myself in a few seconds. I did that a couple of times, then remembered that I needed to rebuild the project to see the change.
Eventually I realised it was generally quicker just to tell the agent.
More interestingly, when I wanted a code or styling change, I deliberately resisted telling the agent exactly how to implement it. I wanted to see what it would do, then inspect the result and decide whether I was happy with it.
I wasn’t using AI as an elaborate autocomplete while continuing to write the site myself. I was increasingly delegating the implementation while retaining visibility of, and responsibility for, the result.
The real surprise was the speed of the design-to-build loop
The thing that changed my thinking most wasn’t how quickly an agent could write an Astro component. It was how quickly I could move through the whole design and development cycle.
I’ve been experimenting with allowing an AI agent to work directly with design tools through MCP, iterating on the design there and then letting the same agent, or another one, build it.
On a separate site experiment, I recently took a landing page through that process.
Getting the design where I wanted it took about ten minutes. Building the landing page from that design took about another ten.
Very little then needed to change to bring the implementation in line with the design.
I’m not suggesting that websites now take twenty minutes to build. A landing page is not a production website, and the work around content, accessibility, integration, testing and deployment doesn’t magically disappear.
What surprised me was how much of the friction between design and implementation had disappeared.
Traditionally there is a handoff. Someone creates a design. Someone interprets it. Components are built. Differences are spotted. Things go backwards and forwards.
With an agent able to work across those environments, that loop becomes much tighter:
design → build → compare → adjust
The differences I did find between design and implementation turned out to be useful. They showed me where the instructions or standards could be improved so that the next build would get closer.
That started to change how I thought about the whole process.
Astro suited the site better than I’d expected
The experiment also confirmed something more straightforward: Astro is a very good fit for this particular website.
There is more structured content behind the site than just the articles. Services, for example, are data rather than content embedded individually into pages.
With WordPress, I’d typically model that using custom post types and custom fields, which means configuring the appropriate plugins and creating the content model in the CMS.
With Astro, I can use content collections. With an AI agent doing the implementation, creating those collections is extremely quick.
The writing workflow is simpler too.
An article is essentially a Markdown document plus some metadata. I don’t need to log into WordPress or use its editor. I can write in any editor that produces Markdown. My preference is Typora.
The finished site is tiny and blindingly fast. Core Web Vitals and all of the Google Lighthouse metrics, including accessibility, score 100.
I’ve deliberately chosen not to use analytics or other trackers, which removes the cookie and tracking-consent complexity I’d otherwise need to deal with. The contact form still uses Mailgun for email delivery, just as the WordPress version did.
Publishing to Cloudflare Pages was straightforward. I ran into a couple of minor issues getting form submissions working, but they turned out to be caused by putting API keys in the wrong place rather than anything fundamental with the platform.
When my existing WordPress hosting plan comes up for renewal, I won’t be renewing it.
This isn’t really about WordPress versus Astro
None of this has convinced me that every website should be built with Astro.
If a client’s requirements are more complex and mature WordPress plugins already solve them well, I’d still happily choose WordPress and Etch.
Having an AI agent capable of building something from scratch isn’t a good reason to build it from scratch. Equally, the fact that I can build something in WordPress isn’t a reason to build it in WordPress.
The technology should fit the problem.
For the sort of relatively straightforward content-led site I’ve just built, my default choice has changed. I’d now go straight to Astro.
There’s an important qualification to that.
When I started this project, one of WordPress’s biggest advantages was that I’d already removed most of the setup friction. I had known environments and established ways of working. I could spin up a project and get on with the site.
My first Astro build didn’t have that.
So once I’d finished it, I started removing that problem too.
The website wasn’t the end of the experiment
I took what I’d learned from building grahamcrosbie.com and created an Astro project I could clone for the next build.
Initially I thought of it as a starter template.
Then I started looking at the wider workflow: the decisions I wanted made consistently, the standards I expected a site to meet, and the testing that could verify the result automatically.
The starter stopped being just a starter.
It became the Astro Site Playbook: a delivery system for building Astro sites with humans and AI agents working from the same set of standards, while leaving the design free to follow the project brief.
That’s a different subject, and probably another article. But it came directly from this experiment.
I started rebuilding my website because I wanted to learn Astro.
I came away convinced by Astro for this kind of site, but much more interested in something else: how quickly the boundary between design and implementation is disappearing when AI agents can work across both.
And that raises a bigger question.
If an AI agent can write almost all the code, what does software engineering look like now?