Baby Monitor Timmy va néixer d'una idea senzilla: un vigilabebès que respecta la privadesa a casa. Sense enregistraments al núvol ni recorreguts innecessaris de dades fora de l'habitació del nadó. El que molta gent no veu és que desenvolupo Timmy com a projecte individual a Zúric, i GitHub Copilot és el meu company de programació, molt ràpid.
El flux de treball entre persones i IA
El repartiment és clar: jo defineixo les funcionalitats, marco les prioritats i prenc les decisions d'arquitectura. Copilot ajuda amb la implementació: escriure codi, afegir proves, acotar errors i preparar els passos de llançament.
Un esprint típic, a grans trets, és així:
- Descripció de la funcionalitat: Descric què ha de fer la funcionalitat, inclosos els casos límit i les restriccions.
- Implementació: Copilot suggereix codi i segueix les convencions ja existents del projecte.
- Proves: Les proves automatitzades d'extrem a extrem s'executen en dos emuladors i comproven la connexió real entre nadó i pare o mare.
- Distribució: Quan les proves passen, es preparen les compilacions d'Android i iOS per a les botigues i els canals de proves adequats.
Aquest cicle es repeteix per a funcionalitats i correccions d'errors. No escric cada línia jo mateix, però decideixo què es desenvolupa, per què es desenvolupa i si un suggeriment encaixa amb Timmy.
Del concepte a WebRTC
La tasca tècnica central era clara des del principi: àudio i vídeo en temps real entre dos telèfons. WebRTC era l'opció evident, però integrar-lo amb Flutter no és trivial: els candidats ICE, la negociació SDP, el recurs alternatiu TURN i els DataChannels han de funcionar junts en l'ordre correcte.
Copilot em va ajudar a ajuntar aquestes peces pas a pas: configurar la connexió entre iguals, mantenir l'ordre crític correcte (DataChannel abans de l'oferta, onTrack abans de setRemoteDescription), i posar la senyalització a Firebase Firestore. Cada peça havia de funcionar en dos emuladors abans de continuar.
Aparellament segur amb ECDH
Una de les funcionalitats més crítiques era el sistema d'aparellament segur. Dos dispositius han d'establir confiança mútua sense dependre d'un servidor central que avali la seva identitat. La solució: un intercanvi de claus ECDH P-256 a través de Firebase, combinat amb un número de verificació visual (SAS) que detecta atacs de tipus man-in-the-middle.
Copilot em va ajudar a implementar la cadena criptogràfica: generació de claus, intercanvi de claus públiques, derivació del secret compartit, càlcul del SAS i xifratge AES-256-GCM per a totes les dades de senyalització posteriors. No envio la clau d'aparellament al backend; només se'n fa servir el hash SHA-256 com a identificador de document de Firestore.
Auditoria de seguretat: detectar i corregir vulnerabilitats
Per a mi, el desenvolupament assistit per IA no és només escriure més ràpid. També ajuda a buscar errors de manera sistemàtica. En un esprint d'auditoria de seguretat centrat en aquest objectiu, Copilot va analitzar el codi i va trobar sis problemes que calia corregir:
- Falta de validació d'entrada a les dades de senyalització
- Possibles condicions de carrera en la gestió dels candidats ICE
- Dades de sessió antigues que no s'estaven netejant correctament
- Regles de seguretat de Firestore massa permissives
- Falta de consideracions sobre el certificate pinning
- Gestió d'errors insuficient en el flux de credencials TURN
Els sis es van corregir en el mateix esprint. Aquí és on Copilot destaca: llegint molts fitxers, comparant patrons i assenyalant els punts que he de revisar més de prop.
Esprints iteratius: com ha evolucionat l'aplicació
Timmy va créixer amb esprints ràpids però ben delimitats. Alguns moments clau:
- v1.8: Redisseny complet de l'aparellament: un codi de 4 caràcters + ECDH P-256 a través de Firebase va substituir l'antic enfocament de clau directa.
- v1.10: Esprint de reforç de seguretat: el cicle d'auditoria i correcció de les sis vulnerabilitats.
- v1.11: Mode fosc a totes les pantalles, a més de la pàgina principal i el blog que esteu llegint ara mateix.
- v1.12: Gran renovació de la pantalla per a pares i mares, mode de visió nocturna i detecció de moviment mitjançant l'anàlisi dels fotogrames de la càmera.
Cada esprint segueix el mateix patró bàsic: descriure l'objectiu, revisar els suggeriments, provar automàticament i després enviar-ho als provadors.
Proves E2E entre dispositius
No es pot provar bé un vigilabebès amb un sol dispositiu. Necessito un dispositiu per al nadó i un altre per al pare o la mare. El projecte va començar amb dos emuladors d'Android funcionant simultàniament i ara complementa aquest procés amb comprovacions locals en el simulador d'iOS i en dispositius reals. L'script de proves automatitzades d'Android encara:
- Instal·la l'aplicació en tots dos emuladors
- Navega pel procés d'aparellament en tots dos dispositius
- Verifica que s'estableixin les connexions d'àudio i vídeo
- Prova el sistema de prémer per parlar, el control de càmera i altres funcionalitats
Com que tots dos emuladors comparteixen la mateixa adreça IP (10.0.2.15), una connexió directa entre iguals mitjançant STUN és impossible. Cada execució de proves ha de passar pel relé TURN de Cloudflare. És molest, però útil: el camí de connexió més complicat es prova cada vegada.
Què he après
Desenvolupar una aplicació completa amb un programador en parella basat en IA m'ha ensenyat algunes coses:
- L'arquitectura importa més que mai. Les convencions clares i una base de codi ben documentada ajuden la IA a suggerir codi coherent. L'ambigüitat surt cara de seguida.
- Les proves no són negociables. El codi generat per IA necessita les mateixes proves rigoroses que el codi escrit per persones. Les proves E2E automatitzades van detectar problemes que hauria estat fàcil passar per alt manualment.
- La persona continua al centre. Cada decisió d'arquitectura, cada compromís de seguretat i cada límit de producte continua sent responsabilitat meva. La IA accelera la implementació, però no substitueix el criteri.
- La velocitat permet qualitat. Com que les funcionalitats es publiquen en hores en lloc de dies, queden més iteracions per polir i corregir errors. Ràpid no vol dir automàticament bo.
Mirant endavant
Baby Monitor Timmy continua evolucionant. El llançament per a iOS és a prop; després vindran funcionalitats de sensors addicionals i un reforç de seguretat continu. El flux de treball es manté semblant: jo marco la direcció i els límits, i Copilot ajuda a implementar i comprovar ràpidament.
Els components rellevants per a la seguretat ara es troben sota límits clars al repositori públic baby-monitor-timmy-core. Allà també es documenten les decisions d'arquitectura sobre l'aparellament, la senyalització i les interfícies del backend.