Проєкт Baby Monitor Timmy почався з простої ідеї: радіоняня, що поважає приватність удома. Жодних записів у хмарі, жодних зайвих шляхів передавання даних за межі дитячої кімнати. Багато хто не знає, що я самостійно розробляю Timmy у Цюриху, а GitHub Copilot — мій дуже швидкий напарник із програмування.
Як працюють людина й ШІ
Розподіл ролей чіткий: я визначаю функції, розставляю пріоритети та ухвалюю архітектурні рішення. Copilot допомагає з реалізацією: писати код, додавати тести, локалізувати помилки та готувати реліз.
Приблизно так для мене виглядає типовий спринт:
- Опис функції: Я описую, що має робити функція, зокрема крайні випадки та обмеження.
- Реалізація: Copilot пропонує код і дотримується наявних у проєкті правил.
- Тестування: Автоматизовані наскрізні тести запускаються на двох емуляторах і перевіряють реальне з’єднання між пристроями дитини та батьків.
- Поширення: Коли тести проходять успішно, збірки Android та iOS готуються для відповідного магазину й каналів тестування.
Цей цикл повторюється для нових функцій і виправлень. Я не пишу кожен рядок сам, але вирішую, що будувати, чому це потрібно та чи підходить пропозиція для Timmy.
Від ідеї до WebRTC
Головне технічне завдання від початку було зрозумілим: передавання аудіо й відео в реальному часі між двома телефонами. WebRTC був очевидним вибором, але інтегрувати його з Flutter непросто: ICE-кандидати, узгодження SDP, резервне з’єднання через TURN і DataChannels мають працювати разом у правильному порядку.
Copilot допоміг мені крок за кроком зібрати ці частини: налаштувати однорангове з’єднання, дотриматися критично важливого порядку (DataChannel перед offer, onTrack перед setRemoteDescription) і реалізувати сигнальний обмін через Firebase Firestore. Кожна частина мала запрацювати на двох емуляторах, перш ніж я рухався далі.
Безпечне сполучення пристроїв за допомогою ECDH
Однією з найкритичніших функцій була система безпечного сполучення пристроїв. Два пристрої мають установити взаємну довіру, не покладаючись на центральний сервер, який підтверджує їхню особу. Рішення: обмін ключами ECDH P-256 через Firebase у поєднанні з візуальним номером перевірки (SAS), що виявляє атаки «людина посередині».
Copilot допоміг реалізувати криптографічний ланцюжок: генерацію ключів, обмін відкритими ключами, отримання спільного секрету, обчислення SAS та шифрування AES-256-GCM усіх подальших даних сигнального обміну. Я не надсилаю ключ сполучення на сервер; лише його хеш SHA-256 використовується як ідентифікатор документа Firestore.
Аудит безпеки: пошук і виправлення вразливостей
Розробка за допомогою ШІ для мене — це не лише швидше писати код. Вона також допомагає системно шукати помилки. Під час цільового спринту з аудиту безпеки Copilot проаналізував кодову базу й знайшов шість проблем які потрібно було виправити:
- Відсутня перевірка вхідних даних сигналізації
- Можливі стани гонки під час оброблення ICE-кандидатів
- Застарілі дані сеансу, які не очищалися належним чином
- Надто поблажливі правила безпеки Firestore
- Не враховано закріплення сертифікатів
- Недостатня обробка помилок у процесі отримання облікових даних TURN
Усі шість проблем виправлено в тому самому спринті. Саме тут Copilot сильний: читати багато файлів, порівнювати шаблони й позначати місця, які мені потрібно уважніше перевірити.
Ітеративні спринти: як розвивався застосунок
Timmy розвивався через швидкі, але чітко окреслені спринти. Деякі етапи:
- v1.8: Повне оновлення системи сполучення пристроїв — 4-символьний код і ECDH P-256 через Firebase замінили старий підхід із прямим ключем.
- v1.10: Спринт посилення безпеки — аудит шести вразливостей і цикл їх виправлення.
- v1.11: Темний режим на всіх екранах, а також головна сторінка й блог, який ви зараз читаєте.
- v1.12: Масштабне оновлення екрана для батьків, режим нічного бачення та виявлення руху за аналізом кадрів камери.
Кожен спринт має той самий базовий порядок: описати мету, переглянути пропозиції, автоматично протестувати, а потім передати тестувальникам.
Наскрізне тестування на різних пристроях
Неможливо як слід протестувати радіоняню на одному пристрої. Потрібен один пристрій для дитини й один — для батьків. Проєкт почався з двох Android-емуляторів, що працювали одночасно, а тепер цей цикл доповнено перевірками в локальному симуляторі iOS і на реальних пристроях. Автоматизований Android-скрипт досі:
- Установлює застосунок на обидва емулятори
- Виконує сполучення на обох пристроях
- Перевіряє, чи встановлено аудіо- та відеоз’єднання
- Тестує режим «натисни й говори», керування камерою та інші функції
Оскільки обидва емулятори мають одну IP-адресу (10.0.2.15), пряме однорангове з’єднання через STUN неможливе. Кожен запуск тестів має проходити через ретранслятор TURN від Cloudflare. Це незручно, але корисно: щоразу тестується найскладніший шлях установлення з’єднання.
Що я дізнався
Створення повноцінного застосунку з ШІ-напарником із програмування навчило мене кількох речей:
- Архітектура важливіша, ніж будь-коли. Чіткі правила й добре задокументована кодова база допомагають ШІ пропонувати узгоджений код. Неоднозначність швидко починає дорого обходитися.
- Тестування — обов’язкове. Код, згенерований ШІ, потребує такого самого ретельного тестування, як і код, написаний людиною. Автоматизовані наскрізні тести виявили проблеми, які легко пропустити під час ручної перевірки.
- Людина зберігає контроль. Кожне архітектурне рішення, кожен компроміс у сфері безпеки й кожне обмеження продукту залишаються за мною. ШІ пришвидшує реалізацію, але не замінює людського рішення.
- Швидкість дає змогу підвищувати якість. Оскільки функції виходять за години, а не за дні, залишається більше ітерацій для доопрацювання та виправлення помилок. Швидко — не завжди означає добре.
Що далі
Baby Monitor Timmy продовжує розвиватися. Реліз для iOS уже близько; після нього з’являться додаткові функції датчиків, а робота над посиленням безпеки триватиме. Робочий процес залишається схожим: я визначаю напрям і межі, а Copilot допомагає швидко реалізовувати та перевіряти.
Для важливих із погляду безпеки компонентів тепер установлено чіткі межі у публічному репозиторії baby-monitor-timmy-core. Там також задокументовано архітектурні рішення щодо сполучення пристроїв, сигнального обміну та інтерфейсів бекенду.