Tutorial
Dettatura vocale in GitHub: come funziona davvero
GitHub non ha una dettatura propria: i campi per issue, PR, commenti e markdown sono semplici textarea web. Un'app con hotkey a livello di sistema tiene premuto un tasto, trascrive ciò che dici e lo incolla nel campo che hai selezionato.
Ultimo aggiornamento: giugno 2026

La dettatura vocale in GitHub significa dettare testo nei campi di GitHub con un'app dotata di hotkey a livello di sistema, perché GitHub non ha una dettatura integrata. I suoi campi per issue, pull request, commenti e markdown sono semplici textarea web. Uno strumento come Whisper tiene premuto un hotkey, trascrive ciò che dici e lo incolla al cursore, nell'issue, nella PR o nella nota di revisione che hai selezionato.
L'anno scorso ho passato una settimana convinto che GitHub avesse silenziosamente aggiunto un pulsante vocale da qualche parte nell'editor delle issue. Non era così. Il corpo dell'issue è una textarea. La descrizione della PR è una textarea. Il commento di revisione, il box delle Discussions, l'editor del README: tutte textarea, dello stesso tipo usato da un modulo di contatto. Non c'è nessuna icona del microfono nascosta in un menu. La verità, per quanto banale, è che la scrittura che fai attorno al tuo codice su GitHub è semplice inserimento di testo, e qualsiasi buon strumento di dettatura può riempire quei campi.
È una buona notizia, perché significa che non devi aspettare che GitHub sviluppi una funzione. Porti tu il tuo livello vocale. Su Windows o Mac, Whisper lavora a livello di sistema operativo, quindi lo stesso hotkey funziona nell'editor delle issue, nella descrizione della PR, in un thread di revisione del codice, nel tuo IDE e in Slack: ovunque lampeggi un cursore. Clicchi sul campo, tieni premuto il tasto, parli e rilasci. Una precisazione importante fin da subito, e continuerò a ripeterla: serve per la prosa, non per il codice.
GitHub non ha la dettatura vocale. È il tuo hotkey a fare il lavoro.

Rispondo alla domanda che la gente digita davvero su Google. No, GitHub non ha la dettatura vocale integrata. Non c'è dettatura nativa nell'editor delle issue, nel modulo della PR, nel pannello di revisione, nelle Discussions o nella wiki. Sono normali textarea web. Per dettare al loro interno, la voce deve arrivare da un'altra parte: dal tuo sistema operativo, dal browser o da un'app di terze parti.
GitHub non blocca mai la dettatura. Semplicemente non ne offre alcuna. Quindi le tue opzioni sono sostanzialmente tre. Il tuo sistema operativo ha la dettatura integrata: la Digitazione vocale di Windows con Win+H, o la Dettatura di macOS. Un'estensione del browser come Voice In può scrivere in una scheda di Chrome o Edge. Oppure un'app desktop a livello di sistema come Whisper detta in qualsiasi campo di qualsiasi app, browser o meno.
La differenza tra queste tre è la portata. La dettatura del sistema operativo è gratuita, funziona su una sola piattaforma alla volta e la qualità varia. Un'estensione del browser vive solo dentro la scheda: non ti può seguire nel tuo IDE o nella CLI di GitHub, e gira nel cloud. Un'app desktop come Whisper non è legata a una scheda; poiché lavora a livello di sistema operativo, detta in GitHub su Chrome, Firefox, Safari o Edge, e anche in un messaggio di commit in GitHub Desktop.
Cosa puoi davvero dettare (e l'unica cosa che non puoi)
Ecco il limite che non ti lascerò superare per sbaglio. Whisper detta la scrittura attorno al tuo codice. Non scriverà il codice stesso.
Quello che copre è la maggior parte della giornata di scrittura di uno sviluppatore, onestamente. Segnalazioni di bug. Descrizioni delle pull request. Note di revisione del codice. Risposte nelle Discussions. README e documentazione in markdown. La prosa che spiega la modifica, non la modifica stessa. Quando pronunci un paragrafo che spiega perché una migrazione è rischiosa, Whisper se la cava benissimo. Quando provi a dettare la migrazione, ti aspetta un pomeriggio storto.
Il motivo è semplice. Il codice pronunciato non sopravvive al viaggio. Nomi di funzioni, JSON, snake_case contro camelCase, un flag di kubectl, un percorso di API: escono come un inglese fatto alla meglio e richiedono una correzione manuale. Un modello vocale sente "user underscore I D" e scrive "user ID", e adesso devi correggerlo. Quindi detta la frase che dice "questa PR corregge il controllo del null nel middleware di autenticazione", poi digita l'identificatore vero. La maggior parte dei corpi di issue e PR è comunque per l'80% spiegazione e per il 20% snippet di codice. Detta l'80, digita il 20.
Premi un hotkey, parla, ottieni il testo nel campo selezionato
Il meccanismo è lo stesso che useresti in qualsiasi altra app, ed è proprio questo il punto. Clicca nel campo di GitHub che vuoi riempire. Tieni premuto l'hotkey. Parla. Rilascia. La trascrizione compare al cursore.
L'hotkey predefinito è Ctrl+Space su Windows e Command+Option su macOS. Entrambi sono push-to-talk: tieni premuto mentre parli, rilascia per fermarti. Puoi cambiarli nelle impostazioni se vanno in conflitto con qualcos'altro, e se ti è mai capitato di combattere contro un conflitto di hotkey, capisci perché quell'impostazione si è guadagnata il suo posto (più sotto ne parlo meglio).
Un dettaglio onesto sulla portata. Whisper incolla nel singolo campo che hai selezionato, uno alla volta. Non compila un intero modulo di issue di GitHub in un solo fiato. Quindi il flusso per una nuova issue è: clicca sul titolo, dettalo, clicca sul corpo, detta quello. Due campi, due pressioni. Sembra meno una magia e più un dattilografo veloce che non tocca mai la tastiera. Questo è il modello mentale giusto.
L'intera app, dal vivo
Questa è l'app vera, in esecuzione proprio qui, non uno screenshot. Esplorala. Le impostazioni, il selettore degli hotkey e la scelta dei modelli sono quelli veri.
Un paio di cose utili da sapere mentre clicchi. Non c'è una scheda specifica per GitHub né una "modalità GitHub", perché non serve. Per Whisper, la descrizione di una PR di GitHub è un campo di testo come un altro. La stessa configurazione che detta nell'editor delle issue detta nella tua email e nel tuo IDE. La imposti una volta sola. La portata è proprio il punto di forza.
Dove conviene davvero: issue, descrizioni di PR, revisioni, discussioni
Il vantaggio sta nella scrittura noiosa e ripetitiva, quella che rimandi perché digitarla è una scocciatura.
Issue. Una buona segnalazione di bug è soprattutto un racconto: cosa hai fatto, cosa ti aspettavi, cosa è successo invece. È il terreno di casa della dettatura. Racconta i passaggi per riprodurre il problema come li spiegheresti a un collega alla tua scrivania, poi incolla lo stack trace a mano.
Descrizioni delle pull request. Il corpo della PR che tutti evitano di scrivere perché il diff "parla da sé" (non è vero). Detta il perché, il contesto di cui ha bisogno chi revisiona, e lascia che il diff racconti il cosa.
Revisioni del codice. I commenti di revisione sono dove il tono conta e dove le persone spiegano troppo poco. Pronunciare una nota di revisione tende a uscire più umana e più completa che digitarla tra una riunione e l'altra. Scriverai "questo funziona, ma si romperà quando la lista è vuota" invece di un semplice "caso limite?"
Discussions e documentazione. Prosa lunga, che è esattamente ciò in cui la voce è brava ed esattamente ciò che nessuno ha voglia di digitare. L'introduzione di un README, una risposta nelle Discussions, una guida alla migrazione: detta la bozza, sistema il markdown dopo. La stessa logica vale per dettare nei ticket di Jira e in altri tracker; GitHub è solo un altro campo nel mucchio.
Ripulisci la dettatura automaticamente
La dettatura grezza ha degli intercalari. "Ehm", "sai", la frase che hai iniziato due volte. Whisper ha un passaggio facoltativo di pulizia con l'IA che corregge intercalari, punteggiatura e maiuscole, così l'issue o la PR si legge come se l'avessi scritta con cura.
Ci sono due varianti. Nel piano locale gratuito, la pulizia gira sulla tua macchina tramite Ollama. In Pro, porti la tua chiave OpenAI e la pulizia gira nel cloud, con anche le risposte dal web disponibili. In entrambi i casi è facoltativa: disattivala e ottieni la trascrizione grezza. La tengo attiva per le descrizioni delle PR e disattivata per i commenti veloci, perché un commento veloce non ha bisogno di revisione e una descrizione di PR sì.
Una cosa che la pulizia non farà è salvare il codice pronunciato. Lucida l'inglese. Non sa che intendevi getUserById quando hai detto "get user by I D". Continua a dettare la prosa; continua a digitare gli identificatori.
Offline e privato: in modalità locale nulla esce dalla tua macchina

Se detti issue e PR su codice che non è pubblico, dove va a finire l'audio è importante. Nella modalità locale di Whisper, la trascrizione avviene interamente sulla tua macchina. Niente di ciò che dici viene inviato a un servizio cloud. Durante la trascrizione non serve alcuna connessione a internet: l'unica volta in cui vai online è il download una tantum del modello, che varia da circa 140 MB a 3 GB a seconda del modello che scegli.
Questo è l'unico punto su cui ti darò davvero un'opinione. La dettatura solo cloud è un disastro per la privacy in attesa di essere trascritto. Una volta ho visto un team interno accumulare una bolletta cloud a cinque cifre in un solo trimestre perché un prototipo di dettatura fatto in casa inviava ogni frase a un'API, e la parte peggiore non era la bolletta, ma il fatto che le note vocali di tutti su un prodotto non ancora rilasciato ora vivevano nei log di un fornitore. Il foglio degli stipendi del tuo capo, il problema di sicurezza che stai segnalando in privato, l'architettura proprietaria che stai descrivendo in una PR: niente di tutto questo dovrebbe lasciare il tuo laptop solo perché volevi scrivere un paragrafo con la voce. La tua macchina ha già un microfono e una CPU. Per un paragrafo, non serve un server di mezzo. Se il tuo strumento gira solo nel cloud, è la prima cosa che sistemerei.
A cosa non serve (scrivere codice)

Forse sei arrivato qui cercando un modo per scrivere codice a voce, oppure ricordi "Hey, GitHub!" e ti chiedi che fine abbia fatto. Due risposte oneste.
"Hey, GitHub!" e GitHub Copilot Voice erano un'anteprima tecnica di GitHub Next. GitHub ha interrotto l'anteprima nel 2024. Non è mai diventato un prodotto; ciò che si è imparato è confluito nell'estensione VS Code Speech. Quindi se un articolo di blog ti dice di attivare "Hey GitHub" oggi, è superato di un paio d'anni.
La corsia della voce per il codice esiste ancora: vive solo nel tuo editor e nel terminale, non su github.com. L'estensione VS Code Speech (a volte chiamata "Hey Code") ti permette di parlare all'editor e a Copilot Chat per codice e comandi. E GitHub Copilot CLI ha aggiunto di recente l'input vocale locale che guida l'agente Copilot nel terminale. Entrambi servono a pilotare il codice e un agente IA. Nessuno dei due detta prosa in un'issue di GitHub nel browser. Quella è una corsia diversa, ed è quella di cui Whisper è padrone: la scrittura attorno al codice.
Quando saltare Whisper per il tuo flusso di lavoro su GitHub
Preferisco che tu usi lo strumento giusto piuttosto che quello che faccio io. Ecco quindi quando saltare Whisper.
Se quello che vuoi davvero è pilotare Copilot o il tuo editor a voce ("correggi questa funzione", "esegui i test", "spiega questo blocco"), quella è la corsia del codice e dell'agente, non della prosa. Usa invece l'estensione VS Code Speech o l'input vocale di GitHub Copilot CLI. Quelli parlano alla macchina; Whisper scrive le parole che legge un essere umano.
Se detti solo qualche commento occasionale di una riga, il tuo sistema operativo lo fa già gratis. Premi Win+H su Windows o attiva la Dettatura su macOS, e puoi buttare giù una frase veloce in un campo di GitHub senza installare nulla. Whisper inizia a ripagarti quando scrivi paragrafi veri in tante app diverse, vuoi che funzioni offline, o vuoi un solo hotkey ovunque invece di una funzione del sistema operativo che copre solo alcuni campi. Sotto quella soglia, l'opzione integrata va benissimo, e non farò finta del contrario.
Locale gratuito, con Pro per il cloud
La pipeline locale (trascrizione, pulizia con l'IA sul dispositivo, hotkey, tutto ciò che ti serve per dettare in GitHub) è gratuita per gli utenti registrati, e non serve una carta al momento dell'iscrizione. Lo installi, accedi e inizi a dettare.
Whisper Pro aggiunge la parte cloud: trascrizione cloud OpenAI, pulizia con l'IA nel cloud usando la tua chiave e risposte dal web, con una breve prova per quel piano. Per dettare issue e PR, il piano locale gratuito copre tutto il lavoro. I numeri di Pro li trovi sulla pagina dei prezzi; non te li sciorinerò qui in mezzo a un paragrafo.
Un'ultima cosa su quell'hotkey
Due parole sul perché l'hotkey è personalizzabile, dato che lega insieme tutto il discorso. La prima versione di Whisper faceva scattare il suo stop-registrazione sei volte per ogni pressione su certe macchine Windows: eventi di rilascio fantasma del framework di input, di quelli che funzionano su un'installazione pulita e si rompono su una reale. Ci sono voluti un debounce di 300ms e più tempo di quanto sia disposto ad ammettere per renderlo affidabile. Ho imparato sulla gestione dell'input di Windows più di quanto avrei mai voluto. La lezione è rimasta: è l'hotkey a doversi piegare alla tua macchina, non il contrario. Clicca nel campo, tieni premuto il tasto, parla. Il codice continui a digitarlo tu, e credo che questa sia la versione onesta del patto.
Detta la tua prossima issue su GitHub
Clicca nel campo, tieni premuto il tasto, parla, rilascia. La trascrizione arriva dove si trova il cursore: nell'editor delle issue, nella descrizione della PR e in ogni altra app.
Modalità locale gratuita per qualsiasi account registrato. Nessuna carta richiesta per iniziare.



