A useful design principle is: borrow interaction models from mature creative tools, not just AI chat interfaces. Chat is poorly suited to writing because it is linear, verbose, and constantly competes for attention.
Sources of inspiration
IDEs and language servers
The most valuable IDE idea may not be autocomplete, but the separation between:
- the editor
- a background semantic model
- diagnostics
- explicit “code actions”
A writing equivalent of the Language Server Protocol could expose a standard set of objects:
- document → section → paragraph → sentence → phrase
- claim, evidence, quotation, citation, definition
- person, organization, date, event
- unresolved note or question
Tools could then provide diagnostics without controlling the editor. A claim checker, citation manager, style analyzer, and argument mapper could all plug into the same protocol.
Crucially, diagnostics should be pull-based. Rather than placing red squiggles everywhere, the writer presses a key to enter review mode and reveal them.
IDE features that transfer well:
- command palettes
- user-defined actions
- project-wide symbol search, adapted to concepts and claims
- “find references” for an idea or assertion
- rename/refactor for terminology
- warnings with optional quick fixes
- semantic diffs
- test suites, in the form of custom editorial checks
- task-specific agents with restricted tools and context
For example, “rename symbol” becomes: “I’ve used agency, autonomy, and control inconsistently. Show every occurrence and let me normalize or deliberately distinguish them.”
Vim and Emacs
Vim contributes modal, composable operations. Emacs contributes the idea that the environment is programmable by the user.
The important Vim abstraction is not merely visual selection. It is operator + scope:
- critique paragraph
- compress section
- source claim
- concretize sentence
- challenge argument
- compare passage
- vary rhythm across selection
Scopes could include semantic units as well as textual ones:
- current claim
- supporting evidence
- all paragraphs serving the same function
- every use of a concept
- every passage derived from a particular source
A grammar like action → object → constraint would be more powerful than a long prompt menu:
Compress → section → preserve examples
Challenge → claim → as domain expert
Rephrase → sentence → preserve cadence and diction
Emacs suggests that commands, keybindings, models, context providers, and display modes should all be replaceable. Writers will invent workflows the product designer cannot anticipate.
DAWs and nonlinear video editors
Digital audio workstations may be a better analogy than IDEs. They are designed for creative work where there is no objectively correct output.
Useful concepts include:
- non-destructive editing: every transformation creates a take, never silently replaces the original
- comping: choose the best phrases from several versions
- tracks: separate prose, citations, notes, counterarguments, and editorial comments
- automation lanes: visualize pacing, sentence length, abstraction, sentiment, or narrative tension
- solo/mute: temporarily hide footnotes, examples, caveats, or editorial annotations
- markers: identify thesis turns, reveals, callbacks, and unresolved questions
- scrubbing: move quickly through an essay’s semantic progression
A writer might generate three possible transitions, audition them in place, and accept one without entering a chat conversation.
CAD and parametric design
CAD tools distinguish the underlying model from a particular rendering. Writing systems could do the same.
An essay might have explicit constraints:
- 1,500 words
- general audience
- thesis visible by paragraph four
- every major claim sourced
- one concrete example before extended abstraction
- preserve a particular opening and closing
- avoid introducing terminology after the midpoint
The system could show which constraints a revision violates. It could also render the same body of thought as an essay, talk, memo, thread, or annotated outline without treating any one representation as canonical.
Version control
Ordinary track changes is too local. Writers need version control that understands intention.
Useful features would include:
- branches for different theses or structures
- snapshots labelled by editorial goal
- paragraph- and claim-level history
- semantic rather than merely textual diffs
- the ability to restore a deleted line independently of later edits
- comparison of “what changed in the argument?” rather than only changed words
- provenance for human- and model-written text
A semantic diff might report:
This revision weakens the causal claim, removes the main objection, adds one example, and changes the intended audience from specialist to general.
Branches are especially valuable in writing because writers often resist experiments for fear of damaging a draft. Cheap, visible reversibility encourages bolder revision.
Debuggers and profilers
A debugger lets programmers inspect a system at the point where it fails. A prose debugger could let a writer stop at a sentence and ask:
- What must the reader already believe for this to work?
- Which earlier claims does this depend on?
- Where was this term introduced?
- What evidence supports it?
- What is the strongest inference the reader can legitimately draw?
- What objections become available here?
A profiler asks where resources are being spent. Its writing counterpart could reveal:
- where the reader’s working memory is overloaded
- stretches with too many new concepts
- repeated setup with insufficient payoff
- sections consuming disproportionate word count
- long distances between a promise and its resolution
- places where abstraction remains high for too long
Spreadsheets and data visualization
Writers often need alternate projections of the same text. Your sentence-per-line mode is a strong example.
Other views could include:
- paragraph purpose in one column, text in another
- claims matched to evidence
- sources matched to passages that rely on them
- sentence length as a sparkline
- abstraction/concreteness heatmaps
- timeline view for narrative or historical essays
- character or entity presence across the document
- lexical repetition map
- section word-count treemap
- “first mention” map for concepts
- only the first and last sentence of each paragraph
The key is that these are views, not alterations to the document.
Scrivener, Obsidian, outliners, and research tools
Scrivener’s corkboard, Obsidian’s links, Workflowy’s zoomable outline, and tools such as LiquidText suggest that source material should live close to the draft without invading it.
A research pane could support:
- dragging quotations into an evidence bank
- preserving page numbers and source provenance automatically
- linking notes to claims rather than merely to documents
- distinguishing quotation, paraphrase, inference, and the writer’s own observation
- seeing unused research
- identifying claims backed by only one source
- tracing a sentence back through notes to its source
This is one place where a harness can outperform a plain text editor dramatically.
Some new primitives
The “editorial lens”
Instead of one universal review, users activate a temporary lens:
- argument
- rhythm
- clarity
- evidence
- originality
- audience
- structure
- voice
- fact consistency
Each lens changes both the visible annotations and the available commands. This avoids the cockpit effect where every metric is shown at once.
A shortcut reveals a lens; Esc returns to clean prose.
A personalized test suite
Writers could create persistent checks such as:
- Flag paragraphs containing more than one rhetorical question.
- Find places where I qualify a claim three times.
- Show abstract nouns unsupported by examples nearby.
- Check that I do not caricature the opposing view.
- Warn when three consecutive sentences share a syntactic opening.
- Find conclusions that merely restate the introduction.
- Show every factual claim lacking a source.
These should report findings, not automatically rewrite text. Over time, they become the writer’s own editorial discipline encoded as tools.
Semantic folding
Code editors fold functions; writing editors could fold by rhetorical role.
A writer might reduce the document to:
- thesis statements only
- first sentences of paragraphs
- claims and objections
- examples only
- quotations only
- section summaries
- narrative events
- unresolved questions
This would make structural problems visible without asking a model to explain them in a page of prose.
Reader simulation with receipts
“Simulate a reader” is useful only if the feedback is anchored.
Instead of generic commentary, the tool could maintain a reader-state timeline:
- what the reader is presumed to know
- what questions are currently open
- what terms have been introduced
- what promises the essay has made
- what the reader may expect next
- where two interpretations become possible
Clicking a diagnosis should reveal the specific textual evidence behind it.↳ Narrate Tool
A friction ledger
While drafting, the writer can hit a single key to leave a lightweight marker:
- verify
- source
- weak
- transition
- example
- name this
- return later
No dialog appears and focus does not move. Later, review mode turns those markers into a queue. This preserves flow while capturing the writer’s own momentary judgment, which is often more valuable than an AI-generated diagnosis.
Voice preservation
A “voice model” should not simply imitate a sample. It should expose the writer’s tendencies as editable dimensions:
- sentence-length distribution
- preferred syntactic shapes
- ratio of concrete to abstract language
- degree of qualification
- characteristic transitions
- humor and irony
- use of fragments
- rhythm and punctuation
- distance from the reader
- common rhetorical moves
- words or constructions the writer avoids
The system can learn this from accepted prose, but the writer should be able to inspect and correct the profile.
More importantly, AI edits should default to minimal transformations. Rather than “rewrite this better,” tools should offer operations such as:
- remove redundancy without changing syntax unnecessarily
- make the referent explicit
- replace only the cliché
- shorten by 15% while preserving sentence rhythm
- produce alternatives, not a replacement
- explain the problem without drafting prose
A useful voice feature would highlight “style drift”: passages that differ sharply from the writer’s established patterns, including model-generated passages that suddenly become polished in a generic way.
Be careful with an “originality score”
Embeddings can detect semantic similarity, but semantic distance is not originality. A sentence can be unlike anything in the comparison corpus and still be banal; it can resemble an existing formulation while making a genuinely original argument.
It would be better to separate several signals:
- internal semantic repetition: where the essay says the same thing twice
- phrase overlap: similarity to sources or a reference corpus
- conceptual novelty: whether a paragraph introduces a new claim or relation
- predictability: clichés and highly conventional continuations
- argument contribution: whether the sentence changes what the reader can conclude
- specificity: whether it supplies concrete information
- source dependence: how closely phrasing follows research material
Call these diagnostics rather than combine them into a dubious 73/100 originality number. Their most useful form may be a map showing where the essay is advancing, elaborating, repeating, qualifying, or merely transitioning.
The interaction contract
The product should probably have three states:
- Draft: plain text, zero unsolicited intervention.
- Inspect: optional overlays and alternate views.
- Act: explicit commands applied to a chosen scope.
Background indexing is fine; background interruption is not. No popups, spontaneous completions, animated assistants, or red squiggles in draft mode. Every action should be reversible, inspectable, and attributable.
The deepest lesson from Vim, Unix, and programmable harnesses is that the product should offer a small set of composable primitives, not a giant catalog of “AI writing” buttons. The ideal experience is less like consulting a chatbot and more like having a programmable editorial instrument that becomes invisible until summoned.