Back to blog

How I built my AI Site Editor

The architecture, safeguards, and product decisions I used to make AI editing reliable.

  • AI
  • Architecture
  • Editor
  • Engineering

1) I Defined A Narrow Editing Model

I stopped treating the site as one big blob of HTML and represented edits as structured operations.

That gave me clearer validation points and made undo/redo practical.

2) I Separated Intent From Execution

I let the model interpret user intent, but I did not let it apply raw output directly.

Instead, I route the output through a transformation layer that maps it into allowed actions.

3) I Added Validation Before Apply

Before committing changes, I run shape checks and rule checks so bad output gets blocked early.

This reduced broken UI states and made failures recoverable.

4) I Optimized For Fast Feedback

I stream progress to keep the editor responsive, but I only commit partial updates that pass structural checks.

The goal is to feel live without sacrificing stability.

5) I Instrumented Failure Modes

I track where edits fail: parsing, action mapping, validation, or render apply.

Those categories gave me much better roadmap signals than generic latency metrics.

Current Principle

I can ship AI editing features faster when I design for reliability first. In practice, deterministic systems around the model matter more than model output alone.