The undo button mattered more than the rewrite button it sits next to

Every writing tool I build eventually gets an editor who does not like something it wrote. The honest fix is not always a full rewrite from scratch, and learning to write a better brief instead of a better paragraph is most of what changes once you start delegating writing instead of doing all of it yourself.

I built exactly that for the drafts this pipeline writes: a button that sends a post back to the same system that wrote it, with the same voice rules, and asks for another pass. Pressing it does not touch the text directly. It bumps a counter. A separate job watches for posts whose counter moved and rewrites only those, on its own, so I never sit and wait on it.

The part that actually mattered was not the rewrite button. It was the one next to it. Whatever draft the new one replaces gets kept, not deleted, and a second button swaps it straight back. A rewrite you cannot undo makes you cautious about ever asking for one. A rewrite you can take back in one click costs you nothing to try.

The button exists in the code today and does nothing, on purpose. Pressing it would call a paid API, and even at a fraction of a cent each time, that is a real bill that now scales with how often a button gets clicked, where before there was none. I was not ready to attach a live, metered cost to a workflow I had not used enough yet to know if it earns that cost back. So it stays built and wired, switched off, until I decide it is worth turning the meter on.

The lesson is not about the button. It is that an undo is what actually lets you hand something off. Without one, you check every output like it might be the only version you get. With one, you can let a system take its first real swing and only step in when the swing is wrong.