Как ИИ помог спроектировать хэндшейк между клиентом и лиц-сервером

В QoLab (форк PoeRedux на .NET 10 WPF) я добрался до того, что откладывают до последнего, — активации лицензий. В клиенте стояла заглушка: LicenseService.Activate выдавал Pro на 30 дней локально на любой введённый ключ. В продакшене так жить нельзя. Нужен был настоящий обмен: клиент отправляет ключ, лиц-сервер на VPS проверяет его и возвращает подписанный ответ. Хэндшейк двух сторон.

Загвоздка в том, что стороны собирались параллельно и на разных стеках. Клиент — мой .NET-репозиторий (кодовое имя Qolab Prism). Сервер — Hono + SQLite на отдельной VPS. Их писали независимо, и встретиться они должны были ровно один раз, когда обе половины готовы. Разъедется контракт хоть на байт — и стыковка превращается в неделю переписки и отладки вслепую.

Почему хэндшейк тяжело проектировать в одиночку

Протокол обмена — место, где ошибка стоит дорого и прячется до последнего. Клиент ждёт одно поле, сервер шлёт другое. Порядок байтов при проверке подписи не совпал. Формат даты разошёлся. Любая такая мелочь всплывает только на живой стыковке, когда обе стороны уже написаны и менять их больно.

Обычно тут держишь в голове сразу две картины мира, клиентскую и серверную, и постоянно сверяешь их между собой. Вот на этом я и решил опереться на ИИ.

Где ИИ реально помог

Я дал модели два документа: дизайн лиц-сервера и отдельный документ хэндшейка, который фиксировал контракт байт-в-байт. Дальше польза распалась на три части.

Роль общего контекста. ИИ держал обе стороны одновременно и ловил расхождения раньше меня. Опишу серверный ответ — модель тут же спрашивает, как его разберёт .NET-клиент. Это и есть та сверка двух картин мира, которую тяжело вести руками.

Криптографические решения. Для подписи ответов выбрали Ed25519. Приватный ключ остаётся только на VPS и никуда не уезжает. Публичный ключ кладётся в git, чтобы клиент мог проверять подпись. ИИ помог проговорить эту схему до конца: где генерится пара, что именно подписывается, как клиент валидирует. Разложить угрозы и договориться о границах доверия — тут помощник экономит уйму времени.

Разделение ответственности. Документ хэндшейка прямо расписывает, кто что делает: агент на стороне VPS строит сервер по дизайну и подтверждает URL и формат; клиентская сторона реализует свою половину под тот же контракт. Синхронизация идёт через git — документ фиксирует контракт так, чтобы обе стороны состыковались без личной переписки.

Как выглядел сам процесс

Писать код я не бросился. Сначала мы с моделью довели до готовности два документа и согласовали их с владельцем продукта. Дизайн лиц-сервера и хэндшейк дополняют друг друга: первый описывает сервер, второй — контракт стыковки.

Дальше по моему рабочему порядку: сначала детальный план через навык writing-plans, потом реализация через TDD. Тесты пишутся первыми, и они же становятся живой проверкой контракта. Разберёт клиент серверный ответ не так, как договорились, — тест упадёт первым. Пользователь до сломанной активации даже не доберётся.

Что я вынес из этого кейса

Главная ценность ИИ здесь — удержание контекста. Один человек, прыгая между клиентом и сервером, неизбежно теряет часть деталей на стыке. Модель держала обе стороны рядом и о них напоминала.

Второе — ИИ заставляет проговорить неявное. Формат полей. Порядок байтов при проверке подписи. Кто владеет приватным ключом. Всё это легко оставить на потом и получить сюрприз на стыковке. Диалог с моделью вытащил такие вопросы на поверхность заранее.

Экспертом по криптографии и сетевым протоколам я себя не считаю — технологии меняются быстрее, чем успеваешь им стать. Но именно поэтому связка «человек держит цель, ИИ держит детали контракта» и сработала. Я решал, каким должен быть продукт, а помощник следил, чтобы две независимо написанные половины сошлись байт-в-байт.

Проектируете интеграцию двух систем — попробуйте тот же ход: сначала документ-контракт, потом код. И пусть ИИ будет тем, кто держит обе стороны в голове, пока вы держите в голове смысл.