Как у нас в проекте на самом деле пишется код
В прошлой статье речь шла в основном про транспортный уровень - uTLS, decoy-трафик, pacing и всё, что связано с прохождением DPI. Это удобно рассматривать как отдельную техническую задачу, но внутри проекта это только один слой.На моей части лежат клиенты под пять операционных систем: Windows, macOS, Linux, Android и iOS. Даже когда собственно транспортная логика у них общая, вокруг неё неизбежно появляется платформенный код. У каждой системы свои сетевые API, свои ограничения на фоновую работу, свои модели пермишенов и свой способ интегрировать всё это с остальной системой.Кроме клиентов есть сетевая инфраструктура: control- и exit-узлы, арбитр, подписанный манифест узлов и обвязка вокруг этого хозяйства. Есть метрики, алертинг, ротация ключей и конфигов. Есть анализаторы трафика. Всё это не существует независимо друг от друга: изменение протокола довольно быстро превращается в изменения на нескольких платформах, серверных компонентах и в тестах.И это только то, чем занимаюсь непосредственно я.Рядом существуют партнёрские приложения, использующие наш SDK, сайт, документация и экосистема вокруг клиента. Ими занимаются другие люди, но с точки зрения общего объёма разработки они никуда не исчезают.Команда при этом небольшая. Поэтому довольно быстро возникает банальная арифметическая проблема: задач больше, чем люди способны последовательно написать руками за разумное время. Именно здесь у нас появились LLM - в основном Claude, иногда модели OpenAI.Не как ещё один архитектор и не как человек, которому можно сказать «сделай мне анти-DPI систему», а как инструмент для довольно определённого класса инженерной работы. Читать далее