O Baby Monitor Timmy começou com uma ideia simples: um intercomunicador para bebé que respeita a privacidade em casa. Sem gravações na nuvem, sem percursos desnecessários dos dados para fora do quarto do bebé. O que muitas pessoas não veem: desenvolvo o Timmy sozinho, em Zurique, e GitHub Copilot é o meu parceiro de programação, muito rápido.
O fluxo de trabalho entre humano e IA
A divisão é clara: defino funcionalidades, estabeleço prioridades e tomo decisões de arquitetura. O Copilot ajuda na implementação: escrever código, acrescentar testes, isolar erros e preparar os passos de lançamento.
Para mim, um sprint típico é mais ou menos assim:
- Descrição da funcionalidade: Descrevo o que a funcionalidade deve fazer, incluindo casos limite e restrições.
- Implementação: O Copilot sugere código e segue as convenções já existentes do projeto.
- Testes: Os testes automatizados end-to-end são executados em dois emuladores e verificam a ligação real entre o dispositivo do bebé e o dos pais.
- Distribuição: Quando os testes passam, as compilações Android e iOS são preparadas para as lojas e canais de teste adequados.
Este ciclo repete-se para funcionalidades e correções de erros. Não escrevo todas as linhas, mas decido o que é desenvolvido, porquê é desenvolvido e se uma sugestão se adequa ao Timmy.
Do conceito ao WebRTC
A principal tarefa técnica foi clara desde o início: áudio e vídeo em tempo real entre dois telemóveis. O WebRTC era a escolha óbvia, mas integrá-lo com o Flutter não é simples: os candidatos ICE, a negociação SDP, o recurso ao TURN e os DataChannels têm de funcionar em conjunto e na ordem certa.
O Copilot ajudou-me a juntar estas peças passo a passo: configurar a ligação entre pares, manter a ordem crítica correta (DataChannel antes da oferta, onTrack antes de setRemoteDescription) e colocar a sinalização no Firebase Firestore. Cada parte tinha de funcionar em dois emuladores antes de eu avançar.
Emparelhamento seguro com ECDH
Uma das funcionalidades mais críticas foi o sistema de emparelhamento seguro. Dois dispositivos precisam de estabelecer confiança mútua sem depender de um servidor central que confirme a respetiva identidade. A solução: uma troca de chaves ECDH P-256 através do Firebase, combinada com um número de verificação visual (SAS) que deteta ataques man-in-the-middle.
O Copilot ajudou a implementar a cadeia criptográfica: geração de chaves, troca de chaves públicas, derivação do segredo partilhado, cálculo do SAS e encriptação AES-256-GCM para todos os dados de sinalização posteriores. Não envio a chave de emparelhamento para o backend; só o respetivo hash SHA-256 é usado como identificador de documento do Firestore.
Auditoria de segurança: encontrar e corrigir vulnerabilidades
Para mim, o desenvolvimento assistido por IA não é apenas escrever mais depressa. Também ajuda a procurar erros de forma sistemática. Num sprint de auditoria de segurança focado, o Copilot analisou a base de código e encontrou seis problemas que precisava de corrigir:
- Falta de validação de entradas nos dados de sinalização
- Possíveis condições de corrida no tratamento dos candidatos ICE
- Dados de sessão desatualizados que não estavam a ser limpos corretamente
- Regras de segurança do Firestore demasiado permissivas
- Falta de considerações relativas à fixação de certificados
- Tratamento de erros insuficiente no fluxo de credenciais TURN
Os seis problemas foram corrigidos no mesmo sprint. É aqui que o Copilot é forte: lê muitos ficheiros, compara padrões e assinala os pontos que preciso de analisar mais de perto.
Sprints iterativos: como a aplicação evoluiu
O Timmy cresceu através de sprints rápidos, mas com limites bem definidos. Alguns marcos:
- v1.8: Reformulação completa do emparelhamento — o código de 4 caracteres + ECDH P-256 através do Firebase substituiu a antiga abordagem de chave direta.
- v1.10: Sprint de reforço da segurança — o ciclo de auditoria e correção das seis vulnerabilidades.
- v1.11: Modo escuro em todos os ecrãs, além da página inicial e do blogue que está a ler agora.
- v1.12: Grande reformulação do ecrã dos pais, modo de visão noturna e deteção de movimento através da análise dos fotogramas da câmara.
Todos os sprints seguem o mesmo padrão básico: descrever o objetivo, rever sugestões, testar automaticamente e depois disponibilizar a versão aos testadores.
Testes E2E entre dispositivos
Não é possível testar corretamente um intercomunicador para bebé num só dispositivo. Preciso de um dispositivo para o bebé e de outro para os pais. O projeto começou com dois emuladores Android a funcionar em simultâneo e agora complementa esse ciclo com verificações locais no simulador iOS e em dispositivos reais. O script automatizado de testes para Android continua a:
- Instalar a aplicação em ambos os emuladores
- Percorrer o emparelhamento nos dois dispositivos
- Verificar que as ligações de áudio e vídeo são estabelecidas
- Testar a função push-to-talk, o controlo da câmara e outras funcionalidades
Como ambos os emuladores partilham o mesmo endereço IP (10.0.2.15), é impossível estabelecer uma ligação direta entre pares através de STUN. Cada execução dos testes tem de passar pelo servidor de retransmissão TURN da Cloudflare. É incómodo, mas útil: o percurso de ligação mais complexo é testado de todas as vezes.
O que aprendi
Desenvolver uma aplicação completa com um parceiro de programação baseado em IA ensinou-me algumas coisas:
- A arquitetura é mais importante do que nunca. Convenções claras e uma base de código bem documentada ajudam a IA a sugerir código consistente. A ambiguidade depressa sai cara.
- Testar não é negociável. O código gerado por IA precisa de testes tão rigorosos como o código escrito por pessoas. Os testes E2E automatizados detetaram problemas que poderiam facilmente passar despercebidos em testes manuais.
- A pessoa mantém-se no processo. Todas as decisões de arquitetura, todas as decisões de compromisso em matéria de segurança e todos os limites do produto continuam a ser da minha responsabilidade. A IA acelera a implementação, mas não substitui o discernimento humano.
- A rapidez permite qualidade. Como as funcionalidades são lançadas em horas em vez de dias, sobra mais tempo para aperfeiçoamentos e correções de erros. Ser rápido não significa automaticamente fazer um bom trabalho.
Perspetivas futuras
O Baby Monitor Timmy continua a evoluir. O lançamento para iOS está próximo; a seguir virão funcionalidades adicionais de sensores e o reforço contínuo da segurança. O fluxo de trabalho mantém-se semelhante: eu defino a direção e os limites, e o Copilot ajuda a implementar e verificar rapidamente.
Os componentes relevantes para a segurança estão agora organizados segundo limites claros no repositório público baby-monitor-timmy-core. É também aí que estão documentadas as decisões de arquitetura relativas ao emparelhamento, à sinalização e às interfaces de backend.