Зачем Fly.io это вообще нужно

Сейчас все пользуют VSCode, и особенно — его форки, которые генерируют код с помощью LLM. Интеграция машин Fly.io в этот процесс удалённого редактирования по SSH выглядит логичным шагом.

Когда LLM генерирует неправильный код, это называют "галлюцинацией". Когда так же поступают люди — это называют "инженерией".

"hallucination" is what we call it when LLMs get code wrong; "engineering" is what we call it when people do.

LLM-генерированный код полезен, если знать, что с ним делать. Но становится особенно ценным, если замкнуть цикл между LLM и окружением выполнения (в "Agent" конфигурации). Суть: LLM генерирует код, агент запускает его, код выдаёт ошибки, агент передаёт их обратно LLM, цикл повторяется — это частичное противоядие от галлюцинаций.

Проблема в том, что такой итеративный процесс разработки не захочется запускать на собственном лэптопе. LLM имеет проблемы с границами контекста и с удовольствием будет менять конфигурацию системы так же охотно, как файлы в Git-проекте. Хотелось бы запустить такой цикл на чистой Linux-машине, которая поднимается мгновенно и не может ничего сломать. Вот к чему мы идём.

Как это реализовано

Emacs хранит духовного предшественника систем удалённого редактирования — куском гиперполезного Elisp кода под названием Tramp. Подключи Tramp к любому интерактивному окружению — обычно SSH-сессии, где можно запускать команды shell — и Emacs расширит себя на то окружение.

VSCode имеет похожий функционал. Естественно предположить: взяли Tramp, упростили, заменили Elisp на TypeScript.

Но на самом деле всё совсем не так!

В отличие от Tramp, который живёт за счёт того, что есть на удалённом подключении, VSCode запускает полномасштабное вторжение: Bash-snippet-stager, который скачивает агент, включая полноценную бинарную сборку Node.

Вот, похоже, исходный код?

Агент работает через port-forwarded SSH и устанавливает WebSockets-соединение обратно к фронтенду VSCode. Этот протокол позволяет:

  • Ходить по файловой системе
  • Редактировать произвольные файлы
  • Запускать собственные shell PTY-процессы
  • Сохраняться в системе

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

Использовать VSCode для удалённого редактирования на dev-серверах вызывает нервозность, а на production во время инцидента — это вообще апоплексия.

Оказалось, что для собственного подключения машин Fly к VSCode всё это не критично, поэтому это не имеет значения в каком-то глубоком смысле. Но раз Fly решила вернуться к формату простого блога — пришлось это разбирать, и теперь это приходится разбирать и всем остальным.