Ansprechbare Dokumente: Ihr Dokument hört zu

Menschen bauen heute Software, indem sie mit ihrem Handy reden. Nicht in irgendeiner nahen Zukunft, sondern jetzt, in der Gegenwart. Das Muster begann am Desktop: Im Februar 2025 nannte Karpathy es „Vibe Coding“, er sprach per SuperWhisper in den Composer von Cursor und rührte die Tastatur kaum an. Seither ist es aufs Handy gewandert. Jemand geht mit dem Hund spazieren, hält die Mikrofontaste gedrückt, sagt „Bau beim Suchfeld ein Debounce ein und setz den Lade-Spinner in das Feld statt daneben“, und eine funktionierende Änderung landet im Repository. Ergonomisch ist das ganz offensichtlich verkehrt: Auf einem Handydisplay liest man Code schlecht, die Spracherkennung verstümmelt Symbolnamen, das Modell benennt gelegentlich eine Funktion um, die Sie gar nicht umbenannt haben wollten. Und trotzdem schließt sich die Schleife. Die Leute liefern.

Das fühlt sich neu an. Es ist auch neu. Aber es ist zugleich der schwierigere Fall. Der einfachere Fall sind Dokumente.

Dokumente sind die einfache Variante

Alles, was das Bauen von Software per Stimme schwierig macht, fällt weg, sobald Sie „Software“ durch „Dokument“ ersetzen:

• Software hat Zustandsautomaten, Build-Systeme, Deploy-Pipelines und tausend dateiübergreifende Invarianten. Ein Dokument hat Struktur und Prosa. Prosa kennt das Modell schon jetzt besser als jedes Framework.
• Software muss irgendwo laufen. Ein Dokument läuft nirgends. Es existiert einfach, und das Öffnen ist das gesamte Deployment.
• Software scheitert auf hundert subtile Arten. Ein Dokument scheitert, indem es falsch aussieht, und das sieht der Benutzer schon in der nächsten Sekunde.
• Software braucht Tests. Ein Dokument muss sich richtig lesen.

Wer auf dem Handy per Stimme eine App programmieren kann, kann dort auch per Stimme ein Dokument verfassen, und das zweite ist strukturell einfacher. Dass es das erste schon gibt und das zweite noch nicht, ist ein Hinweis darauf, dass etwas anderes im Weg stand. Im Weg stand, dass Dokumente in Anwendungen leben, die nie dafür gebaut wurden, dass man mit ihnen spricht.

Diktieren ist nicht Anweisen

Word hat eine Mikrofontaste. Google Docs auch. Beide transkribieren. Sie sprechen, und was Sie gesagt haben, erscheint als Text im Dokument, Zeichen für Zeichen.

Das ist nicht dasselbe.

Diktieren heißt Ich tippe mit dem Mund. Anweisen heißt Ich beschreibe, was ich will, und das Dokument wird dazu. Das sind verschiedene Verben auf verschiedenen Ebenen. Diktieren läuft auf derselben Ebene wie die Tastatur: Es erzeugt Zeicheneingaben. Anweisen läuft eine Ebene darüber: Es erzeugt Änderungen am Dokument. Das erste braucht ein Mikrofon. Das zweite braucht ein Mikrofon und ein Modell und eine Ausführungsebene im Dokument, die eine Anweisung wie „Straff den zweiten Absatz und zieh die Aufzählung in einen Hinweiskasten“ entgegennehmen und umsetzen kann.

Die Ausführungsebene ist das fehlende Stück. Word hat keine. Google Docs hat keine. Die Office-Suite hatte nie eine. Sie setzte eine Tastatur voraus, weil 1985 eine Tastatur das Einzige war, was jemand beim Schreiben zu einem Dokument mitbringen würde, und als die Annahme falsch wurde, hatte niemand Lust, die Suite neu zu bauen.

Die Form des fehlenden Stücks

Genau hier hat reWritable die richtige Form.

Ein reWritable-Dokument ist eine einzelne HTML-Datei mit eingebettetem LLM und einer ⌘K-Rewrite-Schleife. Sie drücken ⌘K, tippen eine Anweisung, das Modell erhält das Dokument, liefert eine geänderte Fassung zurück, und die Datei rendert sich an Ort und Stelle neu. Der vorherige Beitrag dazu hat argumentiert, dass das Dokument dadurch zu seiner eigenen Anwendung wird: Die Datei, die Ihnen auf Ihrer Festplatte gehört, ist dieselbe Datei, die Sie bearbeiten, indem Sie mit ihr sprechen. Dieses Argument betraf die Architektur.

Hier geht es um das Eingabegerät. ⌘K ist ein Tastendruck. Das muss es aber nicht sein. Dieselbe Schleife nimmt Sprache an, sobald Sie ihr ein Transkript geben, und auf dem Handy erzeugt das Betriebssystem dieses Transkript ohnehin, wenn Sie aufs Mikrofon tippen. Die Teile greifen ineinander:

Schicht	Was sie Ihnen gibt
Das Handy	Ein Mikrofon, immer dabei und bereit
Das Betriebssystem	Spracherkennung, bereits integriert
Das Modell	Das Befolgen von Anweisungen
Das Dokument	Eine Rewrite-Schleife in der Datei, die Anweisungen in Änderungen verwandelt

Zum ersten Mal in der Geschichte des Dokuments als Artefakt sind alle vier an einem Ort vorhanden. Die Tastatur-Ära des Verfassens ergab sich daraus, welche dieser Schichten es gab. Die Sprach-Ära ergibt sich daraus, dass alle vier gleichzeitig da sind.

Wie das in der Praxis aussieht

Sie sitzen im Zug. Sie öffnen proposal.html auf dem Handy. Sie halten die Mikrofontaste gedrückt.

„Streich den Abschnitt mit den Umsatzprognosen. Füg am Ende einen Absatz zum Zeitplan für den Rollout ein: Q1 Onboarding, Q2 Ausbau, Q3 Überprüfung.“

Sie lassen los. Das Dokument rendert sich neu. Die Umsatzprognosen sind weg. Ein neuer Schlussabsatz nennt die drei Quartale. Sie überfliegen ihn, drücken wieder aufs Mikrofon („Formulier den Rollout-Absatz zurückhaltender, sag ‘gezieltes Onboarding’ statt einfach nur Onboarding, und versprich nichts für Q3, sag nur, dass wir evaluieren werden“) und lassen los. Es schreibt um. Sie lesen es. Es passt.

Sie kommen ins Büro. Sie öffnen dieselbe Datei am Laptop. Sie ändern einen Satz von Hand. Sie schicken sie ab. Der Empfänger bekommt die Datei aufs Handy, öffnet sie, hält die Mikrofontaste gedrückt und stellt dem Dokument eine Frage über sich selbst. Das Dokument antwortet. Er tippt noch einmal aufs Mikrofon und bittet um eine Änderung. Das Dokument ändert sich.

So funktionieren Dokumente derzeit nicht. Machbar ist das alles heute schon mit Software, die es bereits gibt: Datei als Dokument, eingebettetes LLM, Spracheingabe auf Betriebssystemebene. Dass es noch nicht Alltag ist, liegt daran, dass das Dokument keinen Platz für das Mikrofon hatte. Eine reWritable-Datei hat ihn.

Die Einwände, die kommen

„Ich kann Word doch schon diktieren.“ Diktieren erzeugt Text an der Cursorposition. Sprachanweisungen erzeugen Änderungen auf Dokumentebene: umstrukturieren, den Ton ändern, umformulieren, neu rendern. Das ist nicht dieselbe Schleife. Das eine ist eine Eingabemethode, das andere eine Methode des Verfassens.

„Stimme ist zu ungenau für ernsthafte Dokumente.“ Die Ungenauigkeit entsteht vor dem Modell. Sie spielt keine Rolle, weil das Dokument auf dem Bildschirm steht und das Ergebnis in der nächsten Sekunde sichtbar ist. Ungenaue Eingaben sind in Ordnung, wenn die Rückmeldung sofort kommt. Die Schleife ist so kurz, dass Sie korrigieren, indem Sie es noch einmal sagen, so wie Sie einen Satz korrigieren, indem Sie ihn noch einmal tippen.

„Ich werde doch keine Steuererklärung auf dem Handy schreiben.“ Sie werden sie auch nicht auf dem Handy schreiben. Sie werden sie auf dem Handy fertigstellen: die Zeile, die Sie vergessen haben, das Feld, das Sie klarer fassen wollen, den Absatz, den Sie vor dem Abschicken abschwächen wollen. Entscheidend ist diese Asymmetrie: Die meisten Momente, in denen man etwas ändern will, finden nicht am Schreibtisch statt. Sie finden im Taxi statt, in der Küche, um 11 Uhr nachts im Bett. Das an den Schreibtisch gebundene Dokument ist das, an das Sie genau in dem Moment nicht herankommen, in dem Sie es ändern wollen.

„Das wird eine Menge schlechter Dokumente hervorbringen.“ Es wird schlicht mehr Dokumente hervorbringen, weil das Verfassen in Momenten möglich wird, in denen es bisher nicht möglich war. Manche davon werden schlecht sein. Das war auch so, als die Tastatur die Schreibmaschine ablöste und die Schreibmaschine den Federkiel. Die Frage ist nicht, ob die neue Form auch schlechte Arbeit hervorbringt, sondern ob sie Menschen, die bisher überhaupt keine Dokumente verfassen konnten, damit anfangen lässt.

Was sich dadurch ändert

Der Autor ist nicht mehr jemand, der sich zum Schreiben hinsetzt, sondern jemand, der ein Dokument am Laufen hält wie ein Gespräch. Das Bearbeiten löst sich vom Sitzen am Schreibtisch. Die Fähigkeit, auf die es ankommt, heißt nicht mehr „die Textverarbeitung bedienen“, sondern „die gewünschte Änderung beschreiben“. Diese Fähigkeit ist in der Bevölkerung viel gleichmäßiger verteilt, als es die erste je war.

Auch die Geografie des Verfassens ordnet sich dadurch neu. Die Desktop-Textverarbeitung war um einen einzelnen Arbeitsplatz herum gebaut: eine Maschine, eine Tastatur, ein Bildschirm, ein Benutzer mit zwei freien Händen. Einem ansprechbaren Dokument ist es egal, wo Sie sind. Dasselbe Artefakt reagiert auf die Tastatur am Schreibtisch, auf Ihre Stimme am Handy und am nächsten Tag auf die Stimme einer Kollegin an deren Handy. Das Dokument ist die Konstante. Das Eingabegerät ist das, was Sie gerade in der Hand halten.

Das ist endlich die Form des Verfassens, die das Read/Write-Web vor mehr als dreißig Jahren liefern sollte und nicht geliefert hat, weil das Dokument als Koordinationsprotokoll von einer Office-Suite vereinnahmt wurde, die keinen Platz für ein Mikrofon hatte.

Jetzt hat das Mikrofon einen Platz.

Das Dokument hört zu.

Aus dem Englischen übersetzt: zum Originalbeitrag