Baby Monitor Timmy startet med en enkel idé: en babyalarm som respekterer personvernet hjemme. Ingen opptak i skyen, ingen unødvendige dataflyter ut av barnerommet. Det mange ikke ser, er at jeg bygger Timmy som et soloprosjekt i Zürich, og GitHub Copilot er min svært raske parprogrammerer.
Arbeidsflyten mellom menneske og KI
Fordelingen er tydelig: Jeg definerer funksjoner, setter prioriteringer og tar arkitekturbeslutninger. Copilot hjelper til med implementeringen: å skrive kode, legge til tester, snevre inn feil og forberede utgivelsessteg.
En typisk sprint ser omtrent slik ut for meg:
- Funksjonsbeskrivelse: Jeg beskriver hva funksjonen skal gjøre, inkludert spesialtilfeller og begrensninger.
- Implementering: Copilot foreslår kode og følger prosjektets eksisterende konvensjoner.
- Testing: Automatiserte ende-til-ende-tester kjører på to emulatorer og kontrollerer den faktiske forbindelsen mellom baby- og foreldreenheten.
- Distribusjon: Når testene består, klargjøres Android- og iOS-byggene for de riktige butikk- og testkanalene.
Denne syklusen gjentas for funksjoner og feilrettinger. Jeg skriver ikke hver linje selv, men jeg avgjør hva som bygges, hvorfor det bygges, og om et forslag passer for Timmy.
Fra konsept til WebRTC
Den sentrale tekniske oppgaven var klar fra starten: lyd og video i sanntid mellom to telefoner. WebRTC var det naturlige valget, men integrasjonen med Flutter er ikke triviell: ICE-kandidater, SDP-forhandling, TURN-reserve og DataChannels må fungere sammen i riktig rekkefølge.
Copilot hjalp meg med å sette disse delene sammen steg for steg: konfigurere peer-forbindelsen, holde den kritiske rekkefølgen riktig (DataChannel før tilbud, onTrack før setRemoteDescription), og legge signaleringen i Firebase Firestore. Hver del måtte kjøre på to emulatorer før jeg gikk videre.
Trygg sammenkobling med ECDH
En av de mest kritiske funksjonene var det sikre sammenkoblingssystemet. To enheter må etablere gjensidig tillit uten å være avhengige av at en sentral server går god for identiteten deres. Løsningen: en ECDH P-256-nøkkelutveksling over Firebase, kombinert med et visuelt bekreftelsesnummer (SAS) som oppdager mann-i-midten-angrep.
Copilot hjalp til med å implementere den kryptografiske kjeden: nøkkelgenerering, utveksling av offentlige nøkler, utledning av delt hemmelighet, SAS-beregning og AES-256-GCM-kryptering for alle senere signaleringsdata. Jeg sender ikke sammenkoblingsnøkkelen til backend; bare SHA-256-hashen brukes som dokumentidentifikator i Firestore.
Sikkerhetsrevisjon: Å finne og rette sårbarheter
KI-assistert utvikling handler ikke bare om raskere skriving for meg. Den hjelper også med systematisk feiljakt. I en målrettet sprint for sikkerhetsrevisjon analyserte Copilot kodebasen og fant seks problemer jeg måtte rette:
- Manglende validering av inndata i signaleringsdata
- Mulige konkurransetilstander i håndteringen av ICE-kandidater
- Utdaterte øktdata som ikke ble ryddet opp på riktig måte
- Firestore-sikkerhetsregler som var for åpne
- Manglende vurderinger av sertifikatpinning
- Utilstrekkelig feilhåndtering i flyten for TURN-legitimasjon
Alle seks ble rettet i samme sprint. Her er Copilot sterk: å lese mange filer, sammenligne mønstre og markere steder jeg må undersøke nærmere.
Iterative sprinter: Slik utviklet appen seg
Timmy vokste gjennom raske, men tydelig avgrensede sprinter. Noen milepæler:
- v1.8: Fullstendig redesign av sammenkoblingen — en kode på 4 tegn + ECDH P-256 over Firebase erstattet den gamle løsningen med direkte nøkkel.
- v1.10: Sprint for sikkerhetsforbedringer — gjennomgang og retting av de seks sårbarhetene.
- v1.11: Mørk modus på alle skjermer, i tillegg til forsiden og bloggen du leser nå.
- v1.12: Omfattende oppgradering av foreldreskjermen, nattsynsmodus og bevegelsesdeteksjon via analyse av kamerabilder.
Hver sprint følger det samme grunnmønsteret: beskriv målet, gjennomgå forslagene, test automatisk og send deretter ut til testere.
E2E-testing på tvers av enheter
Du kan ikke teste en babyalarm ordentlig på én enhet. Jeg trenger én babyenhet og én foreldreenhet. Prosjektet startet med to Android-emulatorer som kjørte samtidig, og denne testsyklusen suppleres nå med en lokal iOS-simulator og kontroller på fysiske enheter. Det automatiserte Android-testskriptet gjør fortsatt følgende:
- Installerer appen på begge emulatorene
- Går gjennom sammenkoblingen på begge enhetene
- Kontrollerer at lyd- og videoforbindelser opprettes
- Tester trykk-og-snakk, kamerastyring og andre funksjoner
Siden begge emulatorene deler samme IP-adresse (10.0.2.15), er en direkte peer-to-peer-forbindelse via STUN umulig. Hver testkjøring må gå gjennom Cloudflare TURN-reléet. Det er irriterende, men nyttig: Den mest kompliserte tilkoblingsveien testes hver gang.
Hva jeg lærte
Å bygge en komplett app med en KI-parprogrammerer lærte meg noen ting:
- Arkitektur betyr mer enn noen gang. Tydelige konvensjoner og en godt dokumentert kodebase hjelper KI-en med å foreslå konsekvent kode. Uklarhet blir raskt dyrt.
- Testing er ikke valgfritt. KI-generert kode trenger den samme grundige testingen som kode skrevet av mennesker. Automatiserte E2E-tester fanget opp problemer som ville vært lette å overse manuelt.
- Mennesket må fortsatt være med i prosessen. Hver arkitekturbeslutning, hver sikkerhetsmessige avveining og hver produktgrense ligger fortsatt hos meg. KI gjør implementeringen raskere, men erstatter ikke skjønn.
- Fart gir rom for kvalitet. Fordi funksjoner lanseres på timer i stedet for dager, blir det mer tid til iterasjoner, finpuss og feilretting. Raskt betyr ikke automatisk bra.
Veien videre
Baby Monitor Timmy fortsetter å utvikle seg. iOS-utgivelsen er nær; deretter kommer flere sensorfunksjoner og kontinuerlig sikkerhetsforbedring. Arbeidsflyten forblir lik: Jeg setter retning og grenser, og Copilot hjelper til med rask implementering og kontroll.
De sikkerhetsrelevante byggesteinene ligger nå innenfor tydelige grenser i det offentlige baby-monitor-timmy-core-repositoriet. Der er også arkitekturbeslutningene rundt sammenkobling, signalering og backend-grensesnitt dokumentert.