Baby Monitor Timmy è nato da un'idea semplice: un baby monitor che rispetta la privacy in casa. Niente registrazioni nel cloud, nessun inutile trasferimento di dati fuori dalla cameretta. Quello che molti non vedono è che sviluppo Timmy da solo a Zurigo, e GitHub Copilot è il mio velocissimo partner di programmazione.
Il flusso di lavoro tra persona e IA
La divisione è chiara: definisco le funzionalità, stabilisco le priorità e prendo le decisioni architetturali. Copilot mi aiuta nell'implementazione: scrive codice, aggiunge test, aiuta a circoscrivere i bug e prepara le fasi di rilascio.
Per me, uno sprint tipico è più o meno così:
- Descrizione della funzionalità: Descrivo cosa deve fare la funzionalità, inclusi casi limite e vincoli.
- Implementazione: Copilot propone il codice e segue le convenzioni già presenti nel progetto.
- Test: I test end-to-end automatizzati vengono eseguiti su due emulatori e verificano la connessione reale tra il dispositivo del bambino e quello del genitore.
- Distribuzione: Quando i test passano, vengono preparate le build Android e iOS per gli store e i canali di test appropriati.
Questo ciclo si ripete per funzionalità e correzioni di bug. Non scrivo ogni riga di codice, ma decido cosa viene sviluppato, perché viene sviluppato e se un suggerimento è adatto a Timmy.
Dal concetto a WebRTC
Il compito tecnico centrale era chiaro fin dall'inizio: audio e video in tempo reale tra due telefoni. WebRTC era la scelta ovvia, ma integrarlo con Flutter non è banale: candidati ICE, negoziazione SDP, fallback TURN e DataChannel devono funzionare insieme nel giusto ordine.
Copilot mi ha aiutato a mettere insieme questi elementi passo dopo passo: configurare la peer connection, mantenere corretto l'ordine critico (DataChannel prima dell'offerta, onTrack prima di setRemoteDescription) e usare Firebase Firestore per il signaling. Ogni parte doveva funzionare su due emulatori prima di passare alla successiva.
Abbinamento sicuro con ECDH
Una delle funzionalità più importanti era il sistema di abbinamento sicuro. Due dispositivi devono instaurare un rapporto di fiducia reciproca senza affidarsi a un server centrale che attesti la loro identità. La soluzione: uno scambio di chiavi ECDH P-256 tramite Firebase, combinato con un numero di verifica visivo (SAS) che rileva gli attacchi man-in-the-middle.
Copilot ha aiutato a implementare la catena crittografica: generazione delle chiavi, scambio delle chiavi pubbliche, derivazione del segreto condiviso, calcolo del SAS e crittografia AES-256-GCM per tutti i dati di signaling successivi. Non invio la chiave di abbinamento al backend; solo il suo hash SHA-256 viene usato come identificatore del documento Firestore.
Audit di sicurezza: individuare e correggere le vulnerabilità
Per me, lo sviluppo assistito dall'IA non significa solo scrivere più velocemente. Aiuta anche nella ricerca sistematica dei bug. Durante uno sprint mirato di audit della sicurezza, Copilot ha analizzato la base di codice e ha trovato sei problemi che dovevo correggere:
- Mancata convalida dell'input nei dati di signaling
- Possibili condizioni di concorrenza nella gestione dei candidati ICE
- Dati di sessione obsoleti che non venivano puliti correttamente
- Regole di sicurezza Firestore troppo permissive
- Mancata considerazione del certificate pinning
- Gestione degli errori insufficiente nel flusso delle credenziali TURN
Tutti e sei sono stati corretti nello stesso sprint. Qui Copilot dà il meglio: legge molti file, confronta schemi e segnala i punti che devo controllare più da vicino.
Sprint iterativi: come si è evoluta l'app
Timmy è cresciuto attraverso sprint rapidi ma ben delimitati. Alcune tappe:
- v1.8: Riprogettazione completa dell'abbinamento — il codice di 4 caratteri + ECDH P-256 tramite Firebase ha sostituito il precedente approccio con chiave diretta.
- v1.10: Sprint di rafforzamento della sicurezza — ciclo di audit e correzione delle sei vulnerabilità.
- v1.11: Modalità scura in tutte le schermate, oltre alla home page e al blog che stai leggendo ora.
- v1.12: Importante revisione della schermata del genitore, modalità visione notturna e rilevamento del movimento tramite analisi dei fotogrammi della fotocamera.
Ogni sprint segue lo stesso schema di base: descrivere l'obiettivo, rivedere i suggerimenti, testare automaticamente e poi distribuire ai tester.
Test E2E su più dispositivi
Non puoi testare bene un baby monitor su un solo dispositivo. Mi servono un dispositivo per il bambino e uno per il genitore. Il progetto è iniziato con due emulatori Android in esecuzione contemporaneamente e ora integra quel ciclo con controlli su un simulatore iOS locale e su dispositivi reali. Lo script di test Android automatizzato continua a:
- Installare l'app su entrambi gli emulatori
- Eseguire la procedura di abbinamento su entrambi i dispositivi
- Verificare che le connessioni audio e video siano stabilite
- Testare il push-to-talk, il controllo della fotocamera e altre funzionalità
Poiché entrambi gli emulatori condividono lo stesso indirizzo IP (10.0.2.15), una connessione peer-to-peer diretta tramite STUN è impossibile. Ogni esecuzione dei test deve passare dal relay TURN di Cloudflare. È fastidioso, ma utile: il percorso di connessione più complesso viene testato ogni volta.
Cosa ho imparato
Sviluppare un'app completa insieme a un partner di programmazione basato sull'IA mi ha insegnato alcune cose:
- L'architettura conta più che mai. Convenzioni chiare e una base di codice ben documentata aiutano l'IA a suggerire codice coerente. L'ambiguità diventa costosa molto in fretta.
- I test non sono negoziabili. Il codice generato dall'IA richiede gli stessi test rigorosi del codice scritto dalle persone. I test E2E automatizzati hanno individuato problemi che sarebbe stato facile non notare manualmente.
- La persona resta coinvolta. Ogni decisione architetturale, ogni compromesso sulla sicurezza e ogni confine del prodotto restano sotto la mia responsabilità. L'IA accelera l'implementazione, ma non sostituisce il giudizio.
- La velocità rende possibile la qualità. Poiché le funzionalità vengono rilasciate in ore anziché giorni, resta più tempo per iterare, rifinire e correggere bug. La velocità, da sola, non garantisce la qualità.
Uno sguardo al futuro
Baby Monitor Timmy continua a evolversi. Il rilascio per iOS è vicino; poi arriveranno ulteriori funzionalità dei sensori e un continuo rafforzamento della sicurezza. Il flusso di lavoro resta simile: io definisco direzione e limiti, Copilot aiuta a implementare e verificare rapidamente.
Gli elementi fondamentali rilevanti per la sicurezza sono ora racchiusi entro confini ben definiti nel repository pubblico baby-monitor-timmy-core. È anche lì che sono documentate le decisioni architetturali relative ad abbinamento, signaling e interfacce backend.