Сначала у меня был один большой промпт. Потом — агент, который проходил 16 этапов разработки. Потом — целая платформа с интерфейсом, несколькими сервисами и отдельным сервером.
Позже я отказался от собственной платформы для запуска агентов, сократил инструкции и убрал обязательный конвейер проверок. Общие инструменты и накопленный опыт получили развитие в Облепихе — среде, которую я сейчас использую для проектов нашей студии.
Почему большого промпта оказалось мало
Я долго не воспринимал ИИ для разработки всерьёз. Потом коллега уговорил меня попробовать DeepSeek: я дал ему примерно тысячу строк кода и попросил привести их в порядок, ничего не сломав.
Результат меня так впечатлил, что я стал постепенно поручать модели более сложные задачи.
Для экспериментов с ИИ-разработкой я придумал Telegram-бота с памятью и характером и назвал проект Nexus. Позже задумка выросла в игру с персонажами и свободными действиями. На Nexus я проверял, сколько разработки можно передать ИИ.
Главным инструментом был большой промпт. Агент ошибался — я добавлял условие. Забывал что-то проверить — появлялся новый пункт. Чем дальше, тем больше инструкция напоминала записку человеку, который уже успел затопить кухню: воду выключи, кран проверь, из квартиры не уходи, пока не убедишься, что пол сухой.
Постепенно я стал давать агенту больше самостоятельности и меньше смотреть в код. Он создавал модули, писал тесты, обновлял документацию и сообщал о завершённых задачах. У проекта появлялась всё более аккуратная структура.
Нормально работающий продукт из того эксперимента так и не получился. Но почему? Представь, тебе строят дом. Каждую неделю присылают новые чертежи, фотографии кирпичей и акты проверки кирпичей. Всё выглядит убедительно. Только в доме нет ни света, ни воды, а сам он, кажется, вот-вот развалится.
Как я построил целую платформу для одного агента
После экспериментов с Nexus я начал новый проект с рабочим названием my-agents, в котором разделил работу агента на отдельные этапы. Управление и результаты работы находились в терминале — окне командной строки, без отдельного сайта с кнопками.
Вместо одного промпта появился конвейер инструкций. Агент-разработчик проходил 16 этапов: готовил план, проверял его, писал код, запускал тесты, исправлял ошибки, проводил ревью и аудит, обновлял документацию и контекст.
У каждого этапа было объяснение. План нужен, чтобы понимать задачу. Проверка плана — чтобы не начать делать ерунду. Проверка кода — чтобы заметить ерунду, которую всё-таки начали делать.
Но этим конвейером тоже нужно было управлять. Где остановилась задача? Почему завис процесс? Как продолжить после ошибки? Что делать, если закончился лимит модели?
Терминальный прототип постепенно вырос в полноценный проект — my-core. У него появился веб-интерфейс, backend, база данных и несколько сервисов. Одни запускали задания, другие управляли серверами. Всё это размещалось на отдельном сервере. В интерфейсе можно было работать с проектами, задачами, агентскими ролями и сессиями.
К этому моменту я нагородил в my-core кучу функций, часть из которых даже мне не была нужна. А поддерживать и дорабатывать всё это всё равно приходилось: собственный интерфейс, сервисы, запуск агентов, управление сессиями.
Постепенно до меня дошло, что я сделал себе ещё один большой проект. Только теперь нужно было постоянно заниматься им, чтобы с его помощью заниматься остальными. А какой в этом смысл, если уже есть Codex и его приложение? Куда мне соревноваться с ними в разработке такой платформы?
Зачем я отказался от собственной платформы
В итоге я перешёл на Codex и перестал развивать собственную оболочку для повседневной работы с агентами. Сессии, общение с моделью и интерфейс разработки теперь были в готовом приложении, которое мне не нужно обслуживать самому.
Ушёл и обязательный маршрут через все этапы. Если тебе нужно поправить подпись на кнопке, проводить её через процедуру изменения платёжной системы довольно странно. Даже если каждый участник процедуры очень старается.
Но задачи, история ошибок и общие инструменты всё ещё были нужны. Из этой части опыта и выросла нынешняя Облепиха.
Я отвечаю за техническую часть в студии «Облепиха Лаб», и у нас несколько продуктов. Если в каждом заново устраивать запуск тестов, работу с ключами, поддержку и сбор технических данных, придётся поддерживать несколько похожих решений. Поэтому повторяющиеся вещи я выношу в общую среду.
My-core целиком туда не переезжал. Его собственный механизм запуска агентов перестал быть центром работы. А вот возможность продолжить задачу, разобраться в сбое и вызвать нужный инструмент осталась — уже рядом с Codex.
Что получилось в итоге: инструменты под рукой, инструкции по делу
В основе Облепихи — несколько понятных агенту документов. В AGENTS.md записаны основные правила работы: что можно менять, какие ограничения соблюдать и как проверять результат. В PROJECT.md — короткая карта проекта: где лежит код, за что отвечают его части и какими командами всё запускается.
Дальше идут skills — инструкции для конкретной работы. Как проверить интерфейс, выпустить изменение, подготовить отчёт или написать текст. Иногда к ним приложены примеры и готовые скрипты. Агент читает нужную инструкцию, когда доходит до такой задачи. Ему не нужно перед заменой лампочки изучать руководство к котельной.
Новый skill не означает нового агента: один исполнитель может пользоваться несколькими инструкциями. Но разложить большой промпт по файлам недостаточно. У меня набрался 101 skill; после удаления дублей и лишних требований осталось 56. Часть инструкций повторяла друг друга, часть заставляла выполнять действия, которые не помогали решить задачу.
Через наши MCP-серверы агент получает доступ к самим инструментам. MCP здесь — способ вызвать нужное действие прямо из чата: найти задачу, сохранить результат, посмотреть ошибку или обратиться к памяти. Инструкция объясняет, когда и зачем это делать, а инструмент выполняет действие.
Те же задачи, инциденты, журналы работы и отчёты я вижу в панели управления. Есть и общие серверные функции для продуктов: поддержка пользователей и сбор событий. За аналитику и работу с продуктовыми данными отвечает часть Облепихи, которую я называю Growth.
Отдельный менеджер управляет процессами на рабочем компьютере. Несколько чатов могут одновременно запускать тесты, сборки и локальные серверы. Менеджер учитывает ресурсы, ставит команды в очередь и знает, какой задаче принадлежит каждый процесс. Так можно найти и остановить сервер, который остался от вчерашней работы.
Всё это нужно установить и подготовить на компьютере заранее. Агент часто начинает работу так, будто привычные консольные инструменты уже есть в системе: чем-то можно быстро найти файл, поискать текст в исходниках, открыть браузер для проверки. Но если полезной программы нет, он вполне может обойтись без неё, а не заняться её установкой посреди задачи.
Поэтому я решил собирать рабочее окружение заранее. Например, установить быстрый поиск по файлам и тексту, GitHub CLI для работы с репозиториями и запросами на изменения, инструменты браузерной проверки. Вместе с ними агент получает наши команды, доступ к хранилищу секретов и место для временных файлов. В каждом новом проекте эту подготовку повторять уже не нужно.
Ответы инструментов я сразу сделал короткими: результат и предупреждения, без подробного отчёта о каждом успешном действии.
Если агент сталкивается со сбоем — например, команда не запускается или инструмент возвращает ошибку, — он создаёт запись об инциденте. В ней сохраняет, что пытался сделать, что пошло не так и при каких условиях. Так ошибка не остаётся только в переписке.
Дальше агент разбирается в причине и исправляет проблему. Когда проверка показывает, что всё работает, он закрывает инцидент и записывает, что помогло. Полезный вывод сохраняется в память: в следующей похожей задаче агент сможет найти решение, даже из другого чата.
В память попадает не весь журнал ошибок, а опыт, который пригодится ещё раз. Если проблему достаточно исправить один раз, новое правило для неё не нужно.
Трекер, в котором задачи меняет агент
Сначала я хотел использовать Яндекс Трекер. Но довольно быстро понял, что столько функций мне не нужно, а вот сам процесс работы хочется контролировать гораздо точнее. Поэтому в Облепихе появился свой трекер задач для агентов.
Забавная деталь: в его интерфейсе даже нет возможности вручную добавить или изменить задачу. Мне это просто не нужно. Я обсуждаю работу с агентом в чате, а он сам создаёт задачу, сохраняет договорённости и обновляет состояние. Панель нужна мне, чтобы посмотреть, что происходит.
В карточке есть исходная цель, результат и текущее состояние, критерии приёмки, следующий шаг и самопроверка. Если работа переезжает в новый чат, агент читает эту запись и продолжает с места остановки. Ему не нужно заново восстанавливать задачу по всей переписке.
Приёмка устроена как цикл. Сначала фиксируем, что должно получиться. Агент выполняет работу и проверяет результат по этим условиям. Если что-то не сходится, возвращается к исправлению, а затем повторяет нужные проверки. У каждого пункта приёмки должно появиться подтверждение; одного сообщения «всё готово» недостаточно.
Отдельная часть — adversarial review, или проверка с попыткой найти слабое место. Вместо того чтобы ещё раз убедиться, что всё хорошо, агент ищет, где решение сломается: какой сценарий забыли, что произойдёт при неверных данных, не потеряли ли часть исходного запроса. Найденная проблема снова отправляет задачу на доработку и проверку. Для этого не обязательно заводить ещё одного агента, но важно действительно попытаться опровергнуть собственный результат.
Так я могу контролировать условия, при которых работа считается законченной, а раздачу заданий, сохранение состояния и повторные проверки поручить агентам. Если что-то осталось нерешённым, это видно в задаче, и следующий запуск продолжит работу с конкретного шага.
А если всё-таки собрать кучу агентов?
Для обычной задачи мне чаще хватает одного агента. Но есть работа, где я регулярно подключаю управляющего и нескольких исполнителей. Этот процесс описан в skill agent-supervisor.
Я задаю цель и объясняю, какой результат хочу получить. Управляющий делит работу, выдаёт задания субагентам, проверяет то, что они сделали, и возвращает замечания. Когда одна часть готова, он передаёт следующую. Мне не приходится самому переносить результаты между чатами и повторять каждому исполнителю одни и те же указания.
Особенно хорошо это помогает с монотонной работой: написанием серии статей или повторяющимися циклами 3D-моделирования. Сделать вариант, проверить, поправить, перейти к следующему. Здесь управляющий отлично заменяет меня в роли человека, который постоянно раздаёт задания и следит, чтобы работа двигалась дальше.
Самая интересная часть начинается, когда проблема повторяется. Управляющий может разобраться, что не так с инструкцией, изменить её и поставить эксперимент: дать ту же обычную задачу свежим субагентам с новой версией skill. Они не видят предыдущую переписку, замечания и подсказки, поэтому проверяют саму инструкцию.
Результаты старой и новой версий сравниваются по одним критериям. Если новая инструкция помогает получить нужное качество или становится проще без потери результата, её сохраняем. Если нет — дорабатываем и проверяем снова. Получается что-то похожее на самообучение рабочего процесса: опыт меняет инструкции, с которыми выполняются следующие задачи.
При работе с текстами это особенно заметно. Можно долго объяснять одному агенту, какие фразы мне не нравятся, и добиться хорошей статьи. Но гораздо интереснее, сможет ли другой агент написать её по обновлённой инструкции без всей этой переписки. Именно такой результат и стоит сохранять в методе работы.
Какие инструменты я убрал и почему
Не всё, что я добавлял в Облепиху, оказалось полезным. Например, Graphify должен был помогать искать связи в исходниках. Но сразу после его вызова агент всё равно шёл искать файлы и текст обычными инструментами. Сам Graphify часто возвращал очень поверхностные и, по сути, ненужные результаты. Я так и не заметил пользы от этой дополнительной ступеньки и убрал интеграцию.
Structurizr я пробовал для описания архитектуры. Он требовал поддерживать отдельное описание и сервисы, хотя нужные схемы можно было хранить гораздо проще. От него тоже отказался.
Убрал и отдельный процесс управления аудитами в Growth — той части Облепихи, которая собирает продуктовые данные и помогает с аналитикой. Вместе с ним ушли обязательные реестры исследовательских материалов. Сами функции аналитики остались: лишним оказался процесс вокруг них.
С документацией получилось похоже. Подробный пересказ исходников быстро превращается во вторую версию программы — только на русском или английском. Код уже изменился, а текст ещё уверенно описывает вчерашнее устройство. Теперь для технического разбора сохраняется отчёт по конкретной версии проекта: схема, связи, файлы и их назначение. Его можно открыть позже и увидеть именно то состояние, которое обсуждалось.
Иногда для этого нужно написать новый инструмент. Иногда — поправить старый. А иногда открыть собственную инструкцию, вспомнить, как тщательно ты её составлял, и удалить половину.