Why use Webstudio if AI can build the website?

Spoiler: for some types of websites, we probably don't.

An agent can make a site, publish it, change it later, and inspect the result in a browser. A personal page, a temporary event site, or a one-off campaign may need little more. We had templates and do-it-yourself site builders for that long before LLMs. AI just makes the starting point much cheaper.

I have been trying to answer a more uncomfortable question: if a professional can work with an agent directly, why would they need Webstudio at all?

The usual answers are not convincing. A client can ask an agent to change the site. An agent can update shared components across many pages. It can test a deployment and explain code it wrote six months ago. Visual editing is not a magical form of professional judgment either. A good designer can make the important decisions while working with code and an LLM.

Professional website work has moved through a few different centers of gravity: hand-written pages, CMSs, frameworks, design tools, visual builders, and headless systems. Agents will move a lot of work again. They make it much easier to produce the first version and to change it through language. What happens after that is the part I am trying to understand.

The first version is not where the work ends

I think the difference may be less about making the website and more about what happens to the result afterward.

Take a workflow Webstudio already supports. Ask an agent to make a blog. It can create Markdown articles in the project's Assets, build a blog overview and a dynamic article page, add the queries and bindings, set the page metadata, and inspect the rendered result with vision. The finished blog remains in the same Webstudio project, ready for the next change through the Builder or MCP.

That small change can be made in the Builder, or through MCP. A client can receive Content access to edit only the text, images, and predefined components we chose to expose. A workspace can give another person permission to view, edit content, build, or publish. Before the site goes live, publishing checks for broken Resource references and invalid HTML nesting. The same project can go to a password-protected staging domain before it goes to production.

Hosting is part of that workflow too. Webstudio Cloud builds and deploys the project and handles custom domains alongside staging. We optimize the whole path from building the site to delivering it to visitors. If another hosting setup makes more sense, you can export the project or self-host the generated site.

None of this is impossible to recreate with an agent, a repository, and several services. But it is already designed as one workflow. You do not need to decide where the content lives, build the editing boundary, add the publish checks, and keep those decisions working together.

You should not need every Webstudio feature

There is an obvious objection to this whole idea. Most projects do not need every feature we have today, and they may never need many features we will add later. If an agent-only setup has a narrow, stable job, it can be cheaper and simpler.

Unused features are not a reason to pick Webstudio. The question is what it saves you when the feature you do need arrives.

The Content Engine is one example. It keeps articles as Markdown and JSON files in the project, lets pages query their fields, and keeps article bodies out of the published content database. It is deliberately not an enterprise CMS: projects that need several thousand entries, complex editorial workflows, or content shared across applications should use an external CMS instead.

Webstudio cannot solve every future need, and it should not try to become every service a business uses. There will still be external CMSs, ecommerce platforms, email tools, and custom applications. The useful boundary, I think, is the website itself: the parts that need to share design, content, publishing, access, and an understanding of what is live.

A visual builder has to be useful after the agent acts

This is where visual development changes for me. The Builder should not compete with an agent at typing CSS or assembling sections. It should be a fast place to inspect a result, compare directions, check responsive behavior, and make a precise correction while the work is still in front of you.

Webstudio MCP already has fast iterative previews, and it can inspect rendered pages with vision. That gives an agent a short loop: make a change, look at the result, make another change. The Builder gives a person the same project to inspect and adjust visually.

The next step is to make checks easier to see before publishing: links, accessibility, metadata, structured data, responsive states, and changes to shared components. An agent can run these checks from a skill. The important part is making their result part of the project workflow instead of another output someone has to remember to inspect.

The next missing part is knowing what happened after publishing

Publishing is not the end of the work. A form may stop converting. A page may become slow. An article may lose search traffic. Or somebody may ask an AI a question your site was built to answer and get sent to a competitor.

Today, these signals usually live in different places. I think Webstudio should bring them closer to the project and its publishing history. When an agent suggests a fix, it should be possible to see what changed, publish it deliberately, and check whether it helped. That includes search rankings and whether AI systems surface the site for the questions it is trying to answer.

The product direction follows from this

I keep coming back to three areas:

• Prototyping, review, and testing. Fast MCP previews and rendered inspection are the start. The Builder should become a better canvas for trying directions, checking responsive states, and deciding when a change is ready to publish.
• Management. Content, access, publishing, and the Builder already belong to the same project. Forms and marketing integrations, ecommerce integrations, and custom code components should extend that project.
• Observability. After publishing, the project should help a team understand errors, performance, conversions, search visibility, and what changed before a result moved.

Maybe this is what Webstudio is for

With perfect skills, an agent can give you all of this without a visual development platform.

The question is whether, each time a website grows another requirement, you want to build and maintain the surrounding tool yourself. We are trying to offer a different starting point: a website system that has already spent time on the problems around content, publishing, access, design, and agents, without forcing every project to use all of it.

Maybe agents will eventually make that trade-off uninteresting. For now, I think the test is whether Webstudio saves people from making a pile of temporary solutions every time their website needs to do one more real thing.