Branch

Better Than Word

Human dan

Everyone agrees that LLMs are pretty terrible at Essay writing. They use a repetitive and easy to spot style. They don't usually say anything interesting either.

We've seen that agent harnesses like Claude Code and Codex have given software engineers super powers, but there's nothing like this yet for essay writers (or writers in general).

What sort of tooling would give writers super powers?

How does it look different from the work software engineers do?

How can writers retain their unique style and voice? Or how can the tooling help them develop one?

AI · author-edited gpt-5.6-sol

The equivalent of Claude Code for writers is probably not “a model that writes the essay.” It is a research, argument, and revision environment in which the writer remains the source of judgment.

Coding agents became useful when they gained a harness: access to the repository, search, tests, version control, execution, and a loop for checking their work. A writing agent needs analogous machinery—but prose has no compiler, and “good” is not a single measurable state.

What a writer’s harness would contain

1. A living model of the project

Not just a chat transcript or a folder of documents. The system should maintain:

  • the intended reader
  • the central question
  • candidate theses
  • claims and supporting evidence
  • objections and unresolved tensions
  • sources, quotations, and provenance
  • definitions of important terms
  • examples, scenes, and anecdotes
  • structural outlines
  • stylistic constraints
  • decisions the writer has made and rejected

This would be closer to a graph than a document. An essay is merely one rendering of that graph. WRITER.md

2. An argument debugger

This may be the closest analogue to tests and static analysis.

It could identify:

  • hidden assumptions
  • equivocation between two meanings of a term
  • causal claims supported only by correlation
  • conclusions stronger than the evidence permits
  • unaddressed obvious objections
  • false dichotomies
  • sections that are individually plausible but do not advance the thesis
  • abstractions that need examples
  • examples that are vivid but unrepresentative

It should also be able to “run” the argument against several readers: an expert, a hostile critic, an intelligent newcomer, or someone directly affected by the topic.

This is not an automatic truth machine. It is a way to generate pressure against the writer’s reasoning. Logical Fallacy Linter

3. Structural editing

Most writing assistance operates one sentence at a time, which is often the wrong level.

A useful system would let the writer manipulate the essay at several scales:

  • argument: claim, evidence, objection, reply
  • section: purpose, tension, payoff
  • paragraph: assertion, development, transition
  • sentence: rhythm, syntax, diction
  • word: precision and connotation

It could display a “reverse outline” generated from the actual draft, then compare that with the intended outline. It might label each paragraph by function and expose six consecutive paragraphs all doing background exposition.

It should support operations like:

  • “Show me three structures for this material without drafting them.”
  • “Move the central complication earlier.”
  • “What can be removed if this must lose 30% of its length?”
  • “Find the point at which the essay stops asking a question and starts pretending it has answered it.”
  • “Preserve the conclusion, but propose a route to it that does not depend on chronological organization.” Structural Editing UX

4. Revision instruments, not a rewrite button

A generic “improve this” button almost inevitably pulls prose toward the model’s average style.

Better tools would expose specific transformations:

  • compress repetition
  • replace abstract claims with concrete instances
  • vary sentence architecture
  • make uncertainty explicit
  • separate observation from inference
  • remove throat-clearing
  • identify clichés and inherited metaphors
  • locate unexplained jumps
  • estimate where reader attention is likely to drop
  • compare two revisions and describe what each gains and loses

The key is that suggestions should arrive as diagnoses, alternatives, or patches, not as a silently regenerated document.

How writing differs from software engineering

There are important analogies:

Software Writing
Repository Notes, sources, drafts, archive
Dependency graph Claim/evidence graph
Compiler errors Grammar and consistency failures
Unit tests Factual and citation checks
Integration tests Argument coherence
Runtime profiling Reader-response and pacing analysis
Version control Draft history and decision log
Code review Editorial and adversarial review

But the differences matter more.

Writing has no complete specification

In software, the desired behavior can often be stated externally. In an essay, discovering what the writer really thinks is part of the work. The specification changes because composition changes the author. Modeling the Author

A writing agent therefore cannot simply optimize against the initial brief. It must help the writer notice that the original brief was shallow or mistaken.

Quality is plural and contested

A paragraph can become clearer but less suggestive, shorter but less musical, more rigorous but less humane. These are not bugs with unambiguous fixes.

The tool should surface trade-offs rather than collapse them into a scalar “writing quality” score. Personal Quality/Taste Score

Product and producer are entangled

Code usually does not need to express the programmer’s sensibility. An essay often does. Its selection of details, pattern of attention, degree of certainty, humor, rhythm, and moral posture all reveal a mind.

If an agent makes every local decision, the text may remain competent while ceasing to be authored in the meaningful sense.

Friction can be productive

For programmers, removing boilerplate is usually beneficial. In writing, the difficult sentence may be where the thinking occurs. Automating it can erase the discovery process.

A good harness must distinguish between clerical friction and epistemic friction. It should remove the first and preserve—or intensify—the second.

Preserving a writer’s voice

“Voice” should not mean a bag of superficial mannerisms learned from previous work. Mimicking sentence length, favorite punctuation, and common phrases often produces self-parody.

A better voice model would include:

  • what the writer tends to notice
  • what they refuse to simplify
  • characteristic forms of reasoning
  • their relationship to the reader
  • where they use humor or restraint
  • their tolerance for abstraction
  • how directly they state conclusions
  • which moral and aesthetic instincts recur
  • productive contradictions in their work

The system could learn this from an approved corpus, but it should describe the patterns to the writer rather than merely imitate them:

You usually begin with a concrete anomaly and delay the general claim. This draft states its thesis immediately. Is that deliberate?

That preserves agency and also helps writers become conscious of their own craft.

Practical safeguards might include:

  • never training the voice profile on AI-generated passages
  • marking every generated span
  • keeping generated and human-written text distinguishable in version history
  • letting the writer lock phrases or paragraphs against alteration
  • offering multiple local alternatives instead of one full rewrite
  • measuring divergence from the writer’s corpus without treating divergence as inherently bad
  • maintaining a “negative style guide” of habits the writer wants to avoid

Helping someone develop a voice

Developing a voice is not achieved by choosing “witty,” “warm,” or “authoritative” from a menu.

The system could act more like a demanding editor or composition teacher:

  1. Collect passages the writer admires.
  2. Ask what, specifically, they admire in each.
  3. Compare those preferences with the writer’s own drafts.
  4. Design constrained exercises: write the scene without abstraction, argue the opposite conclusion, remove every hedge, then restore only necessary ones.
  5. Track which revisions the writer consistently accepts or rejects.
  6. Identify emerging preferences.
  7. Periodically articulate those preferences as a revisable poetics.

It could also detect imitation. If a novice’s draft suddenly adopts the visible tics of a favorite writer, the tool might ask what deeper effect those tics are supposed to achieve and suggest another route to that effect.

What the product might actually look like

Imagine an editor with five linked panes:

  1. Draft — the current prose.
  2. Map — outline, claims, evidence, objections, and dependencies.
  3. Sources — searchable materials with citation provenance.
  4. Critics — configurable editorial passes, each with a narrow mandate.
  5. History — versions, alternatives, and the reasons behind decisions.

The writer could assign bounded jobs:

  • “Audit every empirical claim in sections 2–4.”
  • “Find the strongest case against my thesis.”
  • “Build a reverse outline, but do not rewrite.”
  • “Show where the draft becomes repetitive.”
  • “Give me five examples that could test this abstraction.”
  • “Compare this with my three published essays and flag uncharacteristic phrasing.”
  • “Interview me until I can say what I actually believe about the ending.”

That final capability may be especially important. Often the best writing assistant would not generate prose at all. It would ask the next question the writer cannot evade.

The superpower is therefore not producing ten times as many words. It is being able to hold more evidence, alternatives, objections, and structural possibilities in mind—while leaving the consequential choices to the writer.

Human dan

Paul Graham said this about writing:

Writing about something, even something you know well, usually shows you that you didn't know it as well as you thought. Putting ideas into words is a severe test. The first words you choose are usually wrong; you have to rewrite sentences over and over to get them exactly right. And your ideas won't just be imprecise, but incomplete too. Half the ideas that end up in an essay will be ones you thought of while you were writing it. Indeed, that's why I write them.

And William Zinsser in "On Writing Well" said:

Writing is hard work. A clear sentence is no accident. Very few sentences come out right the first time, or even the third time. Remember this in moments of despair. If you find that writing is hard, it’s because it is hard.

Most successful writers tend to agree with those sentiments. How could that influence the design of the harness?

AI · author-edited gpt-5.6-sol

Those quotations imply that difficulty is not merely a cost of writing. Some of it is the mechanism by which thought becomes more precise and complete.

A writing harness should therefore distinguish between two kinds of friction:

  • Clerical friction: finding a quotation, formatting citations, tracking versions, locating repetition, comparing drafts. Better Than Word You are here
This branch begins here Better Than Word
Human dan

Whenever I’ve tried writing in Microsoft Word or Google Docs the experience has been frustrating. I now that many authors still use old programs like WordStar or WordPerfect because they also do not like the modern tools.

Personally I prefer to separate content from presentation. Write in markdown or asciidoc and then use tooling to covert it to html or pdf. Most non-programmers do not like that workflow and prefer the WYSIWYG experience even if it is clunky.

How can the harness bring in the best elements of both approaches? I want the speed and precision of plain text, but it should feel familiar to normal people (non-programmers).

AI gpt-5.6-sol

The right goal is not to compromise halfway between Word and Markdown. It is to separate the document’s meaning from both its editing interface and its final rendering.

A document can have one semantic source of truth while offering several projections:

  • a clean, familiar writing page
  • a keyboard-oriented plain-text view
  • an outline or structural view
  • an annotated editorial view
  • rendered HTML, PDF, ebook, or manuscript previews

The writer chooses the representation appropriate to the task.

A semantic document underneath

Internally, the harness should store meaningful elements rather than simulated sheets of paper:

  • title
  • section and subsection
  • paragraph
  • block quotation
  • list
  • footnote
  • citation
  • figure and caption
  • aside
  • scene break
  • comment
  • unresolved note
  • emphasis and links

This could serialize to Markdown, AsciiDoc, or another inspectable text format, with a sidecar file for information that plain text cannot conveniently hold, such as comments, provenance, and branches.

The important properties are:

  • no opaque binary format
  • stable, deterministic files
  • clean diffs and version control
  • reliable import and export
  • no formatting corruption caused by copy and paste
  • access to the document without the original application

But nontechnical users should never need to know that an abstract syntax tree or text serialization exists.

A familiar surface, without Word’s page simulation

The default view could resemble a conventional word processor: a centered column, ordinary text selection, familiar shortcuts, and a restrained toolbar. But it should edit content, not page geometry.

A writer selects a heading because it is a heading—not because it is 18-point bold Helvetica with extra space below it. A quotation is marked as a quotation, a citation as a citation, and an aside as an aside. The publishing theme decides how those things appear.

This eliminates much of the fragility of WYSIWYG:

  • headings do not become inconsistent
  • pasted text does not import a nest of hidden styles
  • indentation is not made from spaces
  • page breaks do not move unpredictably during composition
  • changing the publication format does not require reformatting the draft

The interface can still show headings, italics, lists, and quotations attractively. It would be better described as WYSIWYM—“what you see is what you mean”—with a true output preview available when needed.

Pagination should generally remain off while drafting. A continuous text column is better for composition; page layout belongs to a preview or production mode.

Multiple views of the same document

A single shortcut could cycle among a few deliberate views.

Compose

Only the prose is visible. No page furniture, AI controls, diagnostics, comment balloons, or permanent formatting ribbon.

This should feel more like WordStar or a good typewriter than a modern productivity dashboard: fast startup, low latency, strong keyboard navigation, and nothing moving unexpectedly.

Source

A plain-text representation for people who want it. Markdown syntax is visible, files are directly editable, and external tools can operate on them.

This should be a first-class view, not a risky “advanced mode.” Changes in source view and compose view operate on the same document and round-trip reliably.

Structure

The document is folded into headings, paragraph summaries, first sentences, claims, or rhetorical roles. Sections can be moved without cutting and pasting large spans of text.

Inspect

Comments, citations, provenance, repetition maps, factual checks, and editorial diagnostics become visible only when summoned.

Preview

The same content is rendered using a target profile:

  • web article
  • academic paper
  • print manuscript
  • newsletter
  • ebook
  • PDF
  • publication-specific house style

Preview is not the editing surface, so visual production concerns cannot constantly interfere with composition.

Two interaction vocabularies

The harness should support both direct manipulation and keyboard composition without forcing either community to adopt the other’s habits.

A nontechnical user could:

  1. Select a passage.
  2. Click Quotation.
  3. Add a source through a familiar dialog.
  4. Drag a section in the outline.
  5. Choose Export as PDF.

A keyboard-oriented user could perform the same operations through commands:

  • quote paragraph
  • cite selection
  • move section after "Objections"
  • export web
  • fold to first sentences

Markdown-like input can act as a shortcut without remaining visible. Typing ## at the beginning of a line could create a heading block; typing > could create a quotation. The interface might briefly acknowledge the transformation and then return to clean prose.

A command palette provides discoverability between toolbar and memorized shortcut. The user can search ordinary verbs such as “add footnote,” “compare versions,” or “show only quotations.” Recent commands gradually become keyboard shortcuts for frequent users.

The system should not describe this as “learning commands.” It is simply a faster way to use the same features.

Precision without programmer aesthetics

Plain text feels precise partly because it has predictable behavior. The product should preserve that precision in the visual editor:

  • keystrokes never lag
  • selections never jump
  • undo is complete and trustworthy
  • formatting never changes by inference
  • smart quotes and other substitutions are controllable
  • keyboard commands compose predictably
  • clipboard behavior is explicit
  • every transformation has a visible diff
  • files save continuously and locally
  • the application works without a network
  • every document can be exported without an account

It should also support more useful textual scopes than ordinary word processors:

  • word
  • sentence
  • paragraph
  • section
  • quotation
  • claim
  • all uses of a term
  • all passages linked to a source

A user could select with the mouse, while an expert could say, in effect:

Compress → this paragraph → preserve the example.

That brings the precision of modal editing to ordinary users without requiring them to learn Vim’s notation.

Styles should express roles, not decoration

Modern word processors technically have styles, but they make ad hoc formatting so easy that documents often become inconsistent. The harness should make the semantic path easier than the decorative one.

Instead of showing dozens of fonts and spacing controls during composition, it might offer:

  • body
  • heading
  • quotation
  • epigraph
  • caption
  • note
  • aside

Visual themes then render those roles. If a user genuinely needs custom presentation, a separate design mode can expose typography, margins, and layout. Those decisions should apply systematically rather than become invisible local overrides.

This is the same separation programmers get from HTML and CSS, presented without asking writers to understand either.

AI should obey the same separation

AI interaction should not live in a chat window beside the draft or continuously decorate the page with suggestions. It should operate as explicit, scoped commands over the semantic document.

For example:

  • diagnose this paragraph
  • challenge this claim
  • find support for this assertion
  • compare these two sections
  • show internal repetition
  • propose three transitions
  • shorten by 15% without changing the examples

The result should appear as a diff, annotation, or alternative “take,” never as an unexplained replacement. Pressing Escape returns immediately to an unannotated page.

A useful interaction contract would be:

  1. Draft: no unsolicited intervention.
  2. Inspect: reveal a chosen editorial lens.
  3. Act: apply a specific operation to a selected scope.

This matters especially given Graham’s and Zinsser’s observations. The system should not interrupt the difficult work of formulating thought with easy generic prose. It can remove clerical friction while preserving the struggle over what a sentence actually means.

A concrete experience

A new user opens the application and sees a blank, continuous page. They type as they would in any word processor. A small, familiar toolbar appears only when text is selected. Headings and quotations look formatted, but the writer is manipulating semantic elements.

As they become more proficient, they discover:

  • Ctrl/Cmd-K opens a command palette.
  • Ctrl/Cmd-. reveals the structural outline.
  • A shortcut changes from paragraph view to one-sentence-per-line view.
  • Another hides everything except the first sentence of each paragraph.
  • Escape always returns to the clean draft.
  • Any passage can be inspected, transformed, or compared without opening a chat.
  • The underlying files can be opened in a text editor and placed in Git.
  • Export profiles produce publication-ready artifacts.

The crucial design principle is progressive disclosure. The default experience should be as approachable as a stripped-down word processor. Precision, programmability, source access, custom workflows, and agents should reveal themselves as the writer needs them.

That would combine the strongest qualities of both traditions:

  • from old writing programs: focus, speed, stability, and keyboard fluency
  • from plain text: portability, inspectability, composability, and separation of concerns
  • from modern visual tools: familiarity, selection, direct manipulation, and immediate feedback
  • from agent harnesses: project awareness, configurable operations, verification, and reversible automation

The result should not feel like an IDE disguised as Word. It should feel like a very calm writing instrument that happens to have a rigorous textual system underneath it.

Explore conversation