What is the right undo experience for AI-generated changes?

Numerholt is a spreadsheet platform built for financial modeling, with an AI assistant that can restructure formulas across a model on request. Imelda Cho is an analyst who uses it daily. This is about the moment undo did more than she asked it to.

How to answer this, stage by stage

Nobody is grading whether you know that undo buttons exist. They're grading whether you noticed undo can have its own kind of mistake.

Let's learn

Picture this: you ask an AI assistant to clean up one part of a document you've been working on for an hour, and you like almost none of what it did. You click undo. What comes back?

Before Numerholt had an AI assistant, every edit to a model was manual, and undo simply stepped back through exactly what you'd typed, one keystroke or one cell at a time, in order.

The fourth box, isolating the diff, is the whole design problem. Everything before and after it is straightforward.

Now the AI assistant can restructure a whole section of a model in one request, dozens of cells at once, in seconds.

Here's the turn: the AI's mistake was never the expensive part. The expensive part was that the only undo available reverted everything back to the last save, which meant any manual work done in the twenty minutes since also vanished, silently, with no warning that it was about to.

At its worst, an analyst loses an hour of hand-tuned scenario work to a single click meant to fix a much smaller problem, and doesn't notice until she needs that scenario again days later.

Both panels say "undo." Only one of them costs you something you didn't ask to lose.

What I would leave alone: a single-cell AI edit doesn't need any of this. It was never at risk of tangling with a manual edit made minutes before, so the simplest undo path is still the right one there.

The lesson: an undo button is a promise about scope, not just a promise to go backward. The moment it takes back more than what actually broke, it's made a new mistake instead of fixing the old one.

Now here is the same thing as a story

The short version above is what you'd say defending this design to Numerholt's product council. Read this one for the actual Thursday afternoon.

Two in the afternoon is when Imelda Cho does her best work, deep enough into the day that the model's structure is fully in her head, but early enough that she isn't rushing to close it out before a meeting.

That Thursday, she'd spent since 2:00pm hand-tuning a one-off downside scenario for a partner call, adjusting a dozen cells by hand to model a specific bad quarter. At 2:20pm, with that scenario still open in the same file, she asked Numerholt's assistant to extend the whole revenue forecast from twelve months to twenty-four.

The assistant rewrote forty cells in about a second. Three of those cells were ones Imelda had hand-tuned twenty minutes earlier for her downside scenario, now silently overwritten as part of the broader rewrite.

Twenty-five minutes from a careful one-off edit to losing it entirely, by clicking the one button meant to protect her.

She didn't like the twenty-four-month forecast, so at 2:25pm she hit undo, expecting the AI's rewrite to disappear and her afternoon's work to still be sitting there. Instead, Numerholt reverted the whole file to its last save point from before 2:00pm. The AI's forecast was gone. So was her downside scenario.

She rebuilt the downside scenario from memory over the next twenty minutes, annoyed but not alarmed, since nothing on screen had told her the two were ever linked.

None of these four existed on the old undo button. It just said "undo," full stop.

With the redesign, that same 2:21pm AI edit becomes its own labeled card: "Changed 40 cells to extend the forecast to 24 months," with a preview of before and after, and a button that undoes only those forty cells. Run the same afternoon forward: Imelda clicks undo at 2:25pm, the forecast rewrite disappears, and her downside scenario, untouched by the AI edit in the first place, is exactly where she left it.

Most edits, including Imelda's forty-cell rewrite, are large but still clean enough to isolate. Only the tangled corner needs the honest fallback.

The old undo asked Imelda to trust that going backward meant going back to exactly where she wanted. The new one shows her precisely what it's about to take back, and nothing more.

I approved the shared undo stack because it was simpler to build, and simple felt like the safer choice at the time. It took one lost scenario to see that simple, in this case, just meant nobody had drawn the line the AI's edit actually needed.

PICK, in one screenNot a lecture on undo history. PICK is what forces you to say which mistake you're actually optimizing against.

Any one of these three is a real reason to fall back to a full revert, said out loud instead of pretended around.

The recap, one line per letter: position is scoped undo as the default, impact is silent data loss versus tedious manual diffing, cost asymmetry is that silent loss is worse because it's hidden, and kill criteria is falling back to full revert when an edit is genuinely too tangled to isolate.

And if you want to be sure it really works, try it somewhere elseSame four letters, a design tool instead of a spreadsheet. The tangled thing is a shared layer, not a shared formula.

Sketchloom is a vector illustration app with an AI feature that can simplify or reflow linework across a whole file at once. Renata Kessling is a freelance illustrator who uses it on client work. Mapped onto PICK: position is the same, scoped undo on the AI's own layer changes, not a full-history revert; impact is that Sketchloom's single shared undo stack meant asking the AI to simplify linework on a client piece wiped out unrelated manual touch-ups Renata had made to a personal side project open in another tab of the same file, ten minutes she can't get back without redoing it from memory.

The cost asymmetry runs the same direction: a full revert is one click and looks safe, but it silently erases whatever else changed since the last save, wherever in the file that happened to be. The kill criteria also transfers directly: if the AI's linework simplification touched a path a manual edit also depended on, like a shared anchor point, Sketchloom's redesign says so plainly and offers a full revert instead of a broken partial one, rather than guessing.

Same two boxes, a different file format underneath them. The asymmetry never changes.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "scope undo to the AI's own edit by default, keep full revert as a second option, and fall back honestly when they're too tangled to separate," and stop.
Cost: there's no time to build entanglement detection this quarter. Say so honestly, and start by isolating undo for the most common case, a single AI request touching one contiguous block, before handling every tangled edge case.
The model gets better, for real: if the AI's edits get more surgical and touch fewer cells over time, that's still not a reason to go back to one shared undo stack, a smaller edit that still overlaps manual work costs the same when it's wiped by mistake.

Where people run it wrong.
They build one undo history for both AI and manual edits because it's simpler, and call the simplicity a feature.
They assume showing a diff after the fact is the same as protecting the work before undo runs, when the loss has often already happened by the time anyone reads a diff.
They wait for a support ticket about lost work to notice the fallback rate climbing, instead of watching it as a number from day one.

How to use it live. When someone asks you for the right undo experience, don't reach for "just add an undo button." Ask what undo could take back that the person never agreed to lose, and design against that specifically.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0