Jason Fried's WriteOn post was so inspiring that I couldn't stop thinking about it, so I built its ideas into an Emacs package: write-on.el. The rule I ended up with is simple: the model suggests, I write. It gives me more options, reads my draft with fresh eyes, and proposes cuts. Every change still goes through me.
The idea in brief
WriteOn calls it alternative control. A word, sentence, or paragraph can hold several versions, and you choose which one shows. Nothing you write gets thrown away just because you weren't sure yet.
- Alternatives: keep variants of a span and swap them in place.
- Ghost: dim a sentence instead of deleting it, and read the paragraph without it.
- Overflow: a pane next to the page for cuts that are good but don't belong here.
Each of these makes it safe to try things, which is the foundation you want before bringing AI into writing.
AI in a personal writing workflow
Most AI writing tools work the same way: you hand over a paragraph and get a different paragraph back. It reads fine, but it's no longer quite yours, and you have to diff it in your head to see what changed. You've stopped writing and started reviewing someone else's draft.
When I write, I want the model to do what a good editor sitting beside me would do, not to write for me.
Ask for options, not answers
When a word or sentence feels off, I usually know that it's wrong before I know what would be right. That's the moment to ask the model.
In write-on, asking for alternatives sends the span along with the paragraph around it, so suggestions match the voice and fit the place. They come back as more entries in the span's list, next to my own versions. My original is still one of the choices. I scroll through them in place, see each one in the sentence, and pick, or ignore them all.
The model widens the set of choices, and the choosing stays with me. Often none of the suggestions is right, but seeing six wrong ones is what shows me what the right one should be. Then I type it myself.
A second reader, not a ghostwriter
The hardest part of revising your own draft is that you can't read it fresh. A model can.
The Lab reads the region or the whole document and marks things instead of fixing them:
- the weakest sentences: vague, flat, or redundant
- sentences that run long
- sentences that are hard to follow
- words that don't fit the tone
- hedges and filler
Each mark is an underline with a short note, and I step through them one at a time. Some I fix; some I disagree with and skip. A rewrite wouldn't let me disagree.
Make mechanical fixes reversible
Typos and punctuation are the one place where I'm happy to let the model just fix things. Even then, each fix is applied as an alternative with the original kept, so any one can be undone in a single keystroke. Models sometimes "correct" a word you chose on purpose.
Cut, but only cut
Trimming is where AI tools overstep most. Ask for "20% shorter" and you usually get a rewrite that happens to be shorter.
Here, a trim proposes cuts by fading words in place on the page. You read the paragraph with the cuts faded, keep anything you want, then make the cuts. And the tool checks that the model only deleted words. If it reworded, reordered, or added anything, the trim is rejected. "Cut" should mean cut, and I'd rather the software enforce that than trust a prompt.
Stay in the flow
A writing tool can't make you wait. Requests run in the background with a small spinner, and you keep typing. If you've moved on by the time the suggestions arrive, they wait for you instead of grabbing your attention. If you edited the text the review was about, the stale results are dropped so they don't land in the wrong places.
It's your workflow
Because it runs inside Emacs on top of gptel, the model is whatever you've configured: Claude, a local model, anything gptel supports. The system prompt is a variable you can change. Documents stay plain Markdown or Org; all the alternatives and ghosts are stored separately.
Closing
WriteOn is a native app. But what made the post inspiring was the idea, and an idea can be described in a few sentences. Once you can describe a feature that clearly, building it into the tools you already own isn't a big project anymore, especially with a model helping. I went from reading the post to a working, tested version in an evening.
I think that's how product demos will matter more and more: less as a reason to switch apps, more as ideas you can bring into your own setup and shape around how you work.
The code is at github.com/bbw9n/write-on.el. And if you don't use Emacs, go read Jason's post anyway.