Android-разработчик с десятилетним стажем опубликовал на Хабре честный технический дневник: попросил LLM-агента сыграть роль сисадмина и настроить мониторинг для трёх VPN-сетей на разных технологиях. Не нанял специалиста, не стал изучать тему два года — взял агента. Сервис поднялся. После пяти нетривиальных поломок — тоже. Сейчас как будто работает. Но автор признаётся: он боится на него дышать.
Контекст
Автор — не новичок в разработке и не наивный энтузиаст AI. Android-стаж 10+ лет, опыт вайбкодинга в мобильной разработке, понимание базовых сетевых концепций. Но сетевое администрирование — не его область. Задача звучала разумно: единая точка входа с демоном мониторинга, который стучится в три VPN-сети и собирает статус сервисов. Технически нетривиально, нанимать сисадмина не хотелось.
Вайбкодинг (vibe coding) — подход, при котором пользователь описывает задачу на естественном языке, LLM генерирует решение, пользователь применяет, не погружаясь в детали. В мобильной разработке автор делал это успешно: если сломается — понятно где, понятно почему, починишь сам. Сетевая инфраструктура — другой класс задачи: ошибки там скрытые, накапливаются, и починить их без экспертизы нельзя.
Автор прямо предупреждал себя: «может получиться дыра в безопасности, портал призыва демонов или сервер с круглосуточным рикроллом» — и держал наготове «ведро со святой водой». Это важная деталь: он не был наивен. Он недооценил специфику именно этого класса рисков — не взрыв, а тихое гниение.
Аналитика
Статья фиксирует три паттерна, важных для любого, кто думает делегировать LLM-агенту инфраструктурные задачи. Первый: агент объясняет с одинаковой уверенностью — правильно и неправильно. Автор читал объяснение про «петлю пакетов» и признаётся: логично звучит, но верно ли понял — не знает. Это не баг модели. Это структурная ловушка: без экспертизы вы не можете верифицировать вывод. Агент повесил скрипт восстановления не на то событие — dnsmasq начал перезагружать правила почти постоянно и периодически падал. Обнаружилось через несколько дней: трафик вроде есть, но ресурс грузится 30 секунд вместо одной.
Второй: каждая итерация «почини» добавляет непрозрачный слой. «Бэкап Шрёдингера» — sh-скрипт, который выглядел как восстановление, но при запуске, вероятнее всего, сломал бы сеть: имена сетевых интерфейсов на новой машине были другими, версии зависимостей не те. Агент при переносе внёс десятки правок, о которых пользователь не думал. Итог — непрозрачная система, где каждый слой фиксов зависит от предыдущего, и никто не держит полной картины.
Третий — центральный инсайт статьи. Автор сравнивает опыт с Ruby on Rails в режиме «convention over configuration»: работать с LLM-генерированным кодом в незнакомой области — всё равно что пользоваться фреймворком без документации, с неявными соглашениями, которые ты не знаешь. Работает — но почему? Почему этот класс, а не тот файл разметки? Когда сломается — непонятно. Как чинить — непонятно.
«Да, такой скрипт и правда был, но я ошибся и не учел, что его нужно зарегистрировать на триггер переподключения соединения» — агент отвечает с леденящим душу спокойствием.
Кейсы применения в бизнесе
B2B-SaaS стартап (3–7 человек). Соблазн поднять dev-окружение или настроить CI/CD через агента без DevOps в штате — реальный. Работает, если есть хотя бы один человек, способный прочитать результат. Опасно там, где агент настраивает сетевые правила или права доступа в production без ревью. Правило простое: AI-генерированная конфигурация инфраструктуры требует того же ревью, что и код — иначе через три недели получите скрытый cron, который каждую минуту переприменяет правила iptables.
Корпорация с legacy-инфраструктурой. Агент видит текущее состояние, но не историю решений — почему именно так настроено. Намеренный костыль под конкретный edge case выглядит как баг. «Почини» сломает то, что казалось сломанным, но было необходимым. Особенно критично при миграции: агент не знает, что вон та странная настройка держит работу конкретного клиента на legacy-оборудовании.
SMB и локальный бизнес в КР/СНГ. Небольшая компания хочет VPN для удалённых сотрудников без сисадмина. Для простых сценариев — работает. Но нужен человек, который умеет читать логи и отличает «сервис недоступен» от «дашборд врёт». Иначе сервис-зомби: выглядит живым, реальный статус неизвестен, а трафик может идти не туда.
Кейсы в личной жизни
Разработчик вне своего стека. Используй агентов в своей зоне экспертизы — там ты можешь верифицировать результат. Вне зоны — добавляй слой ревью: читай, что агент сделал, даже если не понимаешь зачем каждая строка. Хотя бы убедись, что понимаешь структуру изменений.
DevOps/сисадмин. Парадокс: человек с экспертизой получит от LLM-агентов максимум именно потому, что может верифицировать вывод. Автор попал в ловушку из-за отсутствия экспертизы, а не из-за плохого агента. Агент — ускоритель для тех, кто знает, куда ускоряться.
Фрилансер / контент-мейкер. Вайбкодинг безопасен там, где цена ошибки низкая и ошибка видима: автоматизация файлов, скрипты обработки данных, простые интеграции. Там, где ошибка скрытая и накапливается — сеть, безопасность, платёжные системы — цена может оказаться неожиданной.
Как применить сегодня
- Перед запуском агента на инфраструктурную задачу задай себе один вопрос: смогу ли я прочитать результат и понять, что именно сделано?
- Добавляй в prompt требование вести аудит-лог: какие файлы изменены, какие команды выполнены, почему — не для агента, а для себя.
- Тестируй failure scenarios, а не только happy path: перезагрузка, потеря соединения, недоступность зависимости. Именно там прячутся экзотические баги.
- Для критической инфраструктуры — human-in-the-loop: агент предлагает, человек с экспертизой одобряет перед применением. Это управление рисками, не недоверие к AI.
- Если не можешь верифицировать — не применяй в production. Это не ограничение технологии, это вопрос ответственности за результат.