A Baby Monitor Timmy egy egyszerű ötletből indult: egy bébiőr, amely tiszteletben tartja az otthoni magánszférát. Nincsenek felhőben tárolt felvételek, és nincs szükségtelen adatforgalom a gyerekszobából kifelé. Amit sokan nem látnak: Timmyt egyedül fejlesztem Zürichben, és GitHub Copilot a villámgyors programozópárom.
Az ember–MI munkafolyamat
A felosztás egyértelmű: én határozom meg a funkciókat, állítom fel a prioritásokat, és hozom meg az architekturális döntéseket. A Copilot a megvalósításban segít: kódot ír, teszteket készít, behatárolja a hibák okát, és előkészíti a kiadás lépéseit.
Nálam egy tipikus sprint nagyjából így néz ki:
- Funkcióleírás: Leírom, mit kell tudnia a funkciónak, beleértve a szélső eseteket és a korlátokat is.
- Megvalósítás: A Copilot kódot javasol, és követi a projektben már kialakult konvenciókat.
- Tesztelés: Automatizált végpontok közötti tesztek futnak két emulátoron, és ellenőrzik a babaoldali és a szülői eszköz közötti tényleges kapcsolatot.
- Terjesztés: Ha a tesztek sikeresek, elkészülnek az Android- és iOS-verziók a megfelelő alkalmazás-áruházi és tesztelési csatornákhoz.
Ez a ciklus ismétlődik a funkcióknál és hibajavításoknál. Nem én írok meg minden sort, de én döntöm el, mit építünk meg, miért építjük meg, és hogy egy javaslat illik-e Timmyhez.
A koncepciótól a WebRTC-ig
A központi technikai feladat kezdettől világos volt: valós idejű hang- és videókapcsolat két telefon között. A WebRTC kézenfekvő választás volt, de a Flutterrel való integrálása nem egyszerű: az ICE-jelölteknek, az SDP-egyeztetésnek, a tartalék TURN-kapcsolatnak és a DataChanneleknek a megfelelő sorrendben kell együttműködniük.
A Copilot lépésről lépésre segített összeállítani ezeket az elemeket: létrehozni a WebRTC-kapcsolatot, betartani a kritikus sorrendet (DataChannel az ajánlat előtt, onTrack a setRemoteDescription előtt), és a jelzéscserét a Firebase Firestore-ra építeni. Minden elemnek működnie kellett két emulátoron, mielőtt továbbléptem.
Biztonságos párosítás ECDH-val
Az egyik legkritikusabb funkció a biztonságos párosítási rendszer. A két eszköznek kölcsönös bizalmat kell kialakítania anélkül, hogy egy központi szerver igazolná a hitelességüket. A megoldás: ECDH P-256 kulcscsere Firebase-en keresztül, kiegészítve egy vizuális ellenőrző számmal (SAS), amely észleli a közbeékelődéses támadásokat.
A Copilot segített megvalósítani a kriptográfiai láncot: a kulcsgenerálást, a nyilvános kulcsok cseréjét, a közös titok származtatását, az SAS kiszámítását és az összes későbbi jelzéscsere-adat AES-256-GCM-titkosítását. A párosítási kulcsot nem küldöm el a háttérrendszernek; Firestore-dokumentumazonosítóként csak a kulcs SHA-256-kivonatát használom.
Biztonsági audit: sérülékenységek feltárása és javítása
Számomra az MI-vel támogatott fejlesztés nem csupán gyorsabb gépelést jelent. A módszeres hibakeresésben is segít. Egy célzott biztonsági audit során a Copilot elemezte a kódbázist, és hat problémát talált, amelyet javítanom kellett:
- Hiányzó bemeneti ellenőrzés a jelzésátviteli adatoknál
- Lehetséges versenyhelyzetek az ICE-jelöltek kezelésében
- Elavult munkamenetadatok, amelyeket nem törölt megfelelően a rendszer
- Túl megengedő Firestore-biztonsági szabályok
- A tanúsítványrögzítés figyelembevételének hiánya
- Elégtelen hibakezelés a TURN-hitelesítő adatok folyamatában
Mind a hatot ugyanabban a sprintben javítottam. Ebben erős a Copilot: sok fájl átolvasásában, minták összehasonlításában és azoknak a helyeknek a megjelölésében, amelyeket alaposabban meg kell néznem.
Iteratív sprintek: így fejlődött az alkalmazás
Timmy gyors, de jól körülhatárolt sprintekben fejlődött. Néhány mérföldkő:
- v1.8: Teljes párosítási áttervezés — a 4 karakteres kód + Firebase-en keresztüli ECDH P-256 felváltotta a régi, közvetlen kulcsos megközelítést.
- v1.10: Biztonsági megerősítő sprint — a hat sérülékenységet feltáró audit és az azt követő javítási ciklus.
- v1.11: Sötét mód minden képernyőn, valamint az éppen olvasott weboldal kezdőlapja és blogja.
- v1.12: A szülői képernyő jelentős átdolgozása, éjjellátó mód és mozgásérzékelés a kamera képkockáinak elemzésével.
Minden sprint ugyanazt az alapmintát követi: a cél leírása, a javaslatok átnézése, automatizált tesztelés, majd kiküldés a tesztelőknek.
E2E tesztelés több eszközön
Egy bébiőrt nem lehet megfelelően egyetlen eszközön tesztelni. Szükség van egy babaoldali és egy szülői eszközre. A projekt két, egyszerre futó Android-emulátorral indult; ezt a folyamatot ma helyi iOS-szimulátoron és valódi eszközökön végzett ellenőrzések egészítik ki. Az automatizált Android-tesztszkript továbbra is:
- Telepíti az alkalmazást mindkét emulátorra
- Végrehajtja a párosítás lépéseit mindkét eszközön
- Ellenőrzi, hogy létrejön-e a hang- és videókapcsolat
- Teszteli a gombnyomásos beszédfunkciót, a kameravezérlést és más funkciókat
Mivel mindkét emulátor ugyanazt az IP-címet használja (10.0.2.15), a STUN-on keresztüli közvetlen peer-to-peer kapcsolat lehetetlen. Minden tesztfutásnak a Cloudflare TURN-relén keresztül kell mennie. Ez bosszantó, de hasznos: így minden alkalommal a legbonyolultabb kapcsolati útvonalat teszteljük.
Amit megtanultam
Egy teljes alkalmazás MI-alapú programozópárral való fejlesztése néhány dologra megtanított:
- Az architektúra fontosabb, mint valaha. Az egyértelmű konvenciók és a jól dokumentált kódbázis segítenek az MI-nek következetes kódot javasolni. A bizonytalanság hamar sok többletmunkába kerül.
- A tesztelés nem alku tárgya. Az MI által generált kód ugyanolyan alapos tesztelést igényel, mint az ember által írt kód. Az automatizált E2E tesztek olyan problémákat is észleltek, amelyeket kézi teszteléssel könnyű lett volna figyelmen kívül hagyni.
- Az ember továbbra is része a folyamatnak. Minden architekturális döntés, minden biztonsági kompromisszum és a termékkel kapcsolatos minden keret az én felelősségem marad. Az MI felgyorsítja a megvalósítást, de nem helyettesíti az ítélőképességet.
- A gyorsaság lehetővé teszi a minőséget. Mivel a funkciók napok helyett órák alatt készülnek el, több iteráció marad a finomításra és a hibajavításra. A gyorsaság önmagában nem jelent minőséget.
Előretekintés
A Baby Monitor Timmy tovább fejlődik. Az iOS-kiadás közel van; utána további szenzorfunkciók és folyamatos biztonsági megerősítés következik. A munkafolyamat hasonló marad: én szabom meg az irányt és a kereteket, a Copilot pedig segít gyorsan megvalósítani és ellenőrizni.
A biztonság szempontjából lényeges építőelemek ma már világosan elkülönítve találhatók meg a nyilvános baby-monitor-timmy-core kódtárban. Itt található a párosításra, a jelzéscserére és a háttérrendszer interfészeire vonatkozó architekturális döntések dokumentációja is.