AI can generate a landing page in seconds.
That part is no longer impressive.
The difficult part starts when you ask a different question:
Can AI actually understand the page you are editing?
Can it modify one section without breaking the rest of the document? Can it preserve your variables? Can it translate an existing page without destroying its layout? Can it generate a new section that behaves like a native component inside the editor?
These are the problems we faced while building GJSDocs, an AI-powered visual document editor built around a GrapesJS-based editing experience.
In this article, we'll walk through the architecture behind an AI-powered visual editor, what worked, what didn't, and the lessons we learned building it for production.
The Difference Between an AI Generator and an AI Editor
There are two very different products that are often called an "AI page builder."
The first looks like this:
Prompt ↓ AI ↓ HTML ↓ Preview You enter:
"Create a modern SaaS landing page."
The model generates HTML and CSS.
It looks impressive in a demo.
But what happens next?
You want to change the pricing section.
You want to translate the hero.
You want to replace the CTA.
You want to change the spacing.
You want to connect {customer.name} to your CRM.
Now you're back to manually editing the page.
The second approach is much more interesting:
Here AI doesn't replace the visual editor.
AI becomes another way of controlling the editor.
That distinction became one of the most important architectural decisions we made while building GJSDocs.
Why We Chose GrapesJS
When you build a visual editor from scratch, the canvas is only the beginning.
You need:
component management;
drag and drop;
selection;
styles;
responsive behavior;
undo/redo;
blocks;
serialization;
storage;
keyboard interactions;
plugins;
commands;
asset management;
and a way for everything to work together.
Building all of that yourself is expensive.
GrapesJS gives you the editing engine while allowing you to build your own product experience around it.
That is exactly the kind of architecture we wanted for GJSDocs.
The important thing is that GrapesJS doesn't need to know that AI exists.
Your application becomes the orchestration layer.
This separation is extremely useful.
The editor manages visual state.
Your application manages business logic.
The AI layer translates natural language into structured operations.
The Architecture of an AI-Powered GrapesJS Editor
Our architecture can be simplified into five layers.
1. Editor
The GrapesJS canvas contains the actual document.
2. Context
We collect the information the AI needs to understand what the user is currently editing.
3. AI Provider
The request can be sent to an LLM such as OpenAI, Gemini or Claude.
4. Structured Output
The model returns a predictable structure instead of arbitrary HTML.
5. Editor Adapter
The application converts that structure into GrapesJS components.
The complete flow looks like this:
The Context Builder is one of the most important pieces.
Without context, AI is guessing.
With context, AI is editing.
Step 1: Give AI Access to the Editor Context
A common mistake is sending only the user's prompt to the model.
For example:
Translate this section to Spanish. The AI has no idea what "this section" means.
Instead, we can send something conceptually similar to:
{ instruction: "Translate this section to Spanish", scope: "selection", document: { title: "Sales Proposal", page: 2 }, selection: { type: "section", html: "...", text: "...", components: [...] }, variables: [ "client.name", "company.name", "proposal.total" ] } Now the model has a meaningful context.
It knows:
what the user selected;
what page it belongs to;
what the document is about;
which variables exist;
and what operation the user requested.
This makes a huge difference.
Step 2: Don't Ask AI to Return Random HTML
This was another important lesson.
The easiest implementation is:
Prompt → AI → HTML string But it creates problems.
The generated HTML may contain:
invalid structure;
unexpected CSS;
unnecessary wrappers;
styles that conflict with the existing document;
scripts;
unsupported elements;
or content that cannot easily be edited afterward.
A better architecture is:
For example:
{ "type": "section", "layout": "three-column", "heading": "Choose your plan", "columns": [ { "title": "Starter", "price": "{pricing.starter}" }, { "title": "Pro", "price": "{pricing.pro}", "featured": true }, { "title": "Business", "price": "{pricing.business}" } ] } Your application then decides how this structure maps to actual editor components.
This gives you much more control.
Step 3: Let AI Generate Components, Not Just Content
Once the AI output is structured, we can use it for much more than copywriting.
For example, a user could ask:
Create a three-column pricing section with Starter, Pro and Business plans. Make Pro the highlighted option.
The AI can return a structured representation of that section.
Your editor adapter converts it into:
Now the generated result is not just a piece of HTML.
It is a real editable document structure.
That's a much more powerful model.
Step 4: Introduce AI Scopes
One of the best UX improvements we implemented in GJSDocs was allowing AI operations to have a scope.
Instead of one giant "AI generate" button, think about:
Selection
Modify only what the user selected.
Selection → AI → Selection Section
Modify an entire section.
Section → AI → Updated Section Page
Transform the current page.
Page → AI → Updated Page Document
Transform the entire document.
Document → AI → Updated Document This sounds like a small detail.
It isn't.
It dramatically reduces the user's fear of asking AI to make changes.
If I select one paragraph and ask:
"Make this more professional."
I don't expect AI to redesign my entire document.
Scope creates a natural safety boundary.
Step 5: AI Should Understand Variables
This becomes especially important when your editor is not just a website builder.
Consider a business document containing:
Dear {client.name}, Thank you for choosing {company.name}. Your total is {invoice.total}. An AI system that blindly rewrites the HTML might accidentally change or remove those variables.
That's unacceptable in an automation platform.
GJSDocs treats variables as a separate layer.
A template can contain:
{client.name} {client.email} {company.name} {invoice.total} The AI can generate content around those variables while the variable system remains responsible for resolving them later.
This creates a useful separation:
This architecture allows the same template to generate hundreds of personalized documents.
Step 6: Connect AI to Real Data
The next step after variables is external data.
A page builder becomes significantly more useful when generated content can work with actual business data.
For example:
GJSDocs supports integrations such as Airtable, HubSpot and Google Sheets, as well as custom REST API sources.
That means the editor is no longer just a design tool.
It becomes a data-driven generation system.
Imagine a sales team creating a proposal template once.
The template contains:
{client.name} {client.company} {project.name} {project.price} The application retrieves the customer's data.
AI can generate or rewrite the appropriate sections.
The template is rendered.
The final document is exported.
That is a very different product from a traditional page builder.
Step 7: Multiple AI Providers
We also learned that AI should not be unnecessarily coupled to a single provider.
Different models are good at different things.
Some users prefer OpenAI.
Others prefer Gemini.
Others want Claude.
For that reason, the application should ideally expose a provider abstraction:
const ai = createAIProvider({ provider: "openai", apiKey: process.env.OPENAI_API_KEY }); Conceptually:
The editor should not care which model generated the response.
It should only care about the contract:
Input → Structured Output This makes the system much easier to evolve.
GJSDocs currently supports Gemini, OpenAI and Claude for AI-powered document generation and transformation.
Step 8: AI Should Be Able to Edit Existing Content
Generating a new page is useful.
Editing an existing page is arguably more valuable.
Imagine selecting a paragraph and asking:
Make this shorter.
Or:
Translate this page into French.
Or:
Rewrite this proposal for a more enterprise audience.
Or:
Replace this section with a comparison table.
These are fundamentally editing operations.
The AI workflow becomes:
This is much closer to how humans actually use visual editors.
Step 9: Never Give AI Unlimited Control
An AI-powered editor should not blindly execute everything the model returns.
This is particularly important when the generated result can affect:
HTML;
CSS;
JavaScript;
external URLs;
forms;
embeds;
API calls;
or user data.
We recommend treating AI output as untrusted input.
Validate it.
Sanitize it.
Limit what components can be generated.
Don't allow arbitrary JavaScript unless there is a very good reason.
And whenever possible, use a whitelist of supported component types.
For example:
const allowedComponents = [ "section", "container", "heading", "text", "image", "button", "columns", "table" ]; If the model returns something outside the allowed schema, reject or transform it.
The LLM should make suggestions.
Your application should remain in control.
The AI Page Builder Architecture We Recommend
Putting everything together:
This architecture has one major advantage:
Every layer has a clear responsibility.
What We Would Not Do
After building an AI-powered editor, there are a few approaches we would avoid.
1. Don't generate an entire page for every request
If the user asks you to change a heading, don't regenerate the entire document.
Small operations should produce small changes.
2. Don't rely exclusively on raw HTML
HTML is an output format.
It shouldn't necessarily be your internal AI protocol.
Structured data gives you more control.
3. Don't hide the AI state from the user
Users should know what AI is about to change.
Good UX can include:
preview;
diff;
undo;
regenerate;
accept/reject;
selection scope.
4. Don't let AI become the only interface
Some users want to type:
"Make the button blue."
Others want to click the color picker.
A good visual editor should support both.
AI and traditional UI should complement each other.
The UX We Found Most Important
The most interesting lesson wasn't technical.
It was UX.
AI works best when it is contextual.
Instead of placing a giant chatbot next to the editor, put AI actions where the user is already working.
For example:
Now AI feels like part of the editor.
Not a separate product.
That distinction makes the experience much more natural.
Building the First Version
You don't need to build the entire system on day one.
A good MVP can have only three AI operations:
1. Generate
Prompt → New Section 2. Rewrite
Selected Content → Improved Content 3. Translate
Selected Content → Translated Content Then add:
Full-page generation
Style modification
Layout generation
Variable extraction
Data-aware generation
AI templates
AI workflows
The important thing is to establish the architecture correctly from the beginning.
From Page Builder to AI Application Platform
This is where things become really interesting.
Once your AI understands the editor's component tree, it can do much more than generate pages.
It can become an orchestration layer.
For example:
"Create a proposal for Acme Corp." Could eventually trigger:
At that point, you're no longer building just a page builder.
You're building an AI-native content application.
That is the direction we believe visual editors are heading.
What We Learned Building GJSDocs
Building GJSDocs changed our perspective on what an AI editor should be.
At first, it is tempting to think:
"We just need to connect an LLM to the editor."
In reality, the model is only one part of the system.
The hard problems are:
context;
structure;
validation;
editor state;
variables;
data;
permissions;
user experience;
and predictable transformations.
The AI model is the intelligence layer.
The editor is the environment in which that intelligence operates.
That is why GrapesJS is such an interesting foundation for this type of product.
It provides the visual editing engine while leaving your application free to build the AI, data, business logic and UX around it.
Final Architecture
If we were starting a new AI-powered GrapesJS project today, our baseline architecture would look something like this:
The exact stack can change.
The principle doesn't.
Keep the editor, AI and business logic as separate layers.
The Future Isn't AI vs. Visual Editors
We don't think AI will replace visual editors.
We think the opposite will happen.
Visual editors give AI something incredibly valuable:
a structured environment to operate inside.
And AI gives visual editors something they've historically lacked:
a natural-language interface for manipulating complex structures.
The future page builder might look less like:
Drag → Drop → Configure → Repeat
And more like:
"Build me a pricing page for a B2B SaaS company."
Then:
"Make the Pro plan more prominent."
Then:
"Translate it into German."
Then:
"Connect the prices to our API."
Then:
"Make it mobile-first."
And finally:
"Publish it."
The user remains in control.
The visual editor remains the source of truth.
AI simply becomes the fastest way to express what the user wants.
That's the model we're building toward with GJSDocs.
Final Takeaway
If you're building a SaaS product that needs a visual editor in 2026, don't think of AI as an add-on chatbot.
Think of it as a new interaction layer for your editor.
Start with GrapesJS.
Build a strong context layer.
Use structured AI output.
Keep variables and data separate from generated content.
Validate everything.
Give users scope and control.
And most importantly:
Don't make AI replace the editor. Make AI understand the editor.
That's where an AI-powered page builder becomes genuinely powerful.