Why Writers Are Using Code Editors (And What They Actually Need)

Something weird is happening. Writers - essayists, researchers, bloggers, technical authors - are abandoning Google Docs and Word. They are not switching to Notion or some new AI writing app. They are switching to code editors. Specifically, Cursor and VS Code.

This sounds absurd. Code editors are for programmers. They have terminal panels, syntax highlighting, and bracket matching. Why would a writer choose that over a clean document editor?

Because code editors accidentally solved problems that writing tools have ignored for years.

Writers Who Made the Switch

Clark Dever wrote a whole blog post about why he writes with Cursor. His setup: a git-backed markdown repository where every blog post, style guide, and transcript lives in version control. He uses different AI models through Cursor's dropdown - Claude for nuance, GPT for speed - and treats AI as a collaborative editing partner. His goal was to ship one blog post per week for a year. Cursor made that possible.

He is not alone. On the Cursor community forum, researchers discuss using the editor for academic papers. Some write in markdown and convert to Word via Pandoc. Others compose LaTeX directly. One user built an entire workflow with Zotero citations and BibTeX references, all managed inside a code editor. These are not programmers dabbling in writing. They are writers who got tired of fighting their tools.

Why Code Editors Work for Writing

When you strip away the programming-specific features, code editors offer five things that writers desperately need.

1. Plain text (markdown) as the source of truth

Code editors treat your files as plain text. For writers, this means markdown. No proprietary format. No vendor lock-in. No mysterious blob that only one app can open. Your words live in files you can read with any text editor on any computer, forever.

This also means AI can work with your document natively. Every major language model - Claude, GPT, Gemini - thinks in markdown. When your document is already markdown, there is no translation step. The AI reads exactly what you wrote and edits it directly.

2. Inline AI diffs

This is the killer feature. In Cursor, you highlight text, describe what you want, and the AI produces a precise diff. Green for additions. Red for deletions. You accept or reject each change individually. You can see exactly what the AI touched and what it left alone.

Compare this to the ChatGPT workflow: copy a paragraph, paste it into the chat, get back a full rewrite, squint at it trying to figure out what changed, paste it back, fix the formatting. The inline diff model is so much better that writers will put up with a code editor just to get it.

3. @-references for context

Cursor lets you @-mention files in your AI prompts. Writing a conclusion? Type @introduction.md to give the AI your opening as context. Editing for consistency? Reference your style guide. This is a simple feature, but it solves a real problem: giving the AI enough context to make useful suggestions without pasting walls of text into a chat window.

4. Tab completion

As you type, the AI predicts what comes next and offers completions you can accept with Tab. For code, this autocompletes function names. For prose, it continues your sentences in your voice. It is surprisingly useful for getting past writer's block or finishing a thought that is half-formed in your head.

5. Git-style versioning

Every change is tracked. You can see the full history of your document, compare any two versions, and roll back to any point. Google Docs has version history too, but it is a flat timeline with no structure. Git gives you commits with messages, branches for experiments, and the ability to merge different versions together. For long-form projects, this is transformative.

Why Code Editors Do Not Work for Writing

All of that sounds great. So why isn't every writer using Cursor? Because code editors are built for code. They make serious compromises when you try to use them for prose.

No WYSIWYG

You see raw markdown. ## Heading instead of a formatted heading. **bold** instead of bold. [link](url) instead of a clickable link. For short blog posts, this is fine. For a 10,000-word essay with images, footnotes, and nested lists, reading raw markdown gets exhausting. You spend mental energy parsing syntax instead of focusing on your words.

No document structure tools

Writers need outlines, drag-and-drop section reordering, table of contents, and the ability to collapse sections. Code editors have file explorers and function outlines, but nothing designed for document structure. You can install a markdown outline extension, but it feels hacked together.

No writing-specific metrics

Word count, reading time, readability scores, sentence length distribution - writers rely on these. Code editors do not provide them. You can install extensions, but they are afterthoughts that break with updates.

Intimidating for non-technical users

Opening VS Code or Cursor for the first time is overwhelming. Terminal panels, activity bars, status bars, minimap, breadcrumbs. The interface assumes you know what a file tree is and are comfortable with keyboard shortcuts. Most writers just want a clean page and a blinking cursor.

No collaboration for non-technical users

Git is powerful, but try explaining branches and merge conflicts to someone who just wants to leave a comment on paragraph three. Code editors assume everyone on the team is a developer. Real-world writing involves editors, clients, and collaborators who have never opened a terminal.

What Writers Actually Need

The writers migrating to code editors are telling us something important. They are not in love with VS Code. They are in love with the principles: plain text, inline diffs, version control, AI as a first-class citizen. They want those principles in a tool built for writing.

Here is what that tool looks like.

Markdown under the hood

Store everything in markdown so AI can work with it natively. No proprietary formats, no vendor lock-in, no lossy translation between what the human sees and what the AI processes. This is the foundation that makes everything else possible. Markdown is the AI-native format.

WYSIWYG on top

Render that markdown as beautifully formatted text. Headings look like headings. Bold looks bold. Links are clickable. Images display inline. The writer never sees a # or a ** unless they want to. This gives you the readability of Google Docs with the AI compatibility of a code editor.

Inline AI diffs

The Cursor-style editing model applied to prose. Ask the AI to tighten a paragraph, and see exactly what it wants to change. Red strikethrough for deletions. Green highlight for additions. Accept or reject each edit with one click. This is what makes AI editing trustworthy - you stay in control.

Document versioning

Git-style version control without the terminal. Save named versions with descriptions. Compare any two versions with a visual diff. Restore previous versions with one click. Branch your document to try a different direction without losing the original. All of the power of git, none of the command-line overhead.

Real collaboration

Sharing and commenting that works for everyone, not just developers. Send a link, leave comments on specific paragraphs, suggest edits. No git knowledge required. Writers already know how to do this in Google Docs. The bar is set.

Import and export

Bring in your Google Docs, Word files, and existing markdown. Export to any format. Your writing tool should meet you where you are, not force you to start over. The whole point of markdown under the hood is that your content stays portable.

The Gap in the Market

Right now, writers are choosing between two bad options. Option one: traditional writing tools (Google Docs, Word, Notion) that have nice interfaces but treat AI as an afterthought. Option two: code editors (Cursor, VS Code) that have great AI integration but terrible writing experiences.

The writers using Cursor for prose are proof that the demand exists. They are willing to tolerate raw markdown, file trees, and terminal panels just to get inline diffs and version control. Imagine how much better it could be with a tool designed for them from the start.

That is what we are building with Athens. A writing editor that takes the best ideas from code editors - markdown storage, inline AI diffs, document versioning - and wraps them in an interface designed for writers. No terminal. No file trees. No raw markdown. Just the writing experience you want, with the AI integration you need.

The future of writing tools is not Google Docs with a chatbot bolted on. It is not VS Code with a markdown preview panel. It is something new - built on the principles that writers are already voting for with their feet.