1. Hook
Vibe coding снизил порог входа в программирование… но качество результата — лотерея. Агентная инженерия превращает эту лотерею в конвейер.
2. Контекст
В феврале я впервые столкнулся с ИИ-агентами и попробовал что-то навайбкодить. Поначалу просто закидывал промпт в агента и ждал результат. Каждый чат — непредсказуемый результат: то работает, то хрень, которую и не починишь, и не поддержишь. Когда новые правки ломали уже работавший функционал — стало понятно, что так нельзя.
Андрей Карпаты ввёл термин vibe coding — «сижу и вайбую, пусть агент сам пишет» — и показал, что это снижает порог входа, но не даёт контроля над результатом. Он же ввёл термин «агентная инженерия»: дисциплина, где навыки фиксируются как skills и формируются пайплайны для работы агентов.
Почему сломалось: нет структуры — нет воспроизводимости — нет поддержки. От хаотичных запросов к формализованному пайплайну — это и есть агентная инженерия. И у меня есть конкретный пайплайн, который работает каждый день.
3. Главная мысль
Пайплайн — это не про «лучший промпт», а про 8 фаз, где каждая делает ровно одно дело.
Фаза 1 — Parse: GitNexus строит граф связей проекта. Агент получает карту — вот эта функция вызывается из этих мест, а этот класс наследуется там. Без карты агент работает вслепую, просто grep по именам файлов. Конкретно: при рефакторинге метода оплаты в интернет-магазине агент видит все 12 мест, где этот метод вызывается, и не пропускает ни одного. Parse даёт контекст, без которого рефакторинг превращается в русскую рулетку.
Фаза 2 — Plan: отдельный профиль ares-planner на DeepSeek V4 Pro пишет план-контракт в файл. Не промпт в чате, а файл — единый источник истины для всех фаз. При передаче контекста через tmux-сессии inline-промпт обрезается и теряет данные, а файл — надёжен. План-контракт выглядит как чёткий список задач: «замени вызов API оплаты, добавь обработку ошибок для таймаута, не трогай корзину».
Фаза 3 — Premortem (премортем — мысленный эксперимент «представим, что проект провалился, и перечислим почему»): представляем провал и перечисляем риски до кода. Оркестратор читает план и систематически перечисляет: «а если API изменит формат ответа?», «а если эта таблица в БД растёт?» Исправить план на бумаге в сто раз дешевле, чем код в продакшене.
Фаза 4 — Code: здесь начинается интересное. Зачем вообще разные модели? Фронтенд, бэкенд и кроссмодульные задачи требуют разного. Kimi K2.7 натренирована на React и фронтендных задачах — понимает JSX, CSS-модули и адаптивную вёрстку из коробки. GLM 5.1 — аккуратная, дешёвая модель для серверной логики, API и конфигов, где не нужна Vision за три цены. GLM 5.2 — для сложных задач, где затронуты и фронт, и бэк, и архитектурные решения: больше контекста, глубже рассуждения. Не мода, а оптимизация — каждый делает то, в чём силён. Профили запускаются в отдельных tmux-сессиях, как отдельные терминалы с отдельными сотрудниками, а контекст передаётся через файл плана.
Фаза 5 — Impact: GitNexus запускается повторно. Новая функция добавила импорт, который тянет зависимость. Переименованный метод сломал вызов в другом файле, который агент не открывал. Рентген после операции — убедиться, что всё на месте, прежде чем зашивать. Без этой фазы рефакторинг одной функции незаметно ломает три другие, и баг всплывает только в продакшене.
Фаза 6 — Tests: бэкенд и рефакторинг — TDD (test-driven development, разработка через тестирование: сначала пишем тест, потом код, который этот тест проходит). Фронтенд и SEO — пост-тесты: сначала верстаем, потом проверяем через Lighthouse и валидаторы. Отдельная фаза для тестов появилась из практики — без неё агент пропускал проверки, и баги ехали в прод.
Фаза 7 — Review: быстрая вычитка. Нет ли console.log и var_dump от отладки? Нет ли импортов несуществующих модулей — галлюцинаций модели? Не забыты ли TODO из плана? Review не меняет содержания, но ловит мелочи, которые портят впечатление: отладочный вывод в проде выглядит непрофессионально, а несуществующий импорт ломает сборку.
Фаза 8 — Ship: feature-ветка, коммит с понятным сообщением, push, pull request (PR — запрос на слияние кода, чтобы другие могли проверить изменения перед попаданием в основную ветку) через gh CLI. Никаких прямых push в main — только через CI (continuous integration — автоматическая проверка каждого изменения: тесты, линтеры, сборка). PR — не формальность, а точка контроля: тесты, линтеры, и только после зелёного статуса код попадает в основную ветку.
4. Почему это важно
Файл плана — контракт между фазами, а не уточнения в чате. Чат обрезает контекст, файл — источник истины.
Разные модели для разных задач — не переплата за лишние возможности. Kimi для фронта, GLM для бэка — каждый делает то, в чём силён.
Премортем стоит добавить в любой процесс, где цена ошибки высока: это полчаса на обсуждение, которые экономят недели отладки. Parse без Impact — как операция без послеоперационного контроля: кажется, всё хорошо, а швы расходятся.
5. Что это значит для читателя
Пайплайн — это не теория, а рабочий инструмент. Каждый этап можно внедрить постепенно: начать с Parse + Plan, добавить Premortem, затем маршрутизацию моделей. Необязательно внедрять все 8 фаз сразу — даже Parse + Plan уже превращают хаос в осознанный процесс. Результат — предсказуемое качество кода, которое можно воспроизвести и поддерживать. Не магия, а дисциплина: вместе они превращают хаос vibe-кодинга в воспроизводимый процесс.
6. Что дальше
Агентные пайплайны быстро развиваются: появляются открытые фреймворки для оркестрации, форматы навыков (skills) стандартизируются, а вопрос воспроизводимости остаётся открытым — кто гарантирует, что агент отработает одинаково через месяц?
#айишка #подумалось
