When Fable 5 returned last week, I knew exactly what to throw at it. In February, I started a project out of frustration that likewise ended in frustration, so I put it on the shelf and waited. Five months later, Fable 5 was released, and I knew it was time to finish Editor, a single-view diffing tool for writers rather than developers.
At MacStories, we all write in Markdown, and we’ve used GitHub to share and sync changes among team members since 2015. GitHub is primarily a developer tool, but it’s a fast, reliable way to share our Markdown-formatted article files, too.
We use GitHub the most for the Club MacStories newsletters. Every week, Federico, Devon, Jonathan, and I work on sections for MacStories Weekly and save them to a GitHub repo. That allows any of us to sync the sections locally for reading, editing, and assembling the issue.
The trouble is that as great as Markdown text editors are to write and GitHub is for versioning and syncing, there isn’t a good way to view the changes someone has made to a document. I know because I’ve been looking for a solution for a long time. Some Markdown apps like iA Writer and Bear support versioning or backups, but I’ve yet to find a text editor that can visualize changes made by someone else based on a document’s Git history.
Of course, developers have many ways to track changes to code, including GitHub Desktop, Kaleidoscope, and Git Tower. Code is just text, so those apps can be used by writers, too. However, the process of writing and editing prose is fundamentally different from code. I’ve tried the apps above and others, and it’s just too hard to track changes in the formats development tools use.
This is what it’s like trying to track changes in GitHub Desktop.
We wouldn’t have stuck with GitHub as long as we have if it didn’t work, but that hasn’t made the friction of reviewing changes any less frustrating, especially on Fridays when we send MacStories Weekly. That’s when I had the idea for Editor. I was trying to parse some changes Devon had made to one of my stories with GitHub Desktop, and the friction finally got to me.
One obvious problem was the side-by-side document view many code diffing tools use. I wanted more detail than most diffing tools offer, but in a single, readable view, so I could skim through changes quickly.
Most agent-assisted projects benefit from some up-front research and planning. I knew what I wanted would sink or swim on the design, not the app’s underlying Markdown viewer, so I spent time researching systems for visualizing document edits.
That’s when I came across Upwelling, a multi-author project from Ink & Switch that describes itself as “an independent research lab exploring the future of tools for thought.” In their research paper, the authors described my exact problem:
Unfortunately, version control tools like Git, which are designed for software development, do not suit the needs of writers. Git cannot compare or merge files from WYSIWYG editors such as Microsoft Word… and graphical user interfaces for Git are cluttered with complex concepts such as commit hashes and visualizations of non-linear branching and merging histories.
Ink & Switch’s solution, a prototype collaborative text editor, wasn’t what I wanted to build, but the research behind it was full of interesting ideas that helped me settle on several principles for what would become Editor:
- Document changes needed to be visible in a single view that carefully balanced highlighting changes with readability;
- A writer should be able to instantly switch from the marked-up version of their document to the clean original and edited final version;
- Changes needed to be categorized by filterable types like punctuation, word choice, capitalization, insertions, and deletions to reduce clutter in heavily edited documents;
- Change types would be color coded using a side rail system inspired by maps of London’s tube system;
- Navigating among individual edits needed to be done by simple j/k keyboard input; and
- Global document navigation should employ a mini-map of a document’s edit regions (a feature borrowed from developer IDEs like Xcode) to make it easy to jump from one area of a document to another.
Working with Claude and artifacts to prototype Editor.
With those choices made, I got busy in Claude Code and came up with a proof of concept quickly, but sadly, these were the days of Claude Opus 4.6, which wasn’t nearly as good at design as today’s models. What I wanted was possible, but what I had was a mess.
The prototype is recognizable as Editor, but far less readable than the finished version.
As it turns out, designing track changes that are accurate but readable is hard. For example, does changing “day” to “date” replace one word with the other or substitute one character (the “y”) for two others (“te”)? Despite putting clear parameters around what Editor should look like, I could tell Claude was stuck, so I called it quits and moved on.
However, I’d wanted something like Editor for far too long to simply give up. So I saved what I had to a GitHub repo and figured I’d take another run at it later.
Editor makes it easy to see small changes like punctuation with filters.
Later turned out to be last week when Claude Fable 5 was re-released after a U.S. government shutdown of the model. Anthropic made the model available to its subscribers, with some restrictions, through July 7, which I made good use of.
A lot has changed in the six months since I put Editor on ice. Notably, Claude Opus 4.8 and Claude Design were released, and Claude became better at using a browser, all of which fit nicely with Editor’s relatively complex design.
Dark mode does a particularly nice job of highlighting changes.
Between Opus 4.8 and Claude Design, I expect I could have finished Editor without Fable 5, but with it, the only thing that slowed me down was my five-hour token limit. I repeatedly hit the limit in under an hour as Fable managed a swarm of subagents. What could have taken a few hours last Friday night spanned an evening and the next morning. The token gating slowed me down, but at the same time, I expect that using Opus 4.8 and Claude Design would have taken the entire weekend.
But it isn’t just speed that makes Fable 5 impressive; it’s the fact that it got Editor’s complex UI right the first time. Fable took a carefully planned but very broken prototype and turned it into a polished product that the whole MacStories team can use.
Editor is built to run on the internal tools foundation Federico created.
However, there’s a big difference between a web app running on my Mac mini server for personal use and something that can be shared. Fortunately, Editor also benefited from the internal tool foundation Federico has built over the past several months.
He originally built it to house Feedboard, his kanban-style RSS feed reader; Images, an update to our tool for uploading images to the MacStories CDN; and iOS Review Search, a semantic search tool for his iOS and iPadOS reviews. It’s a login-protected internal page built on web app hosting platform Vercel. I later contributed a tool that summarizes Apple Newsroom posts and simplifies uploading their promotional images to our server.
Federico managed Editor’s deployment, in part, from Cursor for iPhone.
With a couple of those tools in hand as context for Fable, I asked Claude to get Editor ready for our internal tools page and passed it off to Federico with a separate set of specs and instructions he could point Claude at for deployment and the creation of a landing page. That introduced bugs that required some troubleshooting, which Federico handled in part using Cursor and it new iPhone app, but by that afternoon, Editor was ready for production. The entire process from old, broken prototype to production web app took less than 24 hours, and for a lot of that time we were either asleep or away from home.
Navigating by individual edit.
When you use agentic tools like Claude every day, it’s easy to forget how far they come so quickly. All you see are the flaws that still serve as roadblocks. What was different about using Fable 5 was that there were no roadblocks. It simply took a project that Opus 4.6 struggled with in February and made short work of it. It was a remarkable thing to see. And now, we have a tool that I’ve wanted since we started using GitHub for our writing in 2015.
Tomorrow, Fable will move to usage credits that are just too expensive for my tastes, given how fast the model burns tokens. Hopefully, it will trickle back into Anthropic’s subscription tiers in the future. Until then, though, I’ll continue knocking out prototypes, and if they’re too much for Opus, I’ll shelve them until a better model comes along. They always do.
Login
