Sprache zu Text in GitHub: so funktioniert es wirklich

GitHub hat kein Voice-Typing. Dein Hotkey erledigt die Arbeit.

Beantworten wir gleich die Frage, die die Leute tatsächlich in Google tippen. Nein, GitHub hat keine eingebaute Sprache-zu-Text-Funktion. Es gibt kein natives Diktat im Issue-Editor, im PR-Formular, im Review-Panel, in Discussions oder im Wiki. Das sind ganz normale Web-Textfelder. Um hineinzudiktieren, muss die Sprache von woanders kommen: von deinem Betriebssystem, deinem Browser oder einer Drittanbieter-App.

GitHub blockiert Diktieren nie. Es bietet nur selbst keines an. Damit hast du grob drei Möglichkeiten. Dein Betriebssystem bringt eine Diktierfunktion mit – Windows Spracheingabe über Win+H oder macOS Diktat. Eine Browser-Erweiterung wie Voice In kann in einen Chrome- oder Edge-Tab tippen. Oder eine systemweite Desktop-App wie Whisper diktiert in jedes Feld in jeder App, egal ob Browser oder nicht.

Der Unterschied zwischen diesen dreien ist die Reichweite. OS-Diktat ist kostenlos und funktioniert auf einer Plattform zur Zeit, die Qualität schwankt. Eine Browser-Erweiterung lebt nur im Tab – sie kann dir nicht in deine IDE oder die GitHub CLI folgen, und sie läuft in der Cloud. Eine Desktop-App wie Whisper ist nicht an einen Tab gebunden; weil sie auf OS-Ebene arbeitet, diktiert sie in GitHub in Chrome, Firefox, Safari oder Edge – und auch in eine Commit-Nachricht in GitHub Desktop.

Was du wirklich diktieren kannst (und das eine, was nicht geht)

Hier ist die Linie, über die ich dich nicht versehentlich treten lassen werde. Whisper diktiert das Schreiben rund um deinen Code. Es schreibt nicht den Code selbst.

Das deckt ehrlich gesagt den Großteil eines Entwickler-Tipptags ab. Fehlerberichte. Pull-Request-Beschreibungen. Code-Review-Notizen. Antworten in Discussions. README- und Markdown-Dokumente. Die Prosa, die die Änderung erklärt, nicht die Änderung selbst. Wenn du einen Absatz sprichst, der erklärt, warum eine Migration riskant ist, kommt Whisper damit bestens klar. Wenn du versuchst, die Migration zu diktieren, steht dir ein schlechter Nachmittag bevor.

Der Grund ist einfach. Gesprochener Code übersteht die Reise nicht. Funktionsnamen, JSON, snake_case gegen camelCase, ein kubectl-Flag, ein API-Pfad – die kommen als bestmögliches Englisch heraus und müssen von Hand korrigiert werden. Ein Sprachmodell hört "user underscore I D" und schreibt "user ID", und schon korrigierst du es. Diktiere also den Satz, der sagt "dieser PR behebt den Null-Check in der Auth-Middleware", und tippe dann den eigentlichen Bezeichner. Die meisten Issue- und PR-Texte bestehen ohnehin zu 80 % aus Erklärung und zu 20 % aus Code-Schnipsel. Diktiere die 80, tippe die 20.

Hotkey drücken, sprechen, Text im fokussierten Feld erhalten

Der Mechanismus ist derselbe, den du in jeder anderen App verwenden würdest – und genau das ist der Punkt. Klick in das GitHub-Feld, das du füllen willst. Halte den Hotkey. Sprich. Lass los. Der Transkript erscheint an der Cursorposition.

Der Standard-Hotkey ist Ctrl+Space unter Windows und Command+Option unter macOS. Beide sind Push-to-Talk: gedrückt halten, während du sprichst, loslassen zum Beenden. Du kannst sie in den Einstellungen ändern, falls sie mit etwas kollidieren – und wenn du je mit einem Hotkey-Konflikt gerungen hast, weißt du, warum diese Einstellung ihren Platz verdient hat (mehr dazu weiter unten).

Ein ehrliches Detail zum Umfang. Whisper fügt in das eine Feld ein, das du fokussiert hast, immer eines nach dem anderen. Es füllt nicht ein ganzes GitHub-Issue-Formular in einem Atemzug aus. Der Ablauf für ein neues Issue ist also: Titel anklicken, diktieren, Textfeld anklicken, das diktieren. Zwei Felder, zwei Tastendrücke. Das fühlt sich weniger nach Magie an und mehr nach einem schnellen Schreiber, der die Tastatur nie berührt. Das ist das richtige Bild im Kopf.

Die ganze App, live

Das ist die echte App, die direkt hier läuft – kein Screenshot. Stöbere herum. Die Einstellungen, der Hotkey-Wähler, die Modellauswahl sind das Original.

Ein paar Dinge, die du beim Klicken wissen solltest. Es gibt keinen GitHub-spezifischen Tab und keinen "GitHub-Modus", weil es keinen braucht. Für Whisper ist eine GitHub-PR-Beschreibung ein Textfeld wie jedes andere. Dasselbe Setup, das in den Issue-Editor diktiert, diktiert in deine E-Mails und deine IDE. Du richtest es einmal ein. Die Reichweite ist das Feature.

Wo es sich auszahlt: Issues, PR-Beschreibungen, Reviews, Discussions

Der Gewinn ist das langweilige, sich wiederholende Schreiben – das Zeug, das du aufschiebst, weil es eine Plage ist, es zu tippen.

Issues. Ein guter Fehlerbericht ist hauptsächlich Erzählung: was du getan hast, was du erwartet hast, was stattdessen passiert ist. Das ist das Heimspielfeld des Diktierens. Sprich die Reproduktionsschritte so durch, wie du sie einem Kollegen an deinem Schreibtisch erklären würdest, und füge den Stacktrace dann von Hand ein.

Pull-Request-Beschreibungen. Der PR-Text, den alle nicht schreiben wollen, weil der Diff "für sich selbst spricht" (tut er nicht). Diktiere das Warum – den Kontext, den der Reviewer braucht – und lass den Diff das Was erzählen.

Code-Reviews. Bei Review-Kommentaren kommt es auf den Ton an, und hier wird oft zu knapp erklärt. Eine gesprochene Review-Notiz klingt tendenziell menschlicher und vollständiger als eine, die du zwischen zwei Meetings tippst. Du schreibst dann "das funktioniert, aber es bricht, sobald die Liste leer ist" statt nur "Edge Case?".

Discussions und Doku. Langform-Prosa, also genau das, worin Sprache gut ist, und genau das, was niemand tippen will. Eine README-Einleitung, eine Discussions-Antwort, ein Migrationsleitfaden – diktiere den Entwurf, räum das Markdown danach auf. Dieselbe Logik gilt fürs Diktieren in Jira-Tickets und andere Tracker; GitHub ist nur ein weiteres Feld auf dem Stapel.

Das Diktat automatisch aufräumen

Rohes Diktat hat Füllwörter. "Ähm", "weißt du", der Satz, den du zweimal angefangen hast. Whisper hat einen optionalen KI-Aufräumdurchlauf, der Füllwörter, Zeichensetzung und Groß-/Kleinschreibung korrigiert, sodass das Issue oder der PR liest, als hättest du es sorgfältig geschrieben.

Es gibt zwei Varianten. In der kostenlosen lokalen Stufe läuft das Aufräumen auf deinem Rechner über Ollama. In Pro bringst du deinen eigenen OpenAI-Schlüssel mit, und das Aufräumen läuft in der Cloud, samt Web-Antworten. So oder so ist es optional – schalte es aus, und du bekommst das rohe Transkript. Ich lasse es bei PR-Beschreibungen an und bei schnellen Kommentaren aus, weil ein schneller Kommentar keine Bearbeitung braucht und eine PR-Beschreibung schon.

Eines, was das Aufräumen nicht leisten wird, ist, gesprochenen Code zu retten. Es poliert das Englische. Es weiß nicht, dass du getUserById meintest, als du "get user by I D" gesagt hast. Diktiere weiter die Prosa; tippe weiter die Bezeichner.

Offline und privat: im lokalen Modus verlässt nichts deinen Rechner

Wenn du Issues und PRs zu nicht-öffentlichem Code diktierst, ist es entscheidend, wohin das Audio geht. In Whispers lokalem Modus passiert die Transkription vollständig auf deinem Rechner. Nichts, was du sagst, wird an einen Cloud-Dienst gesendet. Während der Transkription wird überhaupt kein Internet benötigt – online gehst du nur ein einziges Mal für den Modell-Download, der je nach gewähltem Modell von etwa 140 MB bis 3 GB reicht.

Das ist die eine Stelle, an der ich dir eine echte Meinung gebe. Reine Cloud-Diktierung ist eine Datenschutzkatastrophe, die nur darauf wartet, transkribiert zu werden. Ich habe einmal mitansehen müssen, wie ein internes Team in einem einzigen Quartal eine fünfstellige Cloud-Rechnung anhäufte, weil ein selbstgebauter Diktier-Prototyp jede Äußerung an eine API schickte – und das Schlimmere war nicht die Rechnung, sondern dass die gesprochenen Notizen aller über ein unveröffentlichtes Produkt nun in den Logs eines Anbieters lagen. Die Gehaltstabelle deines Chefs, das Sicherheitsproblem, das du privat meldest, die proprietäre Architektur, die du in einem PR beschreibst – nichts davon sollte deinen Laptop verlassen, nur weil du einen Absatz mit deiner Stimme tippen wolltest. Dein Rechner hat bereits ein Mikrofon und eine CPU. Für einen Absatz braucht er keinen Server in der Schleife. Wenn dein Tool nur in der Cloud läuft, ist das der Teil, den ich zuerst reparieren würde.

Wofür es nicht da ist (Code schreiben)

Vielleicht bist du hier, weil du eine Möglichkeit suchst, Code per Sprache zu schreiben, oder du erinnerst dich an "Hey, GitHub!" und fragst dich, wo es geblieben ist. Zwei ehrliche Antworten.

"Hey, GitHub!" und GitHub Copilot Voice waren eine technische Vorschau von GitHub Next. GitHub stellte die Vorschau 2024 ein. Es wurde nie ein Produkt; die Erkenntnisse flossen in die VS Code Speech-Erweiterung ein. Wenn dir also ein Blogbeitrag heute rät, "Hey GitHub" zu aktivieren, ist er ein paar Jahre veraltet.

Die Spur Sprache-für-Code gibt es noch – sie lebt nur in deinem Editor und Terminal, nicht auf github.com. Die VS Code Speech-Erweiterung (manchmal "Hey Code" genannt) lässt dich mit dem Editor und mit Copilot Chat über Code und Befehle sprechen. Und GitHub Copilot CLI hat kürzlich lokale Spracheingabe hinzugefügt, die den Copilot-Agenten im Terminal steuert. Beides dient dem Steuern von Code und einem KI-Agenten. Keines davon diktiert Prosa in ein GitHub-Issue in deinem Browser. Das ist eine andere Spur, und es ist die, die Whisper besetzt: das Schreiben rund um den Code.

Wann du Whisper für deinen GitHub-Workflow überspringen solltest

Mir ist lieber, du verwendest das richtige Werkzeug als das, das ich baue. Hier ist also, wann du Whisper überspringen solltest.

Wenn du eigentlich Copilot oder deinen Editor per Sprache steuern willst – "repariere diese Funktion", "führe die Tests aus", "erkläre diesen Block" –, dann ist das die Code-/Agenten-Spur, nicht Prosa. Verwende stattdessen die VS Code Speech-Erweiterung oder die Spracheingabe der GitHub Copilot CLI. Die sprechen mit der Maschine; Whisper schreibt die Worte, die ein Mensch liest.

Wenn du nur gelegentlich einen einzeiligen Kommentar diktierst, erledigt dein Betriebssystem das bereits kostenlos. Drücke Win+H unter Windows oder schalte das Diktat unter macOS ein, und du kannst einen schnellen Satz in ein GitHub-Feld werfen, ohne etwas zu installieren. Whisper verdient sich seinen Lohn erst dann, wenn du echte Absätze über viele Apps hinweg schreibst, es offline laufen soll oder du einen Hotkey überall haben willst statt eines OS-Features, das nur manche Felder abdeckt. Unterhalb dieser Schwelle ist die eingebaute Option in Ordnung, und ich werde nicht so tun, als wäre es anders.

Kostenlos lokal, mit Pro für die Cloud

Die lokale Pipeline – Transkription, das KI-Aufräumen auf dem Gerät, der Hotkey, alles, was du zum Diktieren in GitHub brauchst – ist für angemeldete Nutzer kostenlos, und bei der Registrierung wird keine Karte verlangt. Du installierst es, meldest dich an und legst los mit dem Diktieren.

Whisper Pro ergänzt die Cloud-Ebene: OpenAI-Cloud-Transkription, Cloud-KI-Aufräumen mit deinem eigenen Schlüssel und Web-Antworten, mit einer kurzen Testphase für diese Stufe. Zum Diktieren von Issues und PRs deckt die kostenlose lokale Stufe die ganze Arbeit ab. Die Zahlen für Pro stehen auf der Preisseite; ich werde sie dir nicht mitten im Absatz um die Ohren hauen.

Eine letzte Sache zu diesem Hotkey

Ein Wort dazu, warum der Hotkey anpassbar ist, denn es bindet das Ganze zusammen. Die erste Version von Whisper löste auf bestimmten Windows-Rechnern ihr Aufnahme-Stopp sechsmal pro Tastendruck aus – Phantom-Loslass-Events vom Eingabe-Framework, die Art von Sache, die auf einer sauberen Installation funktioniert und auf einer echten kaputtgeht. Es brauchte ein 300-ms-Debounce und mehr Zeit, als ich zugeben will, um es zuverlässig zu machen. Ich habe mehr über Windows-Eingabeverarbeitung gelernt, als ich je wollte. Die Lektion blieb hängen: Der Hotkey muss sich deinem Rechner beugen, nicht umgekehrt. Klick ins Feld, halte die Taste, sprich. Den Code tippst du weiterhin selbst – und ich finde, das ist die ehrliche Version des Deals.