Babyphone Timmy begann mit einer einfachen Idee: ein Babyphone, das die Privatsphäre zu Hause respektiert. Keine Cloud-Aufnahmen, keine unnötigen Datenwege aus dem Kinderzimmer. Was viele nicht sehen: Ich entwickle Timmy als Solo-Projekt in Zürich, und GitHub Copilot ist dabei mein ziemlich schneller Pair-Programmer.
Mein Mensch-KI-Workflow
Die Aufgabenteilung ist klar: Ich definiere Features, setze Prioritäten und treffe die Architekturentscheidungen. Copilot hilft bei der Umsetzung: Code schreiben, Tests ergänzen, Fehler eingrenzen und Release-Schritte vorbereiten.
Ein typischer Sprint sieht bei mir ungefähr so aus:
- Feature-Beschreibung: Ich beschreibe, was das Feature tun soll, inklusive Grenzfälle und Einschränkungen.
- Implementierung: Copilot schlägt Code vor und orientiert sich an den bestehenden Konventionen.
- Testen: Automatisierte End-to-End-Tests laufen auf zwei Emulatoren und prüfen die echte Baby-/Eltern-Verbindung.
- Verteilung: Wenn die Tests passen, werden Android- und iOS-Builds für die passenden Store- und Test-Tracks vorbereitet.
Dieser Zyklus wiederholt sich für Features und Bugfixes. Ich schreibe nicht jede Zeile selbst, aber ich entscheide, was gebaut wird, warum es gebaut wird und ob der Vorschlag in Timmy passt.
Vom Konzept zu WebRTC
Die zentrale technische Aufgabe war von Anfang an klar: Echtzeit-Audio und -Video zwischen zwei Handys. WebRTC war die naheliegende Wahl, aber die Flutter-Integration ist nicht trivial: ICE-Kandidaten, SDP-Verhandlung, TURN-Fallback und DataChannels müssen in der richtigen Reihenfolge zusammenspielen.
Copilot half mir, diese Teile Schritt für Schritt sauber zu ziehen: Peer-Verbindung aufbauen, die kritische Reihenfolge einhalten (DataChannel vor Offer, onTrack vor setRemoteDescription) und die Signalisierung auf Firebase Firestore setzen. Jedes Teilstück musste auf zwei Emulatoren laufen, bevor ich weitergemacht habe.
Sichere Kopplung mit ECDH
Eines der kritischsten Features war das sichere Kopplungssystem mit ECDH. Zwei Geräte müssen Vertrauen aufbauen, ohne dass ein zentraler Server zum Geheimnisträger wird. Die Lösung: ein ECDH-P-256-Schlüsselaustausch über Firebase, kombiniert mit einer visuellen Verifikationszahl (SAS), die Man-in-the-Middle-Angriffe erkennt.
Copilot half bei der Implementierung der kryptografischen Kette: Schlüsselgenerierung, Public-Key-Austausch, Ableitung des gemeinsamen Geheimnisses, SAS-Berechnung und AES-256-GCM-Verschlüsselung für alle nachfolgenden Signalisierungsdaten. Den Pairing-Key sende ich nicht ans Backend; nur sein SHA-256-Hash dient als Firestore-Dokumentkennung.
Sicherheitsaudit: Schwachstellen finden und beheben
KI-gestützte Entwicklung heißt für mich nicht nur schneller tippen. Sie hilft auch beim systematischen Suchen nach Fehlern. In einem gezielten Sicherheitsaudit-Sprint analysierte Copilot die Codebasis und fand sechs Probleme, die ich beheben musste:
- Fehlende Eingabevalidierung bei Signalisierungsdaten
- Potenzielle Race Conditions bei der ICE-Kandidaten-Verarbeitung
- Veraltete Sitzungsdaten, die nicht korrekt bereinigt wurden
- Firestore-Sicherheitsregeln, die zu großzügig waren
- Fehlende Überlegungen zum Certificate Pinning
- Unzureichende Fehlerbehandlung im TURN-Credential-Flow
Alle sechs wurden im selben Sprint behoben. Genau bei so einer systematischen Review-Arbeit ist Copilot stark: viele Dateien lesen, Muster vergleichen und Stellen markieren, die ich mir genauer ansehen muss.
Iterative Sprints: Wie die App entstand
Timmy entwickelte sich in schnellen, aber klar begrenzten Sprints. Einige Stationen:
- v1.8: Komplettes Pairing-Redesign — 4-Zeichen-Code + ECDH P-256 über Firebase ersetzte den alten Direktschlüssel-Ansatz.
- v1.10: Security-Hardening-Sprint — der Sechser-Schwachstellen-Audit- und Behebungszyklus.
- v1.11: Dark Mode auf allen Bildschirmen, plus die Homepage und der Blog, den du gerade liest.
- v1.12: Großer Umbau des Eltern-Bildschirms, Nachtsichtmodus und Bewegungserkennung über Kamera-Frame-Analyse.
Jeder Sprint folgt demselben Grundmuster: Ziel beschreiben, Vorschläge prüfen, automatisiert testen und erst dann an Tester ausliefern.
E2E-Tests über mehrere Geräte
Ein Babyphone testet man nicht sinnvoll mit einem einzigen Gerät. Ich brauche ein Baby-Gerät und ein Eltern-Gerät. Das Projekt startete mit zwei gleichzeitig laufenden Android-Emulatoren und ergänzt diese Schleife inzwischen durch lokale iOS-Simulator- und echte Geräteprüfungen. Das automatisierte Android-Testskript:
- Die App auf beiden Emulatoren installiert
- Die Kopplung auf beiden Geräten durchführt
- Überprüft, dass Audio- und Videoverbindungen hergestellt werden
- Push-to-Talk, Kamerasteuerung und weitere Features testet
Da beide Emulatoren dieselbe IP-Adresse teilen (10.0.2.15), ist eine direkte Peer-to-Peer-Verbindung über STUN nicht möglich. Jeder Testlauf muss deshalb über das Cloudflare-TURN-Relay. Das ist mühsam, aber nützlich: Der komplizierteste Verbindungspfad wird dadurch jedes Mal mitgetestet.
Was ich gelernt habe
Eine komplette App mit einem KI-Pair-Programmer zu bauen hat mir einiges gezeigt:
- Architektur ist wichtiger denn je. Klare Konventionen und eine gut dokumentierte Codebasis helfen der KI, konsistenten Code vorzuschlagen. Mehrdeutigkeit wird sonst schnell teuer.
- Testen ist Pflicht. KI-generierter Code braucht die gleichen rigorosen Tests wie manuell geschriebener Code. Automatisierte E2E-Tests fingen Probleme ab, die ich manuell leicht übersehen hätte.
- Der Mensch bleibt im Loop. Architekturentscheidungen, Sicherheits-Kompromisse und Produktgrenzen entscheide ich. Die KI beschleunigt die Umsetzung, ersetzt aber nicht mein Urteil.
- Geschwindigkeit kann Qualität ermöglichen. Wenn Features schneller testbar sind, bleiben mehr Iterationen für Feinschliff und Fehlerbehebung. Schnell heißt nicht automatisch gut.
Ausblick
Babyphone Timmy entwickelt sich weiter. Der iOS-Release steht kurz bevor; danach folgen zusätzliche Sensorfunktionen und kontinuierliches Security-Hardening. Der Workflow bleibt ähnlich: Ich gebe Richtung und Grenzen vor, Copilot hilft beim schnellen Umsetzen und Prüfen.
Die sicherheitsrelevanten Bausteine liegen jetzt im öffentlichen Repository baby-monitor-timmy-core. Dort sind auch die Architekturentscheidungen rund um Pairing, Signaling und Backend-Schnittstellen dokumentiert.