VoiceCC

Voice-to-Command per AI coding CLI — Panoramica Progetto

Cos'è

VoiceCC è un sistema voice-to-command che permette di controllare AI coding CLI (CLI) tramite voce. L'utente parla, il sistema trascrive con Whisper (GPU locale), interpreta il comando vocale e lo inietta nella sessione terminale dove gira AI coding CLI — sia su WSL (tmux) che su Windows (PowerShell/Terminal).

Supporta comandi testuali diretti, tasti speciali (escape, invio, tab) e interazione intelligente con i prompt di AI coding CLI (selezione opzioni, conferme, input personalizzato, selezione multipla) — completamente a mani libere.

Architettura

graph TB
    User["Utente\nInput Vocale"] -->|"hotkey"| VE

    subgraph Windows
        VE["VoiceEmitter\nAudio Capture + Whisper STT\n+ Hotkey + System Tray"]
        WW["WindowsWorker\nRilevamento Terminale\n+ Iniezione PostMessage"]
        BR["Browser\nDashboard (React)"]
    end

    subgraph WSL / Linux
        HUB["SignalR Hub :5050\nMessage Broker + Filter Pipeline\n+ Choice Detection + Dashboard Statico"]
        TW["TmuxWorker\nSession Monitor\n+ Tmux Injector"]
        TMUX["tmux session 'cc'\nAI coding CLI"]
    end

    VE -->|"SignalR\ncomando vocale"| HUB
    WW -->|"SignalR\nstato sessione + risultati"| HUB
    HUB -->|"instrada comando\nal worker"| TW
    HUB -->|"instrada comando\nal worker"| WW
    TW -->|"send-keys"| TMUX
    WW -->|"PostMessage\nWM_CHAR"| Terminal["Windows Terminal"]
    BR -->|"SignalR"| HUB
    HUB -->|"eventi + stato"| BR
  

Stima Tempi di Sviluppo

Quanto ci metterebbe un developer super senior .NET/React a costruire tutto da zero, scrivendo tutto il codice a mano?

Dettaglio per Fase

Confronto Scenari

Dove va davvero il tempo

La Pipeline Windows (Fase 4) domina perché:

• L'iniezione PostMessage richiede reverse-engineering di comportamenti Win32 non documentati
• Il requisito dello scan code in lParam si scopre solo per tentativi
• UIAutomation per Windows Terminal è mal documentato — l'accesso TextPattern varia per versione del terminale
• Rilevare lo stato di AI coding CLI dalla status bar richiede lettura del contenuto terminale senza rubare il focus
• L'architettura dual SignalR (ruoli emitter + worker in un unico processo) non è banale

L'Intelligent Message (Fase 6) è il secondo collo di bottiglia:

• La ricerca dei keybinding di AI coding CLI va fatta manualmente — non esiste documentazione, si testa ogni tipo di prompt a mano
• Il parsing dello schermo deve gestire 5 tipi diversi di prompt con separatori e indicatori di selezione differenti
• Le differenze cross-platform (tmux usa '❯' U+276F, Windows usa '>' 0x3E) emergono solo durante i test
• Il mapping vocale multilingua (8 lingue, parole numeriche, parole azione) richiede test meticolosi

Whisper STT (Fase 2) nasconde complessità:

• Whisper.net stabile (1.9.0) non supporta beam search — serve la 1.9.1-preview1, scoperto dopo ore
• WithProbabilities() mostra 0% di confidence se non abilitato durante la creazione del processor, non dopo
• I language prompt devono essere NELLA lingua target (non "speak Italian" ma vocabolario italiano reale)
• Audio breve (<1s) causa hallucination ("thank you", "yeah") che necessitano di un filtro dedicato

Tempo Reale di Sviluppo (con AI coding CLI)

Il progetto è stato costruito con AI coding assistant che ha scritto ~90% del codice, diretto da un developer senior che ha progettato l'architettura e preso tutte le decisioni. Partenza da zero assoluto: nessun ambiente, nessun tool installato, solo l'idea. I 6 giorni includono tutto: setup ambiente, ricerca, architettura, sviluppo, test, deploy.

Dettaglio Giorno per Giorno

Stima vs Realtà

Osservazioni Chiave

1. Architettura + contratti + boilerplate = speedup 10–17x. L'AI genera DTO, interfacce, eventi, registrazioni DI, scaffolding SignalR hub, componenti React quasi istantaneamente. Quello che un umano fa in giorni di digitazione, l'AI lo produce in minuti.
2. Il Giorno 3 è stato sovrumano: 46 commit, 5 feature, 2 bugfix in 14 ore. L'intera pipeline Windows (UIAutomation + PostMessage + WindowsWorker + fix routing Hub) più la pipeline message filter costruite in un solo giorno. Questo volume di codice corretto e testato è fisicamente impossibile senza AI — non è questione di velocità di battitura, ma dell'ampiezza di conoscenza di dominio simultanea (Win32, SignalR, tmux, TDD).
3. Whisper.net + CUDA hanno comunque richiesto debug umano. Scoprire che beam search richiede un NuGet in preview, che WithProbabilities() va impostato alla creazione del processor, che i language prompt servono con vocabolario reale — sono gotcha non documentati dove l'AI può cercare ma l'umano deve verificare con l'esecuzione reale.
4. Da POC a produzione in ore, non giorni. Il POC dell'iniezione PostMessage è stato validato e trasformato in un WindowsWorker completo + integrato in VoiceEmitter in un solo pomeriggio. Un umano avrebbe bisogno del giorno di POC più 3–4 giorni per l'implementazione production.
5. I test sono stati "gratis" — scritti insieme al codice, non dopo. Con TDD guidato dall'AI, 245 test sono stati prodotti come sottoprodotto naturale dello sviluppo. Un umano che scrive 245 test a mano avrebbe bisogno di 5–6 giorni dedicati. Con l'AI, il costo del testing è stato essenzialmente zero — assorbito in ogni feature.
6. Effort umano totale: ~62 ore in 6 giorni, partendo da zero assoluto. Il lavoro umano è stato: setup ambiente, decisioni architetturali, prompting dell'AI, revisione output, test manuale con microfono reale + tmux + Windows Terminal e debug del comportamento Whisper/CUDA. L'equivalente manuale stimato è 62 giorni lavorativi (~500 ore). Accelerazione effettiva: ~10x.