Voice coding: programmare con la voce, code review e commit

«Programmare con la voce» di solito suona da pagliacciata. Il video del 2017 in cui uno sviluppatore urla «open paren if foo equals equals null close paren» — è un meme, non un workflow. Anche io ho pensato a lungo che l'idea fosse morta.

Commander Flow mi ha fatto cambiare punto di vista. Non perché abbia aggiunto una magica modalità «dettatura del codice». Ma perché il codice non è solo codice. Il codice sono commit, ticket, code-review, documentazione, commenti, nomi, chat con i colleghi. E tutto ciò che sta intorno al codice — adesso lo faccio a voce.

Dove la voce cambia davvero la vita di uno sviluppatore

L'operazione vocale che faccio più spesso sono i messaggi di commit. Posiziono il cursore in git commit -m "...", tengo il tasto, dico qualcosa come «risolvo race condition nella cancellazione della pipeline, cancello correttamente il token quando la scorciatoia viene premuta di nuovo», e nel terminale arriva un messaggio pronto secondo conventional commits, perché ho impostato le regole una volta a voce e le ricorda.

Le descrizioni delle PR sono quasi uguali, solo più lunghe. Apro il template di GitHub PR, detto come spiegherei a un junior — cosa cambia, perché, cosa non tocchiamo, come testare. In pochi secondi ottengo un markdown ordinato con titoli ## Context, ## Changes, ## Test plan. Prima ci voleva qualche minuto, adesso secondi.

La cosa che mi ha ribaltato di più sono i commenti di code-review. Prima ero pigro a scrivere review approfondite: troppa scrittura per qualcosa che si legge e si dimentica. Adesso seleziono la riga, detto a voce il pensiero, ottengo un commento chiaro e rifinito letteralmente in un paio di secondi. Le mie review sono diventate molto più lunghe e nettamente più utili, e il team se ne accorge.

Categoria a parte: la documentazione. La parte più dolorosa del mestiere. Detto la docstring come la spiegherei a un collega, e Commander Flow la riconduce allo stile XML-doc, TSDoc o markdown — a seconda del linguaggio del progetto. La documentazione ha smesso di essere la tassa che pago al codice.

«Non scrivo codice con la voce. Scrivo tutto ciò che circonda il codice con la voce. E ho capito che è metà del mio lavoro.»

La modalità code-comments: una cosa a parte che amo

Per questo dico semplicemente a voce «lascialo come commento di codice» — e Commander Flow:

• Non tocca gli identificatori in latino (variable names, class names)
• Mantiene i termini (kubectl, async/await, useEffect, OAuth) nella forma originale
• Non aggiunge formule di cortesia «di troppo» (tanto nessuno scrive «gentili lettori» nei commenti al codice)
• Gestisce correttamente due alfabeti nello stesso commento: // verifichiamo che Subscription.IsActive prima di chiamare BillingService.Refresh

Sembra una sciocchezza. Ma senza quell'indizio vocale, le prime build alpha a volte «nobilitavano» il mio commento tecnico fino allo stato di «verifichiamo se il nostro oggetto di business della sottoscrizione sia corretto».

Il dizionario dei termini — funzione sottovalutata

In PolishOptions.Dictionary butto i miei termini e abbreviazioni. Ho lì:

• kubectl, helm, argocd, flux
• IDictionary, IAsyncEnumerable, Span<T>
• ConfigureAwait(false) (intero, come frase — perché la LLM non la riscriva)
• Acronimi aziendali, nomi dei servizi interni

Dopo questo la LLM smette di «migliorare» i termini specifici, lasciandoli esattamente come li ho nominati.

Lo scenario che mi convince ogni giorno

10:30, sono nell'IDE, accanto la chat del team, accanto Linear con un ticket. Tengo la scorciatoia e dico:

«Estratta la logica di retry in una classe a parte RetryPolicy con backoff esponenziale, aggiunti i test, controllate anche il sequence diagram nel ticket prima del merge»

Va in Linear come commento al ticket. Poi — Alt+Tab in Slack, stessa scorciatoia:

«team, ho aperto la PR per review, non bloccante ma preferibilmente oggi»

Stile Slack, in minuscolo, senza «gentili colleghi». Poi — di nuovo nell'IDE.

Tre azioni in tre applicazioni, tutto a voce, dita zero.

Dove sono inciampato

Punteggiatura nel codice che cade nella dettatura. Se detto un blocco «questa funzione restituisce Task<bool>», a volte la LLM «pensa» che Task<bool> sia HTML e prova a fare l'escape. Risolto aggiungendo il termine al dizionario, ma all'inizio mi stupiva.

Conflitti di scorciatoie con l'IDE. Il mio IDE ha le sue hotkey. La scorciatoia di Commander Flow ho dovuto riassegnarla un paio di volte per non andare in conflitto. Adesso è su Caps Lock — il tasto più comodo e meno usato. Piccolo fastidio, risolto con un clic nelle impostazioni.

Le modalità più pesanti possono «pensare» un po' più lente nell'IDE. Per un'email i millisecondi in più non si notano. Per un commento al codice «qui e ora» si notano. Sono passato alla modalità intermedia per il portatile da lavoro e ho lasciato la più potente per il desktop con GPU dedicata. La latenza è scomparsa.

Cosa ho capito della voce come interfaccia di programmazione

La voce non sostituisce la tastiera nell'IDE. La integra dove la tastiera era lo strumento peggiore. Scrivere if (x != null && y != null) — tastiera. Spiegare perché serve quel controllo — voce.

Tra questi due compiti c'è un abisso di carico cognitivo, e non si «risolvono» allo stesso modo con la scrittura. Ho smesso di costringermi a scrivere il secondo tipo di task. Mi è venuto più facile.

Cosa ho preso da questa proporzione

Il voice coding non è «dettare codice». È spostare cosa esattamente fai con la voce. La logica la scrivi a mano, tutto ciò che è umano intorno alla logica — con la voce.

In dieci anni nel mestiere non avevo trovato proporzione più comoda.