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 → деплой”. Зв'яжіться зі мною, і ми розберемо ваш кейс на конкретних обмеженнях ваших інструментів та інфраструктури.