When I teach journalism students about AI, I like to show them the two extremes of AI adoption. On one end, journalists who have fully leaned into AI writing - Alex Heath using Claude for first drafts; Nick Lichtenberg at Fortune pumping out hundreds of stories. On the other end, journalists who want to keep the writing process free of LLMs, using them instead to brainstorm, or copyedit, or generate counterarguments. Consensus among students tends to form in the middle: We can use AI as an editor, helping to structure and polish and challenge the work.
AI-as-editor is compelling. We get to reap the benefits of the technology while keeping humans firmly in control. And AI can do some of an editor’s work, offering suggestions and acting as a sounding board. But there’s a fundamental thing it can’t do that disqualifies it from any serious editing work. LLMs, even at the absolute frontier, cannot work in documents.
How does a human editor work on a draft? They go into a document, make suggestions, and leave comments. They build a collaborative surface, one where everyone working on the document can see how proposed changes fit into the draft, think about the best way to address feedback, and trace the history of the project.
LLMs can’t engage with that process. Try editing with an LLM, and you’ll get suggestions that contradict each other, that don’t connect to the material in your piece, that make sense in their specific context but run counter to the overarching goal or structure of the writing. It’s an endless swamp of advice that might be good. But a great editor hones in on the exact changes that work in service of the piece; they don’t make you wade through 50 good-to-mediocre ideas.
To me, this isn’t a problem of prompting better. Some of it is fundamental: A lot of editing is good taste, something that everybody working in AI swears up and down is the core human skill. For tasks that are not taste-bound, the technical machinery that would let an LLM interact with a document in a productive way does not exist.
Testing AI writing tools
I tried a few of the (many) collaborative AI writing tools on the market, and none of them worked for me.
I set up a simple evaluation: For an early stage research project, I had written a short memo to myself outlining the potential framing and contributions. I wouldn’t ask a human collaborator to edit this, but an AI editor could help sharpen the argument. I put together a list of AI editing tools and a basic prompt for my document: Comment on any places where the argument loses focus, and suggest changes for any awkward prose.
Many options were immediate non-starters. Lots of web-based text editors have AI built in, but they require separate subscriptions. I subscribe to ChatGPT and route work through Codex, so I want to connect to the powerful agent I already have. Superhuman Docs and Notion both have MCP servers, but they don’t do collaborative editing. Claude has a dedicated Word plugin that supports track changes and comments, but I didn’t have access to it through my institution-managed Microsoft account.
Other options supported the functionality I was looking for, but I struggled to set them up. In ODocs, the agent couldn’t figure out how to connect to a document or give suggestions in the interface. The same thing happened in Composer. Etherpad has plugins for AI, but they aren’t intuitive to set up. In general, I haven’t seen an established, functional pattern for even getting an agent to interact with documents, let alone provide useful feedback.
The most functional option I tried was the Proof editor from Every - I got Codex connected to the document and had it make edits. But there was still finicky machinery to contend with. The agent didn’t understand how to navigate the connection process, and document state kept losing changes. Technical instability aside, the implementation seemed promising for straightforward, single-pass document editing. Repeated rounds of edits in more complex documents would create a lot of heavy content and revision state, which I could see overwhelming the agent.
Based on what I’ve seen, there isn’t a working collaborative writing tool that cleanly integrates with AI agents. After hours of testing across multiple tools, I received zero usable comments or suggestions on my single page of writing.
Why is this so hard?
The failures I ran into point to a few fundamental challenges.
An LLM reads a long string of text. A document is a complex structured object with hierarchy, formatting, and other elements shaping and surrounding the text. When I open a draft, I take everything in at once. An agent gets the document flattened into prose, which strips the structure, or serialized with all the markup intact, which buries the prose. There’s active research in this area, but nobody has a good answer for handing an agent a document without losing one layer or the other.
Then, there’s a gap between the intent of a revision and its contents. Revision ideas start at a high level, with goals like “clarify this argument” or “make this section less repetitive.” Turning those goals into specific edits requires interpretation. A human editor can infer what I was trying to do from what I wrote, then make lots of small changes to support that goal. LLMs will happily rewrite a sentence, but they struggle to keep track of the larger goal of the rewrite.
There’s also a lot of technical cruft involved in getting an agent to interact with a new system. Protocols like MCP try to standardize this process, but introducing new tools to an LLM is always tricky - they don’t have any examples of how to use your bespoke document editing suite in their training data. The agent burns a bunch of its context window getting connected, reading tool descriptions, and understanding data structures before it even gets to the content of the document. The issue compounds over time as the agent has to navigate multiple rounds of tool calls, structured data responses, and substantive changes to the document.
None of this will stop people from using AI as an editor. We’ve all gotten good at improvising what we need out of prompt boxes, and there’s utility in pasting a draft into a chat window and asking what’s not working. But it’s a disservice to make a fundamental part of the writing process so difficult. Every switch between the chat and the document is a small tax on attention.
There are straightforward options to explore here. Skip remote document connection entirely and work on local Markdown files. Drop the MCP apparatus (skills beat tools) and represent revision state in CriticMarkup, a format that’s plain text and already in the training data. Pare down the machinery and build in just enough constraint to keep AI from taking over the whole process.
My students landed on AI-as-editor because it’s the position that respects the work. It’s also the only position that nobody has built for. It’s possible to edit in a chat window. It’s easy to delegate an entire draft to an agent. It will be much harder to build constraints that let us leverage the power of an AI editor on our terms.
Educational institutions are facing the issue of generative AI-assisted writing across all their training programs. Since generative AI makes it easier to delegate tasks than to collaborate, each program should define what students must learn to do independently before determining what the AI will be permitted to handle on their behalf. Instilling in them the understanding that they are—and will remain—accountable for any work produced with the help of generative AI is fundamental.