What Rebuilding Our Website Taught Us About Engineering for AI

This blog is part of the Project Weaver engineering series, where we share what we’re learning as we develop frameworks and strategies for AI-assisted software engineering.

Most companies outsource website maintenance to agencies. We outsourced ours to AI agents.

Today, our profiq website is maintained through an autonomous workflow where AI agents detect issues, implement changes, test them, and prepare them for deployment. It became our first production system where AI agents weren’t assistants, they were operators.

Let’s start at the beginning and talk about how we got here.

Every engineering team has a project that slowly becomes “the thing nobody wants to touch.” For us, it was our website.

Not because the website itself was particularly complicated. It had simply accumulated years of history. Different developers had contributed to it over time. Some functionality lived in code, some in WordPress, some in plugins, and some in databases. Even seemingly simple pages depended on layers of context that weren’t immediately obvious.

Developers could eventually piece that context together, but every change meant rebuilding that mental model from scratch. For AI agents, the challenge was even greater.

Layered context isn’t just inconvenient for developers, it becomes one of the biggest obstacles to autonomous AI development. If an AI has to understand multiple systems, hidden configuration, production databases, and years of implementation history before making a simple change, autonomy quickly breaks down.

That realization changed the project. We weren’t simply rebuilding a website. We were rebuilding it so AI could understand, maintain, and evolve it alongside our team.

Goals Beyond Migration

Our website is an important business asset. We regularly publish technical articles, launch new services, create landing pages, and refine how we communicate what we’re building.

Initially, we thought the goal was to remove engineering as the bottleneck for those updates. But as we applied the Project Weaver framework to the migration, the objective became much bigger. The goal became creating a website that AI agents could safely work on.

Once that existed, everyone benefited.

Marketing could request new landing pages or update content through AI agents rather than waiting for developer bandwidth. Leadership could quickly experiment with messaging or campaigns. Engineers could stay focused on architecture instead of routine website changes.

The same engineering decisions that make a system understandable to AI also make it easier for every human on the team. We weren’t just migrating away from WordPress. We were redesigning the website around an AI-first engineering model.

Before Choosing a Framework, We Let AI Ask the Questions

In our previous article, we introduced the Grill Me method, inspired by Matt Pocock’s approach of having AI interview you before jumping into implementation. Rather than immediately selecting a framework or generating code, we spent a single Grill Me session letting AI challenge assumptions, uncover edge cases, and clarify our requirements.

Although building marketing websites isn’t our core business, that one conversation helped us make confident architectural decisions on day one. Instead of rushing into implementation, we invested time creating clarity. It paid dividends throughout the rest of the project.

That process ultimately led us to Astro.

Choosing the Right Tool

Astro solved a problem that has become increasingly important in AI-assisted development. Everything lives in the repository.

Clone the code. Install the dependencies. Run the project.

You immediately have a complete working version of the production website.

There are no database dumps to locate. No production assets to manually download. No hidden WordPress configuration. No missing content that only exists inside a CMS.

Whether you’re a developer joining the team or an AI agent opening the repository for the first time, everything needed to understand the application is already there. That dramatically reduces ambiguity. And reducing ambiguity is one of the biggest productivity gains you can give an AI agent.

Reducing Uncertainty Before Scaling

One important detail about this migration is that we didn’t write the code ourselves. Instead, we orchestrated AI agents to perform the migration.

The engineering challenge wasn’t implementation, it was designing the right framework, tools, validation, and workflows so the agents could work autonomously while continuously proving their work was correct.

Like any engineering project, we started by reducing uncertainty. Rather than migrating hundreds of pages immediately, we migrated representative examples first. The initial results were surprisingly close to the original website, despite being largely an AI interpretation of the existing codebase.

That proved the concept. Once we knew the approach worked, we shifted to the second stage: achieving visual parity.

We equipped the AI agents with browsers, gave them clear guidance on the screen sizes that mattered most, and had them compare their output against the production website. They identified differences, downloaded the correct assets, applied the appropriate fonts and icons, adjusted spacing, refined layouts, and iterated until they closely matched the original experience.

Instead of manually checking every page ourselves, we designed a process where the AI could continuously validate and improve its own work before presenting it for review.

Where Engineers Still Matter Most

One result surprised us. Approximately 95% of the migration was completed by AI in a few days. That didn’t mean the project was finished. It meant our engineers could spend their time where they create the most value.

Instead of writing repetitive migration code, our team focused on responsiveness, accessibility, SEO, design polish, shared components, metadata, architecture, and long-term maintainability.

AI dramatically accelerated implementation and engineers elevated quality. That’s a much better use of everyone’s strengths.

Removing the Organizational Bottleneck

Perhaps the biggest outcome wasn’t technical at all, it was changing who can contribute.

Today, someone in marketing can ask an AI agent to create a new landing page, publish a blog post, or add a helpful widget. The AI implements the change, validates its work, opens a Merge Request, and deploys a preview environment.

Marketing reviews the messaging, layout, and visual experience. Engineering reviews architecture, maintainability, and code quality. Quality gates remain intact, but engineering is no longer the bottleneck for every website change.

That’s a very different workflow from the traditional model of submitting a ticket and waiting for developer capacity. It’s also a good example of how AI doesn’t replace engineering processes, it strengthens them when they’re designed well.

The Migration Was Only the Beginning

Ironically, rebuilding the website is one important part but not the only part. The migration gave us a stronger technical foundation, but there’s still significant work ahead. Modern websites are increasingly evaluated not only by search engines but by AI systems trying to understand expertise, relationships, and context.

Over the coming months we’ll continue improving technical SEO, structured data, internal linking, topic clusters, metadata, and the relationships between our services, articles, authors, and engineering knowledge.

This is becoming as much an engineering challenge as a marketing one. The better your architecture communicates meaning, the easier it becomes for both search engines and AI systems to understand what you do.

We’ll undoubtedly learn things we didn’t expect and some ideas will work better than others. That’s exactly why we’re sharing these experiences through the Project Weaver engineering series. We’re actively learning what it takes to build software that humans and AI can continuously improve together.

If this migration reinforced one lesson, it’s this: The biggest gains don’t come from asking AI to write more code. They come from building systems that AI can understand, validate, and evolve with confidence.

In the end, AI doesn’t eliminate the need for good engineering, it rewards it.

Interested in applying these ideas to your own software? We’d be happy to evaluate your project and discuss how AI-assisted engineering workflows could fit your team. Contact the profiq team.

Want to follow the Project Weaver journey? Explore the rest of our engineering series as we continue sharing what we’re learning about building production software in an AI-first world. Read the Project Weaver recap.