В комментариях к предыдущей статье о транспортном уровне (uTLS, decoy-трафик, обход DPI) автору задали вопрос: кто на самом деле пишет код и какую роль играют нейросети. Ответ оказался неожиданно конкретным: LLM встроены в рабочий процесс, но не как архитекторы, а как инструмент для механической работы.
Объём разработки в проекте значителен. На одном человеке лежат клиенты под пять операционных систем: Windows, macOS, Linux, Android и iOS. Даже при общей транспортной логике каждая платформа требует своего кода: сетевые API, ограничения фоновой работы, модели пермишенов. Плюс сетевая инфраструктура: control- и exit-узлы, арбитр, подписанный манифест узлов, метрики, алертинг, ротация ключей. Изменение протокола затрагивает сразу несколько платформ и серверных компонентов. Рядом — партнёрские приложения на SDK, сайт и документация, но это уже зона ответственности других людей.
Команда небольшая, поэтому задач больше, чем можно написать руками за разумное время. Именно здесь появились LLM — в основном Claude, иногда модели OpenAI. Автор подчёркивает: модель не получает задачу «сделай анти-DPI систему», она работает с уже определёнными принципами.
Что реально делегируется? Первый класс задач — кросс-платформенные порты. Когда транспорт на Go работает, интерфейсы понятны, эквивалентную логику нужно перенести на Swift или Kotlin. Здесь меньше инженерной неопределённости, но много механической работы: другие типы, библиотеки, обработка ошибок. LLM делает первый проход быстрее человека, но код всё равно читают, собирают и проверяют. Для небольшой команды это существенная экономия, особенно когда одно изменение нужно протащить через несколько платформ.
Второй класс — протокольная рутина. Например, ротация ClientHello-фингерпринтов под разные браузеры: нужно воспроизводить наборы TLS-расширений для Chrome, Firefox, Edge и Safari. Содержательную часть — что и зачем воспроизводить — определяет человек, а реализация «сделай то же самое для Firefox 141» отлично подходит модели. Человеку такая работа быстро надоедает, а скука в протокольном коде ведёт к ошибкам вроде переставленного расширения. LLM не скучает.
Третий класс — тесты и фикстуры. Систематически добивать кривые входные данные, варианты ошибок парсинга, пограничные случаи — формализуемая работа. Если дать модели интерфейс, описать ожидаемое поведение и показать существующие тесты, она генерирует следующий слой покрытия. Ловушка в том, что тест модели может проверять не то, что нужно, поэтому он тоже требует ревью. Но писать однотипные фикстуры руками — бессмысленно.
Четвёртый класс — рефакторинг. Когда меняется интерфейс, его использование в других местах проекта можно поручить LLM. Это похоже на портирование: механическая работа по адаптации вызовов.
Автор отмечает, что LLM не заменяют инженера, а снимают рутину, позволяя сосредоточиться на содержательной части. Код от модели всегда проходит ревью, и это критично. Опыт проекта показывает: для небольших команд LLM становятся инструментом, который расширяет пропускную способность, но не отменяет ответственности человека за архитектуру и качество.
