The Shift to Building Builders

Introduction

Anyone who has built more than a handful of WordPress sites knows the routine. Open the builder. Pick a layout. Drop in sections. Adjust spacing. Insert content. Set colors. Wire the form. Make sure the structure looks close enough to the last ten sites built for similar businesses.

That is not where the value is. It is not really even where the thinking is. It is assembly, and assembly is exactly the kind of work systems are good at.

The part that actually requires judgment comes before any of that: deciding what the page should do, how the hierarchy should work, what matters most, what can be simplified, and what should happen when a user takes action. The repetitive clicking has always felt like rent paid to get to the work that matters.

Where the pieces started connecting:

I was already using AI to generate components, think through structure, and surface edge cases. I was also using Playwright to test full user flows and see what was actually happening in the browser. At some point those stopped feeling like separate tools and started looking like parts of the same system.

If AI can define what needs to be built, and browser automation can interact with the interface the way a user would, the next step is straightforward: let that combination drive the builder directly.

Say I need a landing page for a local plumbing company. Normally that means thirty to forty minutes inside Divi, dropping in a hero section, adding a services grid, setting up a contact form, wiring the CTA, adjusting mobile spacing, filling in meta descriptions. The structure is predictable. The decisions are mostly already made before I open the builder.

What I am working toward is a flow where I define the business type, the page goal, and the brand assets, and a system handles the rest inside the same builder I would normally click through by hand. AI generates the structure and content. Playwright drives the interface. Divi renders the result. The client still gets something familiar to manage. What changes is that I did not spend forty minutes assembling it.

What actually changes:

This does not remove the work. It moves it.

The time spent clicking gets traded for time spent defining rules, documenting patterns, and deciding what correct output should look like before a system tries to reproduce it. If I cannot explain a workflow cleanly enough for a system to follow it, that is usually a sign I have not fully thought it through myself. Automation is very good at exposing vague thinking.

A few enterprise tools are already moving in this direction. Skyvern uses AI-driven browser automation to navigate web interfaces without hardcoded selectors. Amazon Nova Act does something similar for multi-step browser tasks. Both point to the same idea: instead of building integrations into every platform, let a system use the existing UI the way a person would. What strikes me is how underexplored that pattern still is in the WordPress and page-builder world, where the interfaces are mature, the workflows are repetitive, and the structure is often predictable enough to automate well.

Where this is headed:

The more I work this way, the less interesting the question "how do I build this faster" becomes. The more useful question is how I design the process that builds it for me.

The pieces mostly exist already. AI handles structure and content generation. Browser automation handles interface interaction. Page builders handle rendering and client-facing management. What is missing is the integration layer that connects them, the part that turns a set of inputs into a finished page without a person clicking through every step.

That is what I am building now. Not waiting for a platform to solve it, but wiring the pieces together and seeing how much of the manual work actually needs a person in the loop. So far, less than I expected.