Technical Context
Я регулярно тестирую cloud coding-среды и веб-агентов (Jules, Codex/Claude Web, Cursor Web и похожие) на задачах, которые возникают в реальных проектах: установка зависимостей, обращение к внешним API, поднятие dev-сервисов, прогон миграций. И почти всегда упираюсь в одно и то же ограничение: контейнер исполнения не имеет нормального доступа в сеть или доступ жестко урезан.
По моим наблюдениям, это выглядит не как «временный баг», а как сознательная политика sandbox’а. Часто разрешены только строго контролируемые HTTPS-запросы на уровне платформы, без возможности свободно ходить наружу из контейнера, без проброса портов и без привычного набора сетевых инструментов, которые мы ожидаем в Linux-окружении.
Из-за этого симптомы путают с чем угодно: «DNS не резолвит», «connection refused», «pip/npm не качает», «git clone не работает», «SDK не может дернуть API». Для инженера это критично, потому что агент формально “пишет код”, но не может его собрать и проверить так, как это делается в CI.
На фоне этого GitHub Codespaces действительно выделяется как более полноценная среда: VS Code devcontainer, нормальные сетевые возможности, привычная работа с пакетными менеджерами и внешними сервисами. Но даже там я видел сценарии, когда сессия засыпает или рвётся подключение, и это нужно учитывать в архитектуре рабочего процесса.
Business & Automation Impact
Я смотрю на это не как на неудобство разработчика, а как на прямое ограничение для ИИ автоматизация в инженерных цепочках. Если агент не может установить зависимости и дернуть внешние системы, он превращается в «умный редактор», а не в автономного исполнителя задач.
Больше всех выигрывают команды, у которых сборка и тесты уже упакованы в предсказуемый пайплайн: lock-файлы, приватные зеркала пакетов, артефакты, кеши, инфраструктура как код. Проигрывают те, кто рассчитывает на “интернет как данность” и живую установку всего на лету.
В реальных внедрениях я закладываю это ограничение сразу. В проектах Nahornyi AI Lab мы часто разделяем контуры: веб-агент работает в «стерильной» среде для генерации изменений, а выполнение (сборка/тест/скан) уходит в контролируемый runner — Codespaces, self-hosted GitHub Actions, GitLab Runner или Kubernetes job, где сеть, секреты и политики доступа настроены явно.
Если бизнес хочет сделать ИИ автоматизацию “под ключ” — от тикета до pull request с зелёным CI — без архитектурных компромиссов не обойтись. Тут нужна архитектура ИИ-решений, которая учитывает безопасность, стоимость вычислений, лимиты платформы и требования комплаенса.
Strategic Vision & Deep Dive
Я ожидаю, что «без интернета в контейнере» станет стандартом для массовых AI IDE, а не временной фазой. Причина простая: как только вы даёте агенту свободный outbound, вы получаете новый класс рисков — от утечек ключей и SSRF до автоматизированного абьюза сторонних сервисов.
Поэтому я проектирую решения так, чтобы агенту не нужен был внешний интернет для большинства операций. Практический паттерн, который хорошо ложится в внедрение ИИ: предварительно собранные dev-образы с зависимостями, внутренние registries, прокси с allow-list доменов, а для интеграций — тонкие “integration gateways” с аудитом и rate limit.
Ещё один вывод из моих проектов: чем сильнее вы хотите автономность агента, тем больше вам нужен управляемый “execution plane”. Это может быть Codespaces для команд, которые уже в экосистеме GitHub, или отдельный изолированный кластер для компаний с повышенными требованиями. В обоих случаях я предпочитаю явную ИИ интеграция с CI/CD и секрет-хранилищами, а не попытку «додушить» веб-IDE до уровня продакшн-раннера.
Если вам кажется, что это усложнение, я предложу другой взгляд: вы просто переносите дисциплину production-инфраструктуры в контур разработки. И именно там сейчас и происходит борьба за скорость: не “кто лучше пишет код”, а “кто быстрее и безопаснее исполняет изменения”.
Что я рекомендую сделать прямо сейчас
- Разделить генерацию и выполнение: агент генерирует изменения, а сборка/тесты идут в доверенном раннере с контролируемой сетью.
- Убрать зависимость от публичного интернета: кеши, зеркала, dev-образы, артефакты, приватные registries.
- Формализовать сетевую политику: allow-list, прокси, аудит, минимальные права для токенов.
- Настроить “живучесть” окружений: чтобы сессии не умирали посреди длительных задач и не ломали поток работы.
Этот разбор подготовил Вадим Нагорный — ведущий практик Nahornyi AI Lab по внедрению ИИ и автоматизации инженерных процессов на базе AI-агентов. Я могу быстро оценить ваш текущий dev-процесс, предложить целевую AI-архитектуру и собрать рабочий контур: от безопасного execution plane до пайплайна “тикет → PR → CI → деплой”. Свяжитесь со мной, и мы разберём ваш кейс на конкретных ограничениях ваших инструментов и инфраструктуры.