Editable outputs and undo

Why this matters #

AI output is a first draft from a collaborator who’s usually helpful and occasionally wrong. People trust collaborators like that when they can see the work, change it and take it back. They stop trusting them the first time something changes that they can’t undo.

Editable, reversible output does two jobs at once. It keeps users in control, which is what makes them willing to use the feature on things that matter. And every edit they make is the most precise feedback you’ll ever get about what the model got wrong.

Suggestions, not decisions #

The most important design choice is framing. The same model output can be presented as:

• A decision: the AI changed your document, filed your ticket, set your settings.
• A suggestion: here’s a draft or a proposed change; you decide.

For most features, start with suggestions. Present output as a draft the user owns: visually distinct until accepted, easy to edit before it lands, and never silently applied to important content.

Accept, reject and edit #

The right interaction depends on what the AI produces.

For text (drafts, rewrites, summaries):

• Show the draft in an editable field, not a read-only block. Users will want to change a word or two.
• For rewrites of existing text, show the changes inline, like tracked changes, so users see exactly what’s different.
• Offer three clear actions: Accept (use as is or with edits), Regenerate (try again, ideally with a reason), and Discard.

For code:

• Show a diff, never a silent replacement. Developers review changes line by line.
• Let users accept parts of a change, not only all or nothing.

For structured data (form fields, categories, extracted values):

• Pre-fill fields but mark which values came from the AI, so users know what to check.
• Highlight low-confidence or unusual values for review.
• Make every field editable before submission.

Two principles apply everywhere: nothing important happens without a clear user action, and the user’s edits always win. If the AI regenerates, it shouldn’t overwrite changes the user made by hand.

Undo and history #

Undo is what makes it safe to try an AI feature. Without it, users hesitate; with it, they experiment.

• Every AI change gets an undo. Including bulk actions. One action, one undo step.
• Undo restores exactly what was there before, including the user’s own edits made after the AI change, where possible.
• Keep a short history of versions for longer artifacts: the original, each AI version, and the user’s edits. Let users compare and restore.
• Make undo visible right after the change. A toast with “Undo” for a few seconds after an AI action catches most regrets.

For changes that can’t be undone, such as sending a message or calling an external system, the undo has to happen earlier, as a preview and confirmation. That’s the subject of approval flows.

Capturing edits as signal #

When a user accepts a draft after changing half of it, that’s very different from accepting it untouched. Both count as “accepted”, but only one means the AI did its job. Measuring how much users change output gives you a quality metric that comes from real usage, for free.

The simplest useful measure is an edit ratio: the share of words that changed between the AI’s version and what the user kept. Here’s a small, dependency-free implementation based on word-level edit distance:

/**
 * Share of the AI draft the user changed before accepting it, from 0 (kept as is) to 1 (fully rewritten).
 * Word-level edit distance: insertions, deletions and substitutions of whole words.
 */
export function editRatio(aiDraft: string, finalText: string): number {
  const a = aiDraft.trim().split(/\s+/).filter(Boolean);
  const b = finalText.trim().split(/\s+/).filter(Boolean);
  if (a.length === 0 && b.length === 0) return 0;

  // Classic dynamic programming over two rows to keep memory small.
  let prev = Array.from({ length: b.length + 1 }, (_, j) => j);
  for (let i = 1; i <= a.length; i++) {
    const curr = [i];
    for (let j = 1; j <= b.length; j++) {
      const substitution = (prev[j - 1] ?? 0) + (a[i - 1] === b[j - 1] ? 0 : 1);
      curr[j] = Math.min((prev[j] ?? 0) + 1, (curr[j - 1] ?? 0) + 1, substitution);
    }
    prev = curr;
  }
  const distance = prev[b.length] ?? 0;
  return Math.min(1, distance / Math.max(a.length, b.length));
}

// Kept as is → 0; one word changed out of eight → 0.125; replaced entirely → 1.
console.log(editRatio('Thanks for reaching out, we will reply soon.', 'Thanks for reaching out, we will reply soon.'));
console.log(editRatio('Thanks for reaching out, we will reply soon.', 'Thanks for reaching out, we will reply today.'));
console.log(editRatio('Thanks for reaching out, we will reply soon.', 'Refund issued.'));

Log the edit ratio with each accepted output, along with the model and prompt version. You’ll then be able to answer questions like “did the new prompt reduce how much people rewrite drafts?” and “which kinds of requests get rewritten the most?” Capturing feedback builds on this, and Project 4 uses edits to improve a prompt.

Respect privacy when you do this. The edit ratio itself is just a number, but storing the before and after text is storing user content: get consent where required, store only what you need, and follow your retention policy.

Common mistakes #

Try it #

Check your understanding #

Key takeaways #