Как проба пера с ИИ превратилась в проект удалённого доступа

Это моя первая статья на Хабре, так что прошу не пинать ногами. Чукча не писатель. Хочу рассказать, как эксперимент из серии «интересно, а что будет, если…» затянулся на несколько месяцев и превратился в серьёзный проект.

Всё началось с вопроса: где заканчиваются возможности ИИ в разработке? Может ли ИИ самостоятельно, по запросу, создать архитектурно сложный продукт с множеством слоев, взаимодействующих элементов, использующий множество разнородных технологий?

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

В старом кондовом пайплайне разработчика ПО это здорово экономило время. Но программиста такой процесс не заменял: контекст приходилось задавать вручную, а результат — внимательно проверять.

Потом появился Codex для Windows. С ним разработка с помощью ИИ перешла на совершенно другой уровень. Ни тебе плавающего контекста, ни кучи правок, после которых выяснялось, что то что он пишет, уже относится совсем к другому проекту, а не к тому, что у тебя фактически работает. ИИ‑агент мог сам пройтись по проекту, разобраться в существующем коде, оставаться в контексте разработки и спустя минуты отвечать на вопросы, для которых раньше пришлось бы потратить часы на задание контекста из исходников. А ещё — выполнять небольшие изменения полностью.

Тут я сильно переоценил его возможности.

Довольно быстро выяснилось, что он может программировать быстро, а качество написанного им кода не уступает качеству кода многих лучших программистов. Попросишь реализовать идею, и он реализует без лишних вопросов (и без не лишних тоже). Проблема в том, что всё, о чем ты ему не сказал, он тоже реализует. Реализует так, как посчитает нужным. Если я чего‑то не продумал, плохо объяснил или не заметил — он реализует так, как бы это сделал лепрекон из фильма «Трасса 60».

Часто это выглядело так: вместо поиска причины появлялись грабли и вилы на любой вкус и цвет, раскиданные вокруг, затем каждая из них обрастала своим сообществом вил и прочих садовых инструментов. Код рос, токены таяли, а проблема никуда не уходила.

С таким вот запасом наивного воодушевления я и принялся за реализацию.

Почему именно удалённый доступ

Задача была вполне приземленной. Я часто и надолго уезжаю, а доступ к компьютерам дома, на работе и у родителей нужен постоянно. Компьютеры начинают сбоить больше всего именно тогда, когда ты находишься далеко от них (отсылка к законам Мура).

Удалённая работа. Иллюстрация с сайта проекта.

Существующие решения меня не устроили по различным причинам. С AnyDesk у меня случались обрывы и проблемы с работой бесплатной версии (дай денег). RustDesk я так и не смог нормально подружить с домашним компьютером — картинка не шла, хотя на других ПК все было хорошо. TeamViewer даже не стал рассматривать из‑за условий использования. Бесплатный RuDesktop в моём опыте работал слишком медленно во всех возможных сценариях — возможно его замедляют специально для некоммерческого использования.

Я подумал, что если ИИ теперь способен работать с целым проектом, может, получится относительно быстро сделать собственное решение для себя? Заодно появился бы серьёзный проект для портфолио и реальный опыт разработки с ИИ — тема, которая становится всё актуальнее при поиске работы.

Начал я примерно в начале лета. Для чистоты эксперимента задачу полностью доверил ИИ. Ставишь задачу, просишь предложить варианты, а потом на все киваешь и со всем соглашаешься. Доверил ИИ почти всё: написание кода, архитектуру, выбор технологий. Хотелось посмотреть, куда он меня заведёт.

А привел он меня практически в родной дом — в долину боли и отчаяния.

Первая версия приложения вытянула из меня немало нервов, но так и не заработала. Больше всего запомнились заботливо разложенные по проекту «грабли». На первый взгляд всё выглядело разумно. Через некоторое время очередное решение неожиданно стреляло как ружье на стене — и приходилось выяснять, как проблема вообще возникла.

Тогда же я понял, что впечатление от модели на тестовых задачах мало говорит о том, как она будет работать над реальными проектами.

Я очень ждал GPT-5.6 Sol. Когда она появилась и сразу начала решать проблемы, над которыми я бился уже неделю, я расслабился. После GPT-5.5 она производила впечатление опытного разработчика, пришедшего на помощь новичку.

А потом мы начали ходить кругами. И так, круге на пятом, тебя охватывает отчаяние и ты понимаешь, что лезть по старинке в код бессмысленно. Что тебе понадобится несколько месяцев, только чтобы понять о чем там речь. А к тому моменту в проекте было уже более 120 000 строк кода.

Исправляя один косяк, модель могла попутно разбросать несколько новых. Через некоторое время следы приводили в ранее вылеченную часть проекта, и я снова разбирал последствия предыдущих правок. В какой‑то момент я вернулся на GPT-5.5: она казалась менее эффектной, зато с ней у меня лучше получалось двигаться вперёд. Она делала именно то, о чем ее просишь и не делала того, чего ты ее не просил.

Так закончилась часть эксперимента «пусть ИИ сам спроектирует и напишет». И началась гораздо более интересная часть: попытка понять, как с ним работать, чтобы проект всё‑таки состоялся.

Второй заход: сначала понять, кто с кем разговаривает

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

Основные требования к новому решению: сервис должен обходиться недорого, мало нагружать серверы и при этом сохранять соединение в самых разных сетевых условиях. Мне не хотелось строить систему, в которой каждый кадр экрана проходит через центральный сервер. При таком подходе дешевый сервер не вывезет и 20–30 клиентов онлайн.

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

На словах схема выглядела логично. В реальности архитектура менялась много раз. Иногда очередная проблема обнаруживала ошибку в реализации, а иногда показывала, что сама прежняя схема была придумана слишком оптимистично. Анализ текущей архитектуры на нагрузки и стрессоустойчивость не раз выявлял узкие места и приводил к полному рефакторингу.

В работе с ИИ обнаружилось неожиданное преимущество. Кардинально переделать архитектуру стало проще: значительную часть механической работы по изменению кода можно было поручить ему. Это не избавляло меня от необходимости анализировать последствия решения — после первого захода я уже достаточно на это насмотрелся. Но цена эксперимента стала ниже по времени.

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

Сеть: место, где красивые схемы встречаются с реальностью

Много времени я потратил на протокол передачи данных. Это оказалась самая трудозатратная часть всей системы. На него ушла, наверное, половина всего времени разработки. Сначала казалось, что WebSocket — отличный кандидат: соединение надёжное, с передачей данных удобно работать. Но между двумя домашними компьютерами, у которых нет выделенных публичных адресов, установить такое соединение напрямую обычно сложно. Для передачи данных сеанса лучше подходил UDP: с ним больше возможностей пробиться через привычные сетевые препятствия.

Устойчивое соединение. Иллюстрация с сайта проекта.

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

Больше всего времени при отладке протокола заняло управление скоростью передачи. Сначала, в домашней сети, я даже не сталкивался с этой проблемой — там сложно забить трафик. Но при проверке удаленных подключений, особенно международных, выяснилось, что между двумя компьютерами есть ещё несколько устройств и каналов, и один из них обязательно окажется самым узким. Если закидывать в него пакеты без ограничений, так быстро, как они у тебя появляются, они начнут копиться в буферах и даже могут повесить или перезагрузить роутер или другую сетевую инфраструктуру между конечными точками по пути следования пакета. Это не тот способ удалённого управления оборудованием, который я планировал реализовать:‑)

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

Компьютеры помогают компьютерам

В результате роли распределились так. Клиент поддерживает сигнальное соединение с серверной инфраструктурой. По нему сервер понимает, кто в сети, помогает подготовить сеанс и выбрать маршрут. Сам экран через это соединение не передаётся.

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

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

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

География тоже участвует в отладке

Ещё одной неожиданной частью сетевой разработки стала география. Изначально сигнальный сервер находился в московском ЦОД. Подключения внутри страны работали хорошо, а при работе из‑за границы начали появляться проблемы.

На поиск причины ушло немало времени. По моим наблюдениям, определённые направления UDP‑трафика проходили нестабильно; насколько именно здесь сказались сетевые ограничения, со стороны приложения установить было трудно. В итоге я перенёс основную серверную инфраструктуру в ОАЭ, и проблемы, с которыми я тогда столкнулся, исчезли.

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

А можно ли доверять реле на промежуточном ПК?

Когда данные сеанса проходят через другие клиентские устройства или серверы в разных странах, вопрос безопасности возникает сам собой. Честно говоря, отправка своего рабочего стола через ПК других клиентов звучит как плохая идея.

Защищённый сеанс. Иллюстрация с сайта проекта.

Поэтому содержимое сеанса шифруется на устройстве отправителя и расшифровывается только на устройстве получателя. Реле пересылает зашифрованные пакеты, но не получает ключи для их чтения. Сигнальное соединение с сервером тоже защищено, а при подключении с паролем устройства подтверждают знание общего секрета с помощью J‑PAKE. Сам пароль серверу для этого передавать не нужно.

Отдельно пришлось продумывать сохранённые разрешения. Мне не хотелось сценария, при котором злоумышленник копирует файлы клиента на другой компьютер и получает доступ к устройству, где это подключение уже было одобрено. Сохранённая авторизация опирается на защищённые секреты участников, а не только на запись вида «этот ID когда‑то разрешили».

Конечно, шифрование не делает устройство неуязвимым. Если один из компьютеров заражён или пользователь сам дал доступ не тому человеку, протокол этого не исправит. Но хотя бы промежуточные узлы не должны становиться местом, где можно прочитать содержимое сеанса.

Неожиданный поворот: ИИ по ту сторону соединения

Уже позже я встроил в клиент локальный MCP‑шлюз. Он позволяет дать ИИ инструменты для работы с удалённым компьютером через обычный сеанс приложения. Для этого нужны разрешения: сам по себе шлюз не должен превращаться в обход аутентификации.

ИИ и удалённое подключение. Иллюстрация с сайта проекта.

После добавления этой функции я решил воспользоваться ею сам и неслабо «охренел» от результата. Компьютер на работе начал зависать. Я запустил ИИ локально, дал ему доступ через MCP и попросил разобраться в возможных причинах.

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

Получилась довольно забавная петля. Я начинал проект, чтобы проверить, способен ли ИИ помочь создать сложное приложение. А потом попросил ИИ через это приложение помочь разобраться с неисправным компьютером.

Что в итоге

Эксперимент затянулся сильнее, чем я ожидал. Зато теперь у меня есть инструмент удалённого доступа, которым я сам пользуюсь и который закрывает мои повседневные задачи: от подключения к рабочему столу до передачи файлов и удалённой диагностики.

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

Последний вывод, к которому я пришёл за время этой разработки, касается уже не удалённого доступа.

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

Зато гораздо ценнее становится архитектурное мышление: понять, какие требования противоречат друг другу, где пройдёт граница ответственности компонентов, что случится при сбое и какую цену придётся заплатить за то или иное решение. Именно здесь ИИ в моём проекте чаще всего ошибался. Он мог быстро построить почти что угодно, в том числе ерунду.

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

Если захотите посмотреть, что получилось, вот сайт проекта: SaccadiaRemote.com.

По моим текущим расчётам, серверная инфраструктура рассчитана примерно на 2500–3000 одновременно подключённых клиентов. Так что если вдруг случится хабраэффект, я могу не успеть вовремя добавить мощности. Для проекта, который начинался как «давай посмотрим, что сможет ИИ», это будет «неожиданная» проблема.