Code-Dokumentation per Sprache schreiben: Kommentare, READMEs und Doku, die nicht nervt

TL;DR: Entwickler vermeiden das Schreiben von Dokumentation, weil es einen mühsamen Wechsel von Code zu Prosa erfordert. Sprachdiktieren beseitigt diese Reibung. Sie lesen den Code, dann sprechen Sie die Erklärung. Das Ergebnis ist bessere Doku, geschrieben in einem Bruchteil der Zeit. Dieser Leitfaden behandelt Workflows für Inline-Kommentare, Docstrings, READMEs und API-Dokumentation mit Voice-Coding-Tools wie Murmur.

Warum Entwickler es hassen, Dokumentation zu schreiben

Seien wir ehrlich. Die meisten Entwickler würden lieber eine Legacy-Codebase refaktorisieren als eine README zu schreiben.

Es ist keine Faulheit. Es ist Reibung. Dokumentation zu schreiben erfordert eine grundlegend andere Denkweise als Code zu schreiben. Code ist präzise, strukturiert und knapp. Dokumentation ist erklärend, konversationell und ausführlich. Zwischen beidem zu wechseln ist kognitiv aufwendig.

So läuft es typischerweise ab:

1. Sie bauen ein Feature fertig
2. Sie wissen, dass Sie es dokumentieren sollten
3. Sie öffnen die README oder eine Dokumentationsdatei
4. Sie starren auf die leere Seite
5. Sie tippen widerwillig ein paar Sätze
6. Sie entscheiden, dass „der Code selbstdokumentierend ist" und machen weiter

Das Ergebnis sind Codebases mit veralteten READMEs, fehlenden Docstrings und Inline-Kommentaren, die seit drei Jahren // TODO: Dokumentation hinzufügen sagen.

Das Grundproblem ist nicht Motivation. Es ist die Eingabemethode. Natürliche Sprache zu tippen, wenn das Gehirn im Code-Modus ist, ist langsam und unnatürlich. Sie können die Erklärung schneller denken als tippen. Und in dieser Lücke zwischen Denkgeschwindigkeit und Tippgeschwindigkeit stirbt die Dokumentation.

Sprache beseitigt den Engpass

Wenn Sie Code einem Kollegen erklären, ringen Sie nicht um Worte. Sie schauen auf die Funktion, verstehen, was sie tut, und sagen es laut. Die Erklärung fließt natürlich, weil Sprache das native Format für Erklärungen ist.

Sprachdiktieren bringt genau diesen Fluss ins Schreiben von Dokumentation. Anstatt Prosa Zeichen für Zeichen zu tippen, lesen Sie den Code, drücken einen Shortcut und sprechen die Erklärung, als hätte ein Junior-Entwickler gerade gefragt „Was macht das hier?"

Der Geschwindigkeitsunterschied ist erheblich. Die meisten Entwickler tippen Prosa mit 40-60 Wörtern pro Minute. Bequemes Sprechen liegt bei etwa 130-150 Wörtern pro Minute. Das ist ungefähr 3x schneller für genau die Art von Text, die Dokumentation erfordert.

Aber Geschwindigkeit ist nur die halbe Geschichte. Per Sprache diktierte Dokumentation ist tendenziell gründlicher und natürlicher. Wenn Sie eine Erklärung sprechen, fügen Sie Kontext und Hinweise ein, die Sie beim Tippen weglassen würden, weil es „den Aufwand nicht wert ist." Genau diese zusätzlichen Details machen Dokumentation nützlich.

Workflow 1: Inline-Kommentare und Code-Annotationen

Inline-Kommentare sind die einfachste Dokumentation zum Diktieren. Der Workflow ist unkompliziert:

1. Lesen Sie den Codeblock, den Sie annotieren wollen
2. Platzieren Sie Ihren Cursor über der relevanten Zeile
3. Drücken Sie Ihren Sprach-Shortcut (Strg+Leertaste in Murmur)
4. Sprechen Sie die Erklärung

Zum Beispiel schauen Sie auf diese Funktion:

function reconcileInventory(orders, stockLevels) {
  const adjustments = orders.reduce((acc, order) => {
    const current = stockLevels.get(order.sku) ?? 0;
    const delta = order.type === 'return' ? order.qty : -order.qty;
    acc.set(order.sku, (acc.get(order.sku) ?? current) + delta);
    return acc;
  }, new Map());
  return adjustments;
}

Anstatt einen Kommentar zu tippen, sprechen Sie:

„Diese Funktion nimmt ein Array von Bestellungen und eine Map der aktuellen Lagerbestände entgegen und berechnet die Netto-Bestandsanpassung für jede SKU. Verkäufe verringern den Bestand und Retouren erhöhen ihn. Das Ergebnis ist eine Map von SKU zu angepasstem Lagerbestand."

Das hat etwa acht Sekunden gedauert. Tippen hätte 30-40 Sekunden gebraucht, und Sie hätten wahrscheinlich etwas Kürzeres und weniger Hilfreiches geschrieben.

Tipps für bessere Inline-Kommentare per Sprache

Beginnen Sie mit dem „Warum", nicht dem „Was". Der Code zeigt bereits, was passiert. Ihr Sprachkommentar sollte erklären, warum. Sagen Sie „Wir prüfen hier auf null, weil die Legacy-API manchmal null statt eines leeren Arrays zurückgibt" anstatt „Prüfe ob Wert null ist."

Sprechen Sie in vollständigen Sätzen. Moderne KI-Transkription funktioniert am besten mit vollständigen Gedanken. Pausieren Sie nicht nach jedem paar Wörtern. Lassen Sie den Gedanken natürlich fließen und die Zeichensetzung folgt von selbst.

Machen Sie sich beim ersten Durchgang keine Sorgen um die Formatierung. Sprechen Sie die Erklärung, dann bearbeiten Sie das Ergebnis schnell mit der Tastatur. Sprache für den ersten Entwurf, Tastatur für den Feinschliff. Dieser hybride Ansatz wird in unserem vollständigen Voice-Coding-Leitfaden behandelt.

Workflow 2: Docstrings und Funktionsdokumentation

Docstrings sind der Bereich, wo Sprachdiktieren wirklich glänzt. Ein guter Docstring erklärt, was eine Funktion tut, was ihre Parameter erwarten, was sie zurückgibt und was schiefgehen kann. Das ist viel Tipparbeit. Aber es sind nur etwa 15 Sekunden Sprechen.

Hier ist der Workflow in VS Code:

1. Platzieren Sie Ihren Cursor innerhalb der Docstring-Eröffnung (nach """ in Python, /** in JavaScript/TypeScript)
2. Drücken Sie Ihren Sprach-Shortcut
3. Beschreiben Sie die Funktion, als würden Sie sie jemandem erklären, der den Code noch nie gesehen hat

Python-Beispiel:

Sie sehen diese Funktion:

def sync_user_preferences(user_id: str, source: str = "api") -> dict:
    ...

Sie sprechen:

„Synchronisiert Benutzereinstellungen von der angegebenen Quelle in den lokalen Cache. Nimmt einen User-ID-String und einen optionalen Source-Parameter entgegen, der standardmäßig auf API gesetzt ist. Kann auch webhook oder migration als Source-Werte akzeptieren. Gibt ein Dictionary zurück, das die zusammengeführten Einstellungen und einen Zeitstempel der letzten Synchronisation enthält. Wirft einen UserNotFoundError, wenn die User-ID nicht existiert, und einen SyncConflictError, wenn die Remote- und lokalen Einstellungen abweichende Zeitstempel haben."

Das produziert einen umfassenden Docstring in 12 Sekunden. Die äquivalente Tippzeit wäre über eine Minute, und die meisten Entwickler hätten bei „Synchronisiert Benutzereinstellungen" aufgehört.

TypeScript/JSDoc-Beispiel:

Für eine TypeScript-Funktion funktioniert der gleiche Ansatz. Platzieren Sie Ihren Cursor innerhalb des JSDoc-Blocks und sprechen Sie:

„Validiert und normalisiert einen eingehenden Webhook-Payload von Stripe. Verifiziert die Webhook-Signatur gegen das konfigurierte Secret, parst den Event-Typ und gibt ein normalisiertes Event-Objekt zurück. Wirft einen InvalidSignatureError, wenn die Signatur nicht übereinstimmt. Der Timeout-Parameter steuert, wie lange auf die Signaturverifizierung gewartet wird, und ist standardmäßig auf 5000 Millisekunden gesetzt."

Bestehenden Code in einem Rutsch dokumentieren

Einer der besten Anwendungsfälle für Sprachdiktieren sind Dokumentations-Sprints auf bestehenden Codebases. Der Workflow:

1. Öffnen Sie eine Datei mit undokumentierten Funktionen
2. Lesen Sie die erste Funktion
3. Sprechen Sie den Docstring
4. Gehen Sie zur nächsten Funktion
5. Wiederholen

Sie können ein ganzes Modul in 15-20 Minuten dokumentieren, wofür Sie beim Tippen eine Stunde oder mehr gebraucht hätten. Die entscheidende Erkenntnis: Sie verstehen den Code bereits. Der Engpass war immer das Tippen, nicht das Denken.

Workflow 3: README-Dateien

README-Dateien sind die Eingangstür jedes Projekts. Sie sind auch das am meisten vernachlässigte Dokumentationsartefakt in den meisten Codebases. Sprachdiktieren verändert die Aufwandskalkulation beim Schreiben.

Der Voice-First-README-Prozess

Anstatt auf eine leere Datei zu starren, öffnen Sie Ihre README und sprechen Sie jeden Abschnitt:

Projektbeschreibung:

„Dies ist eine Middleware-Bibliothek für Express.js, die Rate-Limiting mit Redis-gestütztem Speicher verwaltet. Sie unterstützt sowohl Fixed-Window- als auch Sliding-Window-Algorithmen, konfigurierbare Limits pro Route und automatische IP-basierte und API-Key-basierte Client-Identifikation. Konzipiert für den Produktiveinsatz mit integrierter Unterstützung für Clustering und horizontale Skalierung."

Installationsabschnitt:

„Installieren Sie mit npm install at rate limiter middleware. Erfordert Node 18 oder höher und eine laufende Redis-Instanz. Für die Standardkonfiguration ist kein zusätzliches Setup nötig. Für benutzerdefinierte Konfigurationen siehe den Konfigurationsabschnitt weiter unten."

Verwendungsabschnitt:

Sprechen Sie ein Verwendungsbeispiel durch, als würden Sie einen Kollegen einweisen:

„Importieren Sie den Rate-Limiter aus dem Paket. Erstellen Sie eine neue Instanz mit Ihrer Redis-Verbindungs-URL. Verwenden Sie es dann als Express-Middleware mit app.use. Sie können ein Options-Objekt übergeben, um die Fenstergröße, maximale Anfragen und den Algorithmus zu konfigurieren. Hier ist ein einfaches Beispiel..."

Dann fügen Sie den Codeblock mit der Tastatur hinzu. Dieser hybride Ansatz (Sprache für Prosa, Tastatur für Code) ist die effizienteste Art, technische Dokumentation zu schreiben.

README-Tipps für Sprachdiktieren

Diktieren Sie die Prosa, tippen Sie den Code. Codeblöcke brauchen Präzision, die Tastatureingabe besser handhabt. Aber der gesamte erklärende Text rund um diese Codeblöcke ist perfekt für Sprache.

Sprechen Sie zu einer Person. Stellen Sie sich einen Entwickler vor, der Ihr Projekt gerade auf GitHub gefunden hat. Was muss er zuerst wissen? Sprechen Sie zu dieser Person.

Verwenden Sie Überschriften als Anregung. Erstellen Sie zuerst Ihre Überschriftenstruktur (## Installation, ## Verwendung, ## Konfiguration) und füllen Sie dann jeden Abschnitt per Sprache. Die Überschriften geben Ihnen einen Rahmen, sodass Sie nicht überlegen müssen, was Sie als Nächstes sagen sollen.

Workflow 4: API-Dokumentation

API-Dokumentation ist repetitiv und ausführlich, was sie ideal für Sprachdiktieren macht. Jeder Endpoint braucht eine Beschreibung, Parameter, Request/Response-Beispiele und Fehlercodes. Das ist viel Schreibarbeit, aber das Muster ist vorhersehbar.

Endpoint-Beschreibungen diktieren

Für jeden API-Endpoint sprechen Sie diese Elemente durch:

„POST Slash API Slash Users. Erstellt ein neues Benutzerkonto. Erfordert einen JSON-Body mit E-Mail, Passwort und einem optionalen Anzeigenamen. Die E-Mail muss über alle Konten hinweg einzigartig sein. Das Passwort muss mindestens 8 Zeichen mit einem Großbuchstaben und einer Zahl haben. Gibt einen 201 mit dem erstellten User-Objekt zurück, einschließlich der generierten User-ID und eines Zeitstempels. Gibt 409 zurück, wenn die E-Mail bereits existiert. Gibt 422 zurück, wenn der Request-Body die Validierung nicht besteht."

Das beschreibt den Endpoint ausführlicher als die meisten Entwickler tippen würden, und es hat etwa 15 Sekunden gedauert.

Schema-Beschreibungen diktieren

Datenmodell-Dokumentation profitiert vom gleichen Ansatz:

„Das User-Objekt enthält eine ID, die eine UUID v4 ist und bei der Erstellung generiert wird, eine E-Mail, die einzigartig und case-insensitiv ist, einen Anzeigenamen, der standardmäßig auf den Teil der E-Mail vor dem At-Zeichen gesetzt wird, einen Erstellungszeitstempel im ISO-8601-Format und ein Status-Feld, das active, suspended oder deleted sein kann."

Tipps für das Diktieren technischer Inhalte

Umgang mit Abkürzungen und technischen Begriffen

KI-gestützte Transkriptionstools wie Murmur verarbeiten das meiste technische Vokabular korrekt, weil sie den Kontext nutzen, um die Bedeutung zu verstehen. Ein paar Tipps helfen jedoch bei Grenzfällen:

Sagen Sie Akronyme natürlich. „API", „JSON", „REST", „JWT" werden alle erkannt, wenn sie als Akronyme gesprochen werden. Sie müssen sie nicht buchstabieren.

Nutzen Sie Kontext für mehrdeutige Begriffe. Wenn Sie sagen „Route-Handler für den Users-Endpoint", versteht die Transkription „Route" im Programmierkontext. In vollständigen Sätzen zu sprechen liefert den Kontext, der die Transkription akkurat macht.

Buchstabieren Sie ungewöhnliche Namen bei Bedarf. Bei proprietären Begriffen oder ungewöhnlichen Bibliotheksnamen müssen Sie möglicherweise einmal buchstabieren und dann korrigieren. Nach dem ersten Vorkommen erkennt die KI-Transkriptions-Engine oft das Muster.

Zeichensetzung und Formatierung

Moderne KI-Transkription handhabt Zeichensetzung gut, wenn Sie natürlich sprechen. Ein paar Besonderheiten:

• Punkte und Kommas werden automatisch basierend auf Ihren Sprechmustern eingefügt
• Code-Begriffe wie Funktionsnamen können natürlich gesprochen und dann nachträglich mit Backticks per Tastatur formatiert werden
• Listen funktionieren gut, wenn Sie sie verbal signalisieren: „Erstens... Zweitens... Drittens..." Die Transkription erkennt die Struktur meist

Der hybride Ansatz

Der produktivste Dokumentations-Workflow kombiniert Sprache und Tastatur:

1. Sprache für alle erklärende Prosa, Beschreibungen und natürlichsprachliche Inhalte
2. Tastatur für Codeblöcke, Formatierung (Überschriften, Fettdruck, Links) und präzise Bearbeitungen
3. Sprache erneut zur Überprüfung Ihres Entwurfs. Lesen Sie ihn laut vor und diktieren Sie Korrekturen oder Ergänzungen

Dieser Ansatz nutzt die Stärken jeder Eingabemethode. Sie kämpfen nicht mit der Tastatur bei langer Prosa, und Sie kämpfen nicht mit der Sprache bei präziser Formatierung.

Wo Murmur hineinpasst

Murmur ist genau für diesen Workflow konzipiert. Es funktioniert in jeder Anwendung auf Ihrem PC, was bedeutet, dass Sie Dokumentation diktieren können in:

• VS Code direkt in Ihren Quelldateien
• Terminal-Editoren wie Vim oder Nano
• Browser-basierten Tools wie GitHubs Web-Editor, Notion oder Confluence
• Claude Code zum Prompten von KI, Dokumentation zu generieren oder zu verbessern

Ein Shortcut aktiviert die Diktierfunktion. Sprechen Sie Ihre Dokumentation. Der Text erscheint an Ihrer Cursorposition. Kein App-Wechsel, kein Kopieren-Einfügen, kein Moduswechsel.

Bei kostenlos für 5 Diktate pro Tag plus 7-tägiger Pro-Testphase oder 39,97 € für eine Lifetime-Pro-Lizenz sind die Kosten für bessere Dokumentation vernachlässigbar. Vergleichen Sie das mit den Kosten für das Onboarding eines neuen Entwicklers, der drei Tage damit verbringt, eine undokumentierte Codebase zu verstehen.

Die Dokumentationsgewohnheit

Die größte Hürde für gute Dokumentation sind nicht Tools. Es ist Gewohnheit. Sprachdiktieren senkt den Aufwand genug, um Dokumentation zu einem realistischen Teil Ihres täglichen Workflows zu machen, statt zu einem vierteljährlichen Gewissensbiss.

Hier ist eine einfache Gewohnheit zum Aufbauen:

• Jedes Mal, wenn Sie eine Funktion fertigstellen, verbringen Sie 10 Sekunden damit, einen Docstring zu sprechen
• Jedes Mal, wenn Sie einen PR schließen, verbringen Sie 30 Sekunden damit, einen zusammenfassenden Kommentar zu sprechen
• Jeden Freitag verbringen Sie 10 Minuten damit, Updates für Ihre Projekt-README per Sprache zu diktieren

Zehn Sekunden pro Funktion. Mehr braucht es nicht, wenn Sie sprechen statt tippen können. Und der Zinseszinseffekt dieser 10-Sekunden-Investitionen ist eine Codebase, die neue Entwickler tatsächlich verstehen können.

Loslegen

1. Murmur herunterladen (kostenlos, 2 Minuten Einrichtung)
2. Öffnen Sie eine Datei mit undokumentiertem Code
3. Platzieren Sie Ihren Cursor über einer Funktion
4. Drücken Sie Strg+Leertaste und erklären Sie, was die Funktion tut
5. Wiederholen Sie es für die nächste Funktion

Starten Sie mit einer Datei. Dokumentieren Sie jede Funktion darin per Sprache. Stoppen Sie die Zeit. Sie werden überrascht sein, wie schnell es geht, wenn der Engpass das Denken ist, nicht das Tippen.

Ihre Codebase verdient Dokumentation, die nicht nervt. Ihre Stimme kann sie liefern.

Weiterführende Artikel

• Voice Coding in 2026: Der vollständige Leitfaden
• Setting Up Voice Coding in VS Code: Step-by-Step
• Voice Coding mit Claude Code: Prompts sprechen
• 5 Ways Voice Typing Makes You a Better Developer
• Why Your AI Prompts Suck (And How Voice Fixes Them)