Voice Coding: Code, Reviews, Commits per Stimme

„Programmieren per Stimme" klingt meistens wie Slapstick. Das Video von 2017, in dem ein Entwickler „open paren if foo equals equals null close paren" brüllt, ist ein Meme, kein Workflow. Auch ich dachte lange, diese Idee sei tot.

Commander Flow hat meine Sicht gedreht. Nicht weil es einen magischen „Code-Diktiermodus" hinzugefügt hätte. Sondern weil Code nicht nur Code ist. Code, das sind Commits, Tickets, Code-Reviews, Doku, Kommentare, Namen, Chats mit Kollegen. Und all das rund um den Code – jetzt per Stimme.

Wo Stimme das Leben eines Entwicklers wirklich verändert

Meine häufigste Sprachoperation sind Commit-Messages. Cursor in git commit -m "...", Hotkey halten, etwas wie „Race Condition beim Abbrechen der Pipeline gefixt, Token wird beim erneuten Hotkey-Druck korrekt abgebrochen" – und im Terminal landet eine fertige Nachricht im Conventional-Commits-Stil, weil ich die Regeln einmal per Stimme gesetzt habe und sie sich gemerkt wurden.

PR-Beschreibungen sind fast genauso, nur länger. Ich öffne das GitHub-PR-Template, diktiere wie ich einem Junior erklären würde – was sich ändert, warum, was nicht angefasst wird, wie man testet. Wenige Sekunden später habe ich sauberes Markdown mit Überschriften ## Context, ## Changes, ## Test plan. Früher fünf Minuten, heute Sekunden.

Was sich für mich am stärksten umgekehrt hat – das sind Code-Review-Kommentare. Früher war ich zu faul, ausführliche Reviews zu schreiben: zu viel Tippen für etwas, das man liest und wieder vergisst. Jetzt markiere ich die Zeile, diktiere den Gedanken und bekomme einen klaren, polierten Kommentar in Sekunden. Meine Reviews sind deutlich länger und merklich nützlicher geworden – das Team sieht es.

Eine eigene Kategorie ist Dokumentation. Der schmerzhafteste Teil des Berufs. Ich diktiere einen Docstring, wie ich es einem Kollegen erklären würde, und Commander Flow bringt das in den Stil von XML-Doc, TSDoc oder Markdown – je nach Projektsprache. Doku ist nicht mehr die Steuer, die ich auf den Code zahle.

„Ich schreibe keinen Code per Stimme. Ich schreibe alles rund um Code per Stimme. Und habe verstanden: das ist die Hälfte meines Jobs."

Code-Comments-Modus: eine Sache, die ich besonders liebe

Ich sage einfach per Stimme „lass es als Code-Kommentar" – und Commander Flow:

• Lässt lateinische Bezeichner unverändert (variable names, class names)
• Behält Begriffe (kubectl, async/await, useEffect, OAuth) in der Originalschreibweise
• Fügt keine „überflüssigen" höflichen Floskeln hinzu (in Code-Kommentaren steht eh kein „werte Leser")
• Arbeitet sauber mit beiden Schriftsystemen in einem Kommentar: // prüfen, dass Subscription.IsActive vor Aufruf von BillingService.Refresh

Klingt nach Kleinigkeit. Aber ohne diesen Sprachhinweis haben die ersten Alpha-Builds meinen technischen Kommentar manchmal in „Lassen Sie uns überprüfen, ob unser Geschäftsobjekt der Subscription korrekt ist" verwandelt.

Begriffswörterbuch — eine unterschätzte Funktion

In PolishOptions.Dictionary packe ich eigene Begriffe und Abkürzungen. Bei mir liegen dort:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (komplett, als Phrase – damit die LLM ihn nicht umschreibt)
• Firmen-Abkürzungen, Namen interner Services

Danach hört die LLM auf, spezifische Begriffe zu „verbessern", und lässt sie genau so, wie ich sie genannt habe.

Das Szenario, das mich täglich überzeugt

10:30, ich in der IDE, daneben der Team-Chat, daneben Linear mit dem Ticket. Ich halte den Hotkey und sage:

„Retry-Logik in eine eigene Klasse RetryPolicy mit exponentiellem Backoff ausgelagert, Tests ergänzt, prüfe vor dem Merge zusätzlich das Sequence Diagram im Ticket"

Das geht als Kommentar ins Linear-Ticket. Dann Alt+Tab in Slack, gleicher Hotkey:

„team, PR ist zur Review draußen, nicht blockierend, aber heute wäre cool"

Im Slack-Stil, klein geschrieben, ohne „werte Kollegen". Dann zurück in die IDE.

Drei Aktionen in drei Anwendungen, alles per Stimme, keine Finger.

Wo ich gestolpert bin

Punctuation in Code, der zwischen Diktatphrasen rutscht. Wenn ich „diese Funktion gibt Task<bool> zurück" diktiere, „denkt" die LLM manchmal, Task<bool> sei HTML, und versucht zu escapen. Gelöst, indem der Begriff im Wörterbuch landet, aber anfangs hat es überrascht.

Hotkey-Konflikte mit der IDE. Meine IDE hat eigene Shortcuts. Den Commander-Flow-Hotkey musste ich ein paarmal umbelegen, damit nichts kollidiert. Aktuell liegt er auf Caps Lock – die bequemste, selten genutzte Taste. Kleiner Aufwand, ein Klick in den Einstellungen.

Die schwersten Modi können in der IDE etwas „länger denken". Bei einer E-Mail fallen ein paar Millisekunden nicht auf. Bei einem Code-Kommentar „hier und jetzt" schon. Ich habe für den Arbeitslaptop auf den mittleren Modus umgestellt und den stärksten für den Desktop mit dedizierter GPU reserviert. Latenz weg.

Was ich über Sprache als Programmier-Interface verstanden habe

Stimme ersetzt die Tastatur in der IDE nicht. Sie ergänzt sie dort, wo die Tastatur das schlechtere Werkzeug war. if (x != null && y != null) tippen – Tastatur. Erklären, warum diese Prüfung hier nötig ist – Stimme.

Zwischen diesen beiden Aufgaben liegt eine kognitive Lücke, und sie „lösen sich nicht gleichermaßen durch Tippen". Ich zwinge mich nicht mehr, die zweite Sorte Aufgaben zu tippen. Es ist leichter geworden.

Was ich aus dieser Proportion mitgenommen habe

Voice Coding ist nicht „Code-Diktat". Es ist eine Verschiebung dessen, was genau man per Stimme tut. Logik schreibst du mit der Hand, alles Menschliche drum herum per Stimme.

In zehn Jahren im Beruf habe ich keine bequemere Aufteilung gefunden.