Baby Monitor Timmy naceu dunha idea sinxela: un vixilabebés que respecte a privacidade no fogar. Sen gravacións na nube nin rutas de datos innecesarias que saian do cuarto do bebé. O que moita xente non ve é que desenvolvo Timmy eu só en Zúric, e GitHub Copilot é o meu compañeiro de programación moi rápido.
O fluxo de traballo entre persoa e IA
A repartición está clara: eu defino as funcións, establezo prioridades e tomo decisións de arquitectura. Copilot axuda coa implementación: escribir código, engadir probas, acoutar erros e preparar os pasos de publicación.
Un sprint típico para min é máis ou menos así:
- Descrición da función: Describo o que debe facer a función, incluídos os casos límite e as restricións.
- Implementación: Copilot propón código e segue as convencións xa existentes no proxecto.
- Probas: As probas automatizadas de extremo a extremo execútanse en dous emuladores e comproban a conexión real entre bebé e persoa coidadora.
- Distribución: Cando pasan as probas, prepáranse as compilacións de Android e iOS para a tenda e as canles de probas axeitadas.
Este ciclo repítese para novas funcións e correccións de erros. Non escribo cada liña eu mesmo, pero decido que se desenvolve, por que se desenvolve e se unha proposta encaixa con Timmy.
Do concepto a WebRTC
A tarefa técnica central estaba clara desde o comezo: audio e vídeo en tempo real entre dous teléfonos. WebRTC era a elección evidente, pero integralo con Flutter non é trivial: os candidatos ICE, a negociación SDP, a alternativa mediante TURN e os DataChannels deben funcionar xuntos na orde correcta.
Copilot axudoume a xuntar esas pezas paso a paso: configurar a conexión entre pares, manter correcta a orde crítica (DataChannel antes da oferta, onTrack antes de setRemoteDescription) e montar a sinalización en Firebase Firestore. Cada parte tiña que funcionar en dous emuladores antes de seguir adiante.
Emparellamento seguro con ECDH
Unha das funcións máis críticas foi o sistema de emparellamento seguro. Dous dispositivos deben establecer confianza mutua sen depender dun servidor central que avale a súa identidade. A solución: un intercambio de claves ECDH P-256 mediante Firebase, combinado cun número de verificación visual (SAS) que detecta ataques de intermediario.
Copilot axudou a implementar a cadea criptográfica: xeración de claves, intercambio de claves públicas, derivación do segredo compartido, cálculo do SAS e cifrado AES-256-GCM para todos os datos de sinalización posteriores. Non envío a clave de emparellamento ao backend; só se usa o seu hash SHA-256 como identificador dun documento de Firestore.
Auditoría de seguridade: atopar e corrixir vulnerabilidades
Para min, o desenvolvemento asistido por IA non é só escribir máis rápido. Tamén axuda a buscar erros de forma sistemática. Nun sprint centrado nunha auditoría de seguridade, Copilot analizou a base de código e atopou seis problemas que tiña que corrixir:
- Falta de validación de entrada nos datos de sinalización
- Posibles condicións de carreira na xestión de candidatos ICE
- Datos de sesión obsoletos que non se limpaban correctamente
- Regras de seguridade de Firestore demasiado permisivas
- Falta de consideracións sobre certificate pinning
- Xestión insuficiente de erros no fluxo de credenciais TURN
Os seis problemas corrixíronse no mesmo sprint. Aquí é onde Copilot destaca: lendo moitos ficheiros, comparando patróns e sinalando os puntos que teño que revisar máis de preto.
Sprints iterativos: como evolucionou a aplicación
Timmy medrou mediante sprints rápidos pero con límites claros. Algúns fitos:
- v1.8: Redeseño completo do emparellamento — un código de 4 caracteres + ECDH P-256 mediante Firebase substituíu o antigo enfoque de clave directa.
- v1.10: Sprint de reforzo da seguridade — auditoría das seis vulnerabilidades e ciclo de corrección.
- v1.11: Modo escuro en todas as pantallas, ademais da páxina principal e o blog que estás lendo agora.
- v1.12: Gran renovación da pantalla da persoa coidadora, modo de visión nocturna e detección de movemento mediante análise dos fotogramas da cámara.
Cada sprint segue o mesmo patrón básico: describir o obxectivo, revisar as propostas, probar automaticamente e despois envialo ás persoas probadoras.
Probas E2E entre dispositivos
Non se pode probar ben un vixilabebés nun só dispositivo. Necesito un dispositivo para o bebé e outro para a persoa coidadora. O proxecto comezou con dous emuladores de Android executándose á vez e agora complementa ese ciclo con comprobacións locais no simulador de iOS e en dispositivos reais. O script de probas automatizadas de Android aínda:
- Instala a aplicación nos dous emuladores
- Guía o emparellamento nos dous dispositivos
- Verifica que se establecen as conexións de audio e vídeo
- Proba o push-to-talk, o control da cámara e outras funcións
Como ambos os emuladores comparten o mesmo enderezo IP (10.0.2.15), unha conexión directa entre pares mediante STUN é imposible. Cada execución de probas ten que pasar polo relé TURN de Cloudflare. É molesto, pero útil: en cada proba compróbase a ruta de conexión máis complicada.
O que aprendín
Desenvolver unha aplicación completa cun compañeiro de programación baseado en IA ensinoume algunhas cousas:
- A arquitectura importa máis ca nunca. Unhas convencións claras e unha base de código ben documentada axudan á IA a propoñer código coherente. A ambigüidade encarece o traballo moi rápido.
- As probas non son negociables. O código xerado por IA necesita as mesmas probas rigorosas ca o código escrito por persoas. As probas E2E automatizadas detectaron problemas que sería fácil pasar por alto manualmente.
- A persoa segue no proceso. Cada decisión de arquitectura, cada concesión en materia de seguridade e cada límite do produto seguen sendo responsabilidade miña. A IA acelera a implementación, pero non substitúe o criterio.
- A velocidade permite mellorar a calidade. Como as funcións se publican en horas en vez de días, queda máis marxe para iterar, pulir e corrixir erros. Ser rápido non significa automaticamente facelo ben.
Mirando cara ao futuro
Baby Monitor Timmy segue evolucionando. A versión para iOS está preto; despois chegarán máis funcións de sensores e un reforzo continuo da seguridade. O fluxo de traballo será parecido: eu marco a dirección e os límites, e Copilot axuda a implementar e comprobar con rapidez.
Os compoñentes relevantes para a seguridade están agora baixo límites claros no repositorio público baby-monitor-timmy-core. Alí tamén se documentan as decisións de arquitectura sobre o emparellamento, a sinalización e as interfaces do backend.