Leaving a site builder to regain control: how I rebuilt xavier-barry.fr with AI

The trigger was financial, but the real motivation was control

For two years, Hostinger’s builder had done its job: it helped me publish a clean site quickly without spending much time on the technical side.

At renewal time, the equation changed. I could simply have paid for another term. Instead, I used that constraint as a reason to take back control of the site: its code, hosting, SEO, languages, performance, and deployment workflow.

A few years ago, I probably would not have made the same choice. Rebuilding a complete site, even a static one, means handling a long list of details: page structure, components, responsive behavior, redirects, metadata, sitemap, hreflang, assets, multilingual content, and deployment.

AI changed the cost of that decision.

Being hands-on no longer has to mean writing every line

I had no desire to become the main developer of my own website. That is neither where I create the most value nor where I want to spend most of my time.

What I did want was to get much closer to the production chain again: understand the choices, define the architecture, break down the work, review changes, set guardrails, inspect previews, and decide what reaches production.

That is where AI became useful to me. It does not replace technical judgment. It shifts the effort: less time producing every line, more time expressing intent precisely and controlling the system that turns that intent into software.

A deliberately simple stack

The new site uses a much simpler architecture: Astro to generate a static website, GitHub as the source of truth, and Netlify for previews and deployment.

I wanted as few moving parts as possible and a delivery chain I could understand end to end. No CMS, no backend, no oversized infrastructure.

The hard part was not choosing an exotic stack. It was preserving everything that matters when migrating an existing website: URLs, search visibility, content, French, English and Spanish versions, canonicals, sitemap, and performance.

AI becomes useful when the process becomes explicit

During the migration, I gradually formalized a way of working with assistants and agents.

I keep responsibility for framing and content. Agents can inspect the repository, propose an implementation, edit files, and run validations. But their work is constrained by explicit rules: a dedicated branch, a staging target, documented invariants, a non-regression checklist, and human validation before merge.

That discipline may sound excessive for a personal website. That is exactly why I find it valuable: if the process remains reliable on a small project, it becomes an excellent lab for understanding how AI can fit into a larger software delivery system.

Control points I keep:

• a working branch created from staging, never directly from production;
• a written specification before material changes;
• automated checks for routes, i18n, and the build;
• a preview before merge;
• a clear separation between generation and validation.

The main lesson is not “AI codes fast”

This project mostly reminded me that an agent can accelerate a bad decision just as effectively as a good one.

If the architecture is unclear, routing rules are implicit, or content has no source of truth, AI produces inconsistency faster.

When constraints are documented and feedback loops are short, however, it becomes a very concrete capability multiplier.

That is what interests me in AI-augmented engineering: not the spectacular demo of a prompt generating a screen, but the ability to build a production system where additional speed does not destroy quality or control.

What this website represents for me

xavier-barry.fr is obviously my professional website. It has also become a small, permanent laboratory.

I use it to test new ways of working with ChatGPT and Codex, structure handoffs between humans and agents, document invariants, and automate the checks that prevent us from repeating the same mistakes.

I am not trying to become a developer again because of AI. I am trying to remain a CTO / CTPO who understands very concretely how software production is changing.

Explore my approach to applied AI and AI-augmented engineering