В феврале я впервые столкнулся с ИИ-агентами и начал предпринимать первые попытки что-то навайбкодить. Поначалу я просто закидывал промпт в агента и ждал результат. Иногда результат был отличным, иногда — полный мусор. Каждый раз, когда я начинал чат с нейросетью, результат был непредсказуем — либо то, что надо, либо хрень, которая и не работает, и её потом нельзя поддерживать, или когда новые правки в старый код ломали уже работающий функционал. Как итог: непредсказуемое качество, которое невозможно ни воспроизвести, ни поддерживать.
В процессе работ я начал понимать, что нельзя написать один раз в чат «сделай хорошо» и чтобы агент всё сделал за тебя — ему нужны свои правила работы и чёткое описание их логики, которое фиксируется в так называемом пайплайне — pipeline.
Андрей Карпатый ввёл термин vibe coding — «сижу и вайбую, пусть агент сам пишет» — и показал, что это снижает порог входа, но не даёт контроля над результатом. Он же использует ещё один термин — агентная инженерия: дисциплина, где навыки фиксируются как skills и формируются определённые пайплайны для работы агентов. Но сейчас не об этом, кому нужно — можно погуглить эти термины.
Самое главное, чем хочу поделиться, — это мой текущий пайплайн работ по программированию, которым я пользуюсь каждый день и который улучшил итоговые результаты программирования.
Фаза 1 — Parse (разбор)
Прежде чем что-то делать с кодом, нужно понять, на что это повлияет. Агент по умолчанию каждый раз, когда начинает работать, ничего не помнит про проект.
GitNexus — это сервис, который сканирует репозиторий и строит граф связей между всеми файлами, функциями, классами и модулями проекта. Представьте карту города, где видно каждый дом и каждую дорогу к нему. Когда вы собираетесь перестроить перекрёсток, вы сразу видите, какие улицы пострадают. Без GitNexus агент работал бы вслепую — просто grep по именам файлов, который не покажет, что изменение одной функции сломает три модуля, которые на неё ссылаются. С GitNexus агент получает точную карту: вот эта функция вызывается из вот этих мест, а этот класс наследуется вот там. Это основа всего пайплайна — без понимания структуры проект перестраивать нельзя.
Фаза 2 — Plan (планирование)
План пишет не тот же агент, который будет кодить. За это отвечает отдельный профиль ares-planner, работающий на модели DeepSeek V4 Pro. Почему именно она? DeepSeek — серьёзная модель с этапом размышления (chain-of-thought): прежде чем выдать результат, она анализирует, что именно нужно, какие есть ограничения, и последовательно рассуждает о каждом шаге. Это не «напиши код сразу», а «подумай, потом напиши план». Результат сохраняется в файл .hermes/plans/<feature>.md — это единый контракт между всеми фазами. Ни один агент не получает промпт руками; все читают план из файла. Это критично: при передаче контекста через tmux-сессии inline-промпт обрезается и теряет данные, а файл — надёжный источник истины.
Фаза 3 — Premortem (премортем-анализ)
Премортем — это мысленный эксперимент: представьте, что проект уже провалился, и задайте себе вопрос — почему? Классический метод из управления проектами, который я адаптировал для работы с AI. Оркестратор читает план и систематически перечисляет риски: «а если API изменит формат ответа?», «а если эта таблица в БД растёт?» Каждый риск добавляется прямо в план с мерой противодействия. Это дешёвая страховка — исправить план на бумаге в сто раз дешевле, чем исправлять код в продакшене. Без премортема агент часто проскакивает мимо краевых случаев, потому что его не спросили о них явно.
Фаза 4 — Code (кодирование)
Здесь начинается самое интересное: разные типы работы получают разные модели. Не потому что это модно, а потому что каждая модель сильна в своём.
Kimi K2.7 Code — для фронтенда и вёрстки. Эта модель натренирована на React и фронтовых задачах; она понимает JSX, CSS-модули, адаптивную вёрстку и современные UI-паттерны из коробки. Когда нужно сверстать компонент или написать хук — Kimi делает это естественно, без долгих уговоров.
GLM-5.1 — для серверной логики, API, баз данных и SEO. Здесь не нужна Vision-модель, которая умеет «видеть» картинки и стоит в три раза дороже. Нужна аккуратная, дешёвая модель, которая точно работает с кодом, маршрутами и конфигами. GLM-5.1 — оптимальный баланс цены и качества для бэкенда.
GLM-5.2 — для сложных, кроссмодульных задач, где затронуты и фронт, и бэк, и архитектурные решения. Это более мощная модель с расширенным контекстом, которая умеет удерживать в голове больше связей и рассуждать о компромиссах.
Каждый профиль запускается в отдельной tmux-сессии — это как отдельный терминал с отдельным сотрудником. Профили не делят память между собой; весь контекст передаётся через файл плана.
Фаза 5 — Impact (оценка последствий)
После того как код написан, GitNexus запускается снова. Зачем? Потому что в процессе кодирования агент неизбежно касается больше символов, чем планировалось. Новая функция может добавить импорт, который тянет за собой зависимость. Переименованный метод может сломать вызов в другом файле, который агент не открывал. GitNexus проверяет каждый изменённый символ и показывает: вот эта функция теперь вызывается из трёх мест, а вы обновили только два. Это как рентген после операции — убедиться, что всё на месте, прежде чем зашивать.
Фаза 6 — Tests (тестирование)
Изначально в моём пайплайне фазы тестирования не было. Я считал, что если агент хороший, то и код будет хорошим. Но Hermes Agent сам предложил добавить её — и был прав. Стратегия зависит от типа работы:
- Бэкенд и рефакторинг — TDD (Test-Driven Development): сначала пишем тесты, которые описывают ожидаемое поведение, потом пишем код, который эти тесты проходит. Это не просто проверка, это способ специфицировать, что именно должен делать код, до того как он написан.
- Фронтенд и SEO — пост-тесты: сначала верстаем, потом проверяем результат визуально и через Lighthouse/валидаторы. Писать TDD для CSS-макетов бессмысленно, но прогнать валидатор разметки — обязательно.
Фаза 7 — Review (ревью)
Быстрая, но систематическая проверка: нет ли console.log и var_dump, оставленных для отладки? Нет ли импортов несуществующих модулей (галлюцинации модели)? Не нарушены ли конвенции проекта? Не забыты ли TODO из плана? Мелкие правки делаются на месте, крупные отправляются обратно в tmux-сессию кодера. Это как финальная вычитка перед публикацией — не меняет содержания, но ловит опечатки, которые портят впечатление.
Фаза 8 — Ship (доставка)
Последний шаг — оформить работу через Git. Создаётся feature-ветка, коммит с понятным сообщением, push, pull request через gh CLI. Никаких прямых push в main — только через CI. PR — это не формальность, а точка контроля: CI прогоняет тесты, линтеры, и только после зелёного статуса код попадает в основную ветку. Это гарантирует, что то, что работает на машине разработчика, работает и в продакшене.
Итог
Каждый этап делает ровно одно дело. GitNexus даёт знание структуры проекта, премортем страхует от глупых ошибок, а маршрутизация моделей не переплачивает за возможности, которые не нужны конкретному шагу. Каждая модель подбирается под задачу — не самая дорогая, а самая подходящая. Контракт между фазами — файл плана, а не куча уточнений в чате.
Vibe coding открыл дверь в программирование для всех, снизил порог входа — агентная инженерия делает так, чтобы за этой дверью был порядок, а не бардак.
