Это не история про «ИИ помог написать команду».
Это исследование момента, когда ИИ сам выполняет работу в инфраструктуре, меняя контексты исполнения.

Введение

Сейчас под «автономным ИИ» чаще всего понимают чат-бота, который:

  • подсказал команду

  • сгенерировал Terraform

  • помог найти флаг в документации

Это нулевой или первый уровень автономности.

Меня интересовал другой вопрос:

Может ли ИИ не советовать, а действовать — как инженер?

Не в симуляции.
А в реальном облаке, с реальными ВМ, SSH и последствиями.

Что я называю вторым уровнем автономности

Для себя я формализовал уровни так:

Уровень 0 — советчик

ИИ отвечает текстом.

Уровень 1 — оператор под контрлем человека

ИИ пишет команды, и выполняет их в реальной среде черз MCP или Tools

🔥 Уровень 2 — автономный исполнитель

ИИ:

  • сам выполняет команды

  • сам подключается по SSH

  • сам работает внутри второго уровня вложенности

  • человек остаётся в контуре контроля, но не исполняет руками

Именно этот уровень я и исследовал.

Условия эксперимента

ИИ был запущен не локально, а работал через SSH-плагин.

У него был доступ:

  • к машине с установленным yc (Yandex Cloud CLI)

  • к SSH

  • к целевым ВМ, которые он сам создавал

Задача формулировалась обычным человеческим языком:

Создай ВМ и Managed PostgreSQL в Yandex Cloud.
Затем подключись по SSH к ВМ, подними Docker Compose с Nginx и WordPress
и подключи WordPress к созданной базе данных.

Без Terraform.
Без Ansible.
Без заранее заготовленных скриптов.

Ключевая сложность: не одна среда, а цепочка контекстов

Главная трудность эксперимента была не в WordPress
и не в Docker.

Сложность была в том, что ИИ пришлось работать в нескольких средах исполнения подряд.

Фактическая цепочка выглядела так:

SSH-плагин (агент)
   ↓
Машина с yc CLI
   ↓
Yandex Cloud API
   ↓
SSH в созданную ВМ
   ↓
Docker Engine
   ↓
WordPress контейнер
   ↓
Managed PostgreSQL (вне ВМ)

⚠️ Важно:
у ИИ не было «локальной машины».
Он всегда работал удалённо, через SSH.

Почему это принципиально важно

ИИ должен был понимать:

  • где он сейчас исполняется

  • какие команды доступны в этом контексте

  • где заканчивается облако и начинается ОС

  • где он управляет инфраструктурой, а где — сервисами

Для человека это очевидно.
Для ИИ — это отдельная когнитивная нагрузка. Головы внимания МЫ не контролируем.

Шаг 1. Управление облаком через yc

В первом контексте ИИ работал на машине с yc CLI и:

  • проверил текущий cloud / folder

  • нашёл доступную зону

  • создал ВМ с минимальными ресурсами

  • создал Managed PostgreSQL (самый дешёвый пресет)

  • извлёк:

    • публичный IP ВМ

    • hostname базы

    • креды

Делает ошибки YC он знает плохо. Цель а как будет если он не занет CLI
Делает ошибки YC он знает плохо. Цель а как будет если он не занет CLI

И естественно не знает типа и инстансов. Не AWS все-таки

Шаг 2. Переход в другой контекст — SSH в ВМ

Дальше происходит критический переход:

ИИ сам выполнил:

К моменту публикации все удалено. Так что публику пароли без изменений
К моменту публикации все удалено. Так что публику пароли без изменений

И с этого момента он больше не работал с облаком,
а оказался внутри конкретной ВМ.

Контекст полностью сменился:

  • Ubuntu

  • apt

  • systemd

  • файловая система сервера

    И справился сильно не сразу


Лог SSH-подключения ИИ к ВМ

Шаг 3. Администрирование ВМ и Docker

Уже внутри ВМ ИИ последовательно:

  1. Установил Docker и docker-compose plugin

  2. Подготовил рабочий каталог

  3. Сгенерировал:

    • docker-compose.yml

    • конфиг Nginx

    • .env с параметрами БД

  4. Запустил контейнеры

📸 Скрин 4:
docker compose ps — контейнеры запущены

И тут к стати ошибка WP не поднялся
И тут к стати ошибка WP не поднялся

Шаг 4. WordPress + PostgreSQL (не MySQL)

WordPress не поддерживает PostgreSQL из коробки.
Это классическая ловушка.

ИИ:

  • знал об этом

  • скачал драйвер PG4WP

  • установил db.php в wp-content

  • включил sslmode=require для Managed PostgreSQL
    Но не сразу)

Это уже не шаблонная задача, а инженерная.

Ошибки были — и это нормально

Были реальные проблемы:

  • bash -u и неэкранированные переменные

  • heredoc + environment variables

  • повторные перезапуски контейнеров

    Исправил: в контейнер WordPress скопирована директория wp-content/pg4wp (раньше был только db.php, из‑за этого и было “PG4WP file directory not found”). Контейнеры перезапущены.

    Сейчас сайт отдаёт редирект на установку WP:

ИИ не завис и не «сдался». Хотя и приходилось подталкивать

Он:

  • ловил ошибку

  • менял стратегию

  • повторял шаг

  • доводил задачу до результата

Почему это всё ещё не «полностью автономный ИИ»

Важно быть честным.

❌ ИИ не понимает бизнес
❌ ИИ не несёт ответственность
❌ ИИ может снести прод без ограничений

Но:

✅ он уже умеет работать в инфраструктуре напрямую
✅ он умеет менять контексты исполнения
✅ он может быть вторыми руками инженера

Главный вывод исследования

Второй уровень автономности реален уже сейчас.

ИИ уже способен:

  • управлять облаком

  • заходить по SSH

  • администрировать ВМ

  • поднимать сервисы

  • работать с managed-ресурсами

Но человек обязан оставаться в контуре управления.

Это не «ИИ вместо DevOps».
Это DevOps с экзокортексом.

Что дальше

Следующий шаг — уровень 3:

  • ИИ сам обнаруживает проблему

  • сам предлагает план

  • сам выполняет

  • человек только подтверждает

Я двигаюсь именно туда.

Если тема зайдёт — продолжу публиковать результаты.

Или более сложная задача.

К стати Gpt-4o и Claud 3.7 c подобными задачи не справлялись