Door Denys Medvediev

Tutorial

Spraak naar tekst in GitHub: hoe het echt werkt

GitHub heeft geen eigen dicteerfunctie. De velden voor issues, PR's, reacties en markdown zijn gewone webtekstvakken. Een app met een systeembrede sneltoets houdt een toets ingedrukt, zet om wat je zegt en plakt het in het veld waar je focus ligt.

Laatst bijgewerkt: juni 2026

Open laptop met broncode op een houten bureau in een gezellige, moderne werkplek

Spraak naar tekst in GitHub betekent dat je proza in de tekstvelden van GitHub dicteert met een app die een systeembrede sneltoets gebruikt, omdat GitHub geen eigen dicteerfunctie heeft. De velden voor issues, pull requests, reacties en markdown zijn gewone webtekstvakken. Een tool als Whisper houdt een sneltoets ingedrukt, zet om wat je zegt en plakt het bij de cursor — in het issue, de PR of de reviewnotitie waar je focus ligt.

Vorig jaar was ik een week lang overtuigd dat GitHub stilletjes ergens in de issue-editor een spraakknop had toegevoegd. Dat was niet zo. De issuetekst is een tekstvak. De PR-beschrijving is een tekstvak. De reviewreactie, het Discussions-vak, de README-editor — allemaal tekstvakken, hetzelfde soort dat een contactformulier gebruikt. Er zit geen microfoonpictogram verstopt in een menu. De saaie waarheid is dat het schrijven dat je rond je code op GitHub doet, gewoon tekstinvoer is, en elke fatsoenlijke dicteertool kan het invullen.

Dat is goed nieuws, want het betekent dat je niet hoeft te wachten tot GitHub een functie bouwt. Je neemt je eigen spraaklaag mee. Op Windows of Mac zit Whisper op het niveau van het besturingssysteem, dus dezelfde sneltoets werkt in de issue-editor, de PR-beschrijving, een code-reviewdraad, je IDE en Slack — overal waar een cursor knippert. Je klikt in het veld, houdt de toets ingedrukt, praat en laat los. Eén belangrijke kanttekening vooraf, en die zal ik blijven herhalen: dit is voor het proza, niet voor de code.

GitHub heeft geen spraakgestuurd typen. Jouw sneltoets doet het werk.

Ontwikkelaar werkt aan code op een opstelling met twee monitoren in een modern kantoor

Laat me de vraag beantwoorden die mensen echt in Google typen. Nee, GitHub heeft geen ingebouwde spraak naar tekst. Er is geen native dicteerfunctie in de issue-editor, het PR-formulier, het reviewpaneel, Discussions of de wiki. Dat zijn standaard webtekstvakken. Om erin te dicteren moet de spraak ergens anders vandaan komen: je besturingssysteem, je browser of een app van derden.

GitHub blokkeert dicteren nooit. Het biedt er alleen zelf niets voor. Je hebt dus grofweg drie opties. Je besturingssysteem heeft dicteren ingebouwd — Windows Voice Typing via Win+H, of macOS Dictation. Een browserextensie als Voice In kan in een Chrome- of Edge-tabblad typen. Of een systeembrede desktopapp als Whisper dicteert in elk veld in elke app, browser of niet.

Het verschil tussen die drie is bereik. Dicteren via het besturingssysteem is gratis en werkt op één platform tegelijk; de kwaliteit wisselt. Een browserextensie leeft alleen binnen het tabblad — die kan je niet volgen naar je IDE of de GitHub CLI, en draait in de cloud. Een desktopapp als Whisper zit niet vast aan een tabblad; omdat hij op OS-niveau werkt, dicteert hij in GitHub in Chrome, Firefox, Safari of Edge, en ook in een commitbericht in GitHub Desktop.

Wat je echt kunt dicteren (en het ene wat niet kan)

Hier trek ik de grens die je niet per ongeluk mag overschrijden. Whisper dicteert het schrijven rond je code. Het schrijft de code zelf niet.

Dat dekt eerlijk gezegd het grootste deel van de typedag van een ontwikkelaar. Bugmeldingen. Pull-requestbeschrijvingen. Code-reviewnotities. Antwoorden in Discussions. README- en markdown-documenten. Het proza dat de wijziging uitlegt, niet de wijziging zelf. Als je een alinea inspreekt waarin je uitlegt waarom een migratie riskant is, gaat Whisper daar prima mee om. Als je de migratie zelf probeert te dicteren, krijg je een vervelende middag.

De reden is simpel. Gesproken code overleeft de reis niet. Functienamen, JSON, snake_case versus camelCase, een kubectl-vlag, een API-pad — die komen er als best-effort Engels uit en moeten met de hand worden verbeterd. Een spraakmodel hoort "user underscore I D" en schrijft "user ID," en nu ben je aan het corrigeren. Dicteer dus de zin die zegt "deze PR repareert de null-check in de auth-middleware," en typ daarna de echte identifier. De meeste issue- en PR-teksten bestaan toch voor 80% uit uitleg en 20% codefragment. Dicteer de 80, typ de 20.

Druk op een sneltoets, praat, krijg tekst in het actieve veld

Cancel
De opname-overlay: een klein capsuletje dat verschijnt terwijl je praat, zodat je weet dat Whisper luistert.

Het mechanisme is hetzelfde als in elke andere app, en dat is juist het hele punt. Klik in het GitHub-veld dat je wilt vullen. Houd de sneltoets ingedrukt. Praat. Laat los. Het transcript verschijnt bij de cursor.

De standaardsneltoets is Ctrl+Space op Windows en Command+Option op macOS. Beide zijn push-to-talk: ingedrukt houden terwijl je praat, loslaten om te stoppen. Je kunt ze in de instellingen wijzigen als ze botsen met iets — en als je ooit met een sneltoetsconflict hebt geworsteld, weet je waarom die instelling zijn plek heeft verdiend (daarover later meer).

Eén eerlijk detail over het bereik. Whisper plakt in het ene veld waar je focus ligt, één tegelijk. Het vult niet in één adem een heel GitHub-issueformulier in. De flow voor een nieuw issue is dus: klik op de titel, dicteer die, klik op de tekst, dicteer dat. Twee velden, twee keer indrukken. Het voelt minder als magie en meer als een snelle typist die nooit het toetsenbord aanraakt. Dat is het juiste mentale beeld.

De hele app, live

Whisper
De echte Whisper-desktopapp, hier draaiend — klik door de instellingen, de sneltoetskiezer en de modelkeuzes.

Dit is de echte app, hier draaiend — geen screenshot. Snuffel rond. De instellingen, de sneltoetskiezer en de modelkeuzes zijn het echte werk.

Een paar dingen die het waard zijn om te weten terwijl je klikt. Er is geen GitHub-specifiek tabblad en geen "GitHub-modus," want dat hoeft niet. Voor Whisper is een GitHub-PR-beschrijving een tekstveld als elk ander. Dezelfde opzet die in de issue-editor dicteert, dicteert in je e-mail en je IDE. Je stelt het één keer in. Het bereik is de functie.

Waar het zich uitbetaalt: issues, PR-beschrijvingen, reviews, discussions

De winst zit in het saaie, repetitieve schrijfwerk — het soort dat je uitstelt omdat het uittypen een corvee is.

Issues. Een goede bugmelding is grotendeels verhaal: wat je deed, wat je verwachtte, wat er in plaats daarvan gebeurde. Dat is het thuisterrein van dicteren. Praat de reproductiestappen door zoals je ze aan een collega aan je bureau zou uitleggen, en plak daarna de stacktrace er met de hand bij.

Pull-requestbeschrijvingen. De PR-tekst die iedereen overslaat omdat de diff "voor zich spreekt" (dat doet hij niet). Dicteer het waarom — de context die de reviewer nodig heeft — en laat de diff het wat vertellen.

Code-reviews. Bij reviewreacties doet toon ertoe en leggen mensen te weinig uit. Een reviewnotitie inspreken komt meestal menselijker en vollediger over dan er tussen meetings door eentje typen. Je schrijft "dit werkt, maar het breekt als de lijst leeg is" in plaats van alleen "randgeval?"

Discussions en docs. Lange teksten, precies waar spraak goed in is en precies wat niemand wil typen. Een README-intro, een Discussions-antwoord, een migratiegids — dicteer het concept, knap de markdown daarna op. Dezelfde logica geldt voor het dicteren in Jira-tickets en andere trackers; GitHub is gewoon nog een veld op de stapel.

Maak het gedicteerde automatisch netjes

Thinking...
De verbeterstand: een optionele AI-ronde haalt stopwoorden, interpunctie en hoofdletters recht voordat de tekst neerkomt.

Ruwe dictatie zit vol opvulling. "Eh," "weet je," de zin die je twee keer begon. Whisper heeft een optionele AI-opschoonronde die stopwoorden, interpunctie en hoofdletters corrigeert, zodat het issue of de PR leest alsof je het zorgvuldig hebt geschreven.

Er zijn twee smaken. In de gratis lokale laag draait de opschoning op je eigen machine via Ollama. In Pro breng je je eigen OpenAI-sleutel mee en draait de opschoning in de cloud, met ook webantwoorden beschikbaar. Hoe dan ook is het optioneel — zet het uit en je krijgt het ruwe transcript. Ik laat het aan voor PR-beschrijvingen en uit voor snelle reacties, want een snelle reactie hoeft niet bewerkt te worden en een PR-beschrijving wel.

Eén ding dat de opschoning niet doet, is gesproken code redden. Het polijst het Engels. Het weet niet dat je getUserById bedoelde toen je "get user by I D" zei. Blijf het proza dicteren; blijf de identifiers typen.

Offline en privé: in lokale modus verlaat niets je machine

Blauw hangslot dat een houten poort beveiligt met doorvallend zonlicht, als symbool voor private lokale verwerking

Als je issues en PR's dicteert over code die niet openbaar is, maakt het uit waar de audio naartoe gaat. In de lokale modus van Whisper gebeurt de transcriptie volledig op je eigen machine. Niets van wat je zegt wordt naar een clouddienst gestuurd. Tijdens de transcriptie is er helemaal geen internet nodig — de enige keer dat je online gaat, is de eenmalige modeldownload, die varieert van ongeveer 140 MB tot 3 GB, afhankelijk van welk model je kiest.

Dit is de ene plek waar ik je een echte mening geef. Dicteren dat alleen in de cloud werkt, is een privacyramp die erom vraagt getranscribeerd te worden. Ik zag ooit een intern team in één kwartaal een cloudrekening met vijf cijfers opbouwen omdat een zelfgebouwd dicteerprototype elke uiting naar een API stuurde — en het ergste was niet de rekening, maar dat ieders gesproken notities over een niet-uitgebracht product nu in de logs van een leverancier stonden. De salarisspreadsheet van je baas, het beveiligingsissue dat je privé indient, de eigen architectuur die je in een PR beschrijft — niets daarvan zou je laptop moeten verlaten alleen omdat je een alinea met je stem wilde typen. Je machine heeft al een microfoon en een CPU. Voor één alinea heeft die geen server in de lus nodig. Als je tool alleen in de cloud draait, is dat het deel dat ik als eerste zou aanpakken.

Waar het niet voor is (code schrijven)

Close-up van een laptoptoetsenbord verlicht met blauw licht, dat doet denken aan hands-on programmeren

Misschien kwam je hier op zoek naar een manier om met je stem code te schrijven, of herinner je je "Hey, GitHub!" en vraag je je af waar het is gebleven. Twee eerlijke antwoorden.

"Hey, GitHub!" en GitHub Copilot Voice waren een technische preview van GitHub Next. GitHub heeft de preview in 2024 stopgezet. Het is nooit een product geworden; de inzichten zijn opgegaan in de VS Code Speech-extensie. Dus als een blogpost je vandaag vertelt om "Hey GitHub" in te schakelen, is die een paar jaar verouderd.

De spraak-voor-code-baan bestaat nog steeds — die leeft alleen in je editor en terminal, niet op github.com. Met de VS Code Speech-extensie (soms "Hey Code" genoemd) kun je tegen de editor en tegen Copilot Chat praten voor code en commando's. En GitHub Copilot CLI heeft onlangs lokale spraakinvoer toegevoegd die de Copilot-agent in de terminal aanstuurt. Beide zijn voor het besturen van code en een AI-agent. Geen van beide dicteert proza in een GitHub-issue in je browser. Dat is een andere baan, en het is de baan die Whisper bezit: het schrijven rond de code.

Wanneer je Whisper voor je GitHub-workflow beter kunt overslaan

Ik zie liever dat je de juiste tool gebruikt dan die van mij. Dus hier is wanneer je Whisper kunt overslaan.

Als je eigenlijk Copilot of je editor met je stem wilt besturen — "repareer deze functie," "voer de tests uit," "leg dit blok uit" — dan is dat de code/agent-baan, geen proza. Gebruik in plaats daarvan de VS Code Speech-extensie of de spraakinvoer van GitHub Copilot CLI. Die praten tegen de machine; Whisper schrijft de woorden die een mens leest.

Als je alleen af en toe een reactie van één regel dicteert, doet je besturingssysteem dat al gratis. Druk op Win+H op Windows of zet Dictation aan op macOS, en je kunt zonder iets te installeren een snelle zin in een GitHub-veld neerzetten. Whisper begint zich terug te verdienen wanneer je echte alinea's schrijft in veel apps, het offline wilt laten werken, of overal één sneltoets wilt in plaats van een OS-functie die maar sommige velden dekt. Onder die grens is de ingebouwde optie prima, en dat zal ik niet anders voorstellen.

Gratis lokaal, met Pro voor de cloud

De lokale pijplijn — transcriptie, de AI-opschoning op je apparaat, de sneltoets, alles wat je nodig hebt om in GitHub te dicteren — is gratis voor ingelogde gebruikers, en er is geen creditcard nodig bij het aanmelden. Je installeert het, logt in en begint te dicteren.

Whisper Pro voegt het cloudvlak toe: OpenAI-cloudtranscriptie, AI-opschoning in de cloud met je eigen sleutel, en webantwoorden, met een korte proefperiode voor die laag. Voor het dicteren van issues en PR's dekt de gratis lokale laag de hele klus. De cijfers voor Pro staan op de prijzenpagina; ik ga ze je niet midden in een alinea voorhouden.

Nog één ding over die sneltoets

Een woord over waarom de sneltoets aanpasbaar is, want het bindt het hele verhaal samen. De eerste versie van Whisper liet op bepaalde Windows-machines de opname-stop zes keer per toetsaanslag afgaan — spookloslaatgebeurtenissen van het invoerframework, het soort dat werkt op een schone installatie en breekt op een echte. Het kostte een debounce van 300 ms en meer tijd dan ik wil toegeven om het betrouwbaar te krijgen. Ik leerde meer over Windows-invoerverwerking dan ik ooit wilde. De les bleef hangen: de sneltoets moet zich naar jouw machine plooien, niet andersom. Klik in het veld, houd de toets ingedrukt, praat. De code typ je nog steeds zelf — en dat is volgens mij de eerlijke versie van de afspraak.

Dicteer je volgende GitHub-issue

Klik in het veld, houd de toets ingedrukt, praat, laat los. Het transcript komt terecht waar je cursor staat — in de issue-editor, de PR-beschrijving en in elke andere app.

Gratis lokale modus voor elk ingelogd account. Geen creditcard nodig om te beginnen.

Foto van Denys Medvediev

Denys Medvediev

Ik ben degene die onze supportmail leest, hoogstwaarschijnlijk door de antwoorden te dicteren.