Baby Monitor Timmy nació de una idea sencilla: un vigilabebés que respeta la privacidad en casa. Sin grabaciones en la nube ni salidas innecesarias de datos desde la habitación del bebé. Lo que mucha gente no ve es que desarrollo Timmy como proyecto en solitario en Zúrich, y GitHub Copilot es mi rapidísimo compañero de programación.
El flujo de trabajo entre una persona y la IA
La división está clara: yo defino las funciones, establezco prioridades y tomo las decisiones de arquitectura. Copilot ayuda con la implementación: escribe código, añade pruebas, ayuda a localizar errores y prepara los pasos necesarios para cada lanzamiento.
Para mí, un sprint típico se parece más o menos a esto:
- Descripción de la función: Describo qué debe hacer la función, incluidos los casos límite y las restricciones.
- Implementación: Copilot propone código y sigue las convenciones ya existentes del proyecto.
- Pruebas: Las pruebas automatizadas de extremo a extremo se ejecutan en dos emuladores y comprueban la conexión real entre el dispositivo del bebé y el de los padres.
- Distribución: Cuando las pruebas se superan, se preparan las compilaciones de Android e iOS para las tiendas y los canales de prueba correspondientes.
Este ciclo se repite para las funciones y las correcciones de errores. No escribo yo mismo cada línea, pero decido qué se desarrolla, por qué se desarrolla y si una propuesta encaja con Timmy.
Del concepto a WebRTC
La tarea técnica central estaba clara desde el principio: audio y vídeo en tiempo real entre dos teléfonos. WebRTC era la elección obvia, pero integrarlo con Flutter no es trivial: los candidatos ICE, la negociación SDP, la alternativa TURN y los DataChannels deben funcionar juntos en el orden correcto.
Copilot me ayudó a unir esas piezas paso a paso: configurar la conexión entre pares, mantener el orden crítico correcto (DataChannel antes de la oferta, onTrack antes de setRemoteDescription) y gestionar la señalización mediante Firebase Firestore. Cada parte tenía que funcionar en dos emuladores antes de seguir adelante.
Emparejamiento seguro con ECDH
Una de las funciones más críticas fue el sistema de emparejamiento seguro. Dos dispositivos deben establecer confianza mutua sin depender de un servidor central que avale su identidad. La solución: un intercambio de claves ECDH P-256 mediante Firebase, combinado con un número de verificación visual (SAS) que detecta ataques de intermediario.
Copilot ayudó a implementar la cadena criptográfica: generación de claves, intercambio de claves públicas, derivación del secreto compartido, cálculo del SAS y cifrado AES-256-GCM para todos los datos de señalización posteriores. No envío la clave de emparejamiento al backend; solo se usa su hash SHA-256 como identificador de documento de Firestore.
Auditoría de seguridad: encontrar y corregir vulnerabilidades
Para mí, el desarrollo asistido por IA no consiste solo en escribir más rápido. También ayuda a buscar errores de forma sistemática. En un sprint centrado en auditoría de seguridad, Copilot analizó la base de código y encontró seis problemas que tenía que corregir:
- Falta de validación de entrada en los datos de señalización
- Posibles condiciones de carrera al gestionar candidatos ICE
- Datos de sesión obsoletos que no se limpiaban correctamente
- Reglas de seguridad de Firestore demasiado permisivas
- Falta de consideración del anclaje de certificados
- Manejo insuficiente de errores en el flujo de credenciales TURN
Los seis se corrigieron en el mismo sprint. Aquí es donde Copilot destaca: lee muchos archivos, compara patrones y señala los puntos que debo revisar más de cerca.
Sprints iterativos: cómo evolucionó la aplicación
Timmy creció mediante sprints rápidos, pero con límites claros. Algunos hitos:
- v1.8: Rediseño completo del emparejamiento: el código de 4 caracteres + ECDH P-256 mediante Firebase sustituyó al anterior enfoque de clave directa.
- v1.10: Sprint de refuerzo de seguridad: ciclo de auditoría y corrección de las seis vulnerabilidades.
- v1.11: Modo oscuro en todas las pantallas, además de la página de inicio y el blog que estás leyendo ahora mismo.
- v1.12: Gran renovación de la pantalla para padres, modo de visión nocturna y detección de movimiento mediante el análisis de fotogramas de la cámara.
Todos los sprints siguen el mismo patrón básico: describir el objetivo, revisar las propuestas, ejecutar pruebas automáticas y distribuir la versión a los usuarios de prueba.
Pruebas E2E en distintos dispositivos
No se puede probar bien un vigilabebés en un solo dispositivo. Necesito un dispositivo para el bebé y otro para los padres. El proyecto empezó con dos emuladores Android funcionando simultáneamente, y ahora ese ciclo se complementa con comprobaciones locales en el simulador de iOS y en dispositivos reales. El script de pruebas automatizadas de Android sigue haciendo lo siguiente:
- Instala la aplicación en ambos emuladores
- Realiza el emparejamiento en ambos dispositivos
- Verifica que se establezcan las conexiones de audio y vídeo
- Prueba la función de pulsar para hablar, el control de la cámara y otras funciones
Como ambos emuladores comparten la misma dirección IP (10.0.2.15), una conexión directa de igual a igual mediante STUN es imposible. Cada prueba tiene que pasar por el relé TURN de Cloudflare. Es molesto, pero útil: la ruta de conexión más complicada se prueba cada vez.
Lo que aprendí
Desarrollar una aplicación completa con un programador en pareja basado en IA me enseñó algunas cosas:
- La arquitectura importa más que nunca. Las convenciones claras y una base de código bien documentada ayudan a la IA a proponer código coherente. La ambigüedad sale cara enseguida.
- Las pruebas no son negociables. El código generado por IA necesita las mismas pruebas rigurosas que el código escrito por personas. Las pruebas E2E automatizadas detectaron problemas que habría sido fácil pasar por alto manualmente.
- La persona sigue involucrada. Cada decisión de arquitectura, cada decisión que implica una contrapartida de seguridad y cada límite del producto siguen siendo responsabilidad mía. La IA acelera la implementación, pero no sustituye el criterio.
- La velocidad permite mejorar la calidad. Como las funciones se publican en horas en lugar de días, queda más margen para iterar, pulir y corregir errores. Ser rápido no significa automáticamente hacerlo bien.
De cara al futuro
Baby Monitor Timmy sigue evolucionando. El lanzamiento para iOS está cerca; después llegarán más funciones basadas en sensores y un refuerzo continuo de la seguridad. El flujo de trabajo seguirá siendo parecido: yo marco la dirección y los límites, y Copilot ayuda a implementar y comprobar todo rápidamente.
Los componentes relacionados con la seguridad están ahora claramente delimitados en el repositorio público baby-monitor-timmy-core. Allí también se documentan las decisiones de arquitectura sobre el emparejamiento, la señalización y las interfaces del backend.