14 агентов, три языковые модели, десяток Python‑скриптов и целое множество промптов всех сортов и расцветок, а также Claude Sonnet, DeepSeek Pro и Gemini на подхвате. Не то чтобы это было необходимо для разработки IT‑систем, но если начал собирать ИИ‑конвейер, то остановиться трудно. Единственное, что у меня вызывало опасение, — это синхронизация контекста между репозиториями. Нет ничего более беспомощного, безответственного и испорченного, чем агент, потерявшийся между бэкендом и фронтендом. Я знал, что рано или поздно мы дойдём и до этой дряни.

Если в вашей команде людей меньше, чем пальцев на руке у неопытного фрезеровщика, то вы знаете это чувство: список задач растёт быстрее, чем вы успеваете закрывать предыдущие. Вы работаете по вечерам, откладываете рефакторинг, потому что «некогда».

Я проработал в одной компании шесть лет, четыре из них — в разработке на Python. Последние три года я единственный разработчик в своей команде. Почему так вышло? «Исторически так сложилось». Задач по разработке меньше не становилось, и с этим надо было что‑то делать.

Статья является пересказом личного опыта по внедрению ИИ‑пайплайна в команду из одного человека, в хронологическом порядке. Постарался передать основные выводы каждого из этапов внедрения, и если вы только начинаете подобное у себя — надеюсь мои выводы помогут вам пройти пусть быстрее и эффективней.

Декабрь: чат‑боты не тянут

До декабря я работал с нейросетями как и многие: открывал чат, писал запрос, получал ответ (код или что‑то ещё), копировал в редактор. Для мелких задач — вопрос на пять строк, генерация функции — это работало нормально. Но как только задача вырастала до «добавить фичу с новым эндпоинтом и фильтром на фронтенде», всё ломалось. Чат не справлялся с контекстом — каждое новое сообщение требовало пересказывать архитектуру проекта заново. К четвёртому‑пятому запросу модель забывала, что мы вообще делаем.

Урок декабря: чат‑интерфейс — тупик для системной разработки. Нужен инструмент, который видит проект, держит контекст и работает не с одним промптом, а с задачей целиком.

Я начал изучать материалы Anthropic и OpenAI по агентной разработке. Если вы только погружаетесь в эту тему, рекомендую начать с этого: 

• Building effective agents

• Effective harnesses for long‑running agents

• Effective context engineering for AI agents

Январь: первый запуск и первая иллюзия

Январь стал пробой пера. OpenCode CLI в проекте, стандартный агент, который шёл в комплекте с OpenCode. Простейшая цепочка: «получи задачу → сгенерируй код → положи в файл». Никакой оркестрации, синхронизации и разделения ролей. 

На одном репозитории это работало: маленькие задачи вроде «поправить тест», «добавить поле в модель» или «обновить зависимости» закрывались за минуты. Появилось ощущение эйфории: «Ого, оно летает! Ещё пара месяцев — и я всё автоматизирую, заживём!».

Урок января: на одном репозитории и простых задачах, агенты выглядит как магия. Не обольщайтесь — это иллюзия, которая очень быстро разобьётся. Но она даёт энергию двигаться дальше.

Февраль: два агента, один Claude — и первое «вау»

К февралю я получил первый прототип. Два агента: бэкендер и тестировщик. Всё ещё никакой сложной архитектуры и оркестратора. Кодер получает задачу и пишет код, тестировщик покрывает тестами, а запросы отправлялись каждому агенту вручную в формате «сделай такую задачу», переключение на тестировщика с запросом «напиши тесты по задаче».

Процесс работы оставался ручным: я заводил задачу в Jira, описывал её, оценивал сроки и сложность, а затем вручную переносил описание как запрос для агента. Никакой автоматической декомпозиции и маршрутизации между агентами — просто прямое указание: «вот задача — напиши код». Простенько и со вкусом, но мне этого хватало: задачи были небольшими, а работа над фичей целиком ещё не требовалась.

Один репозиторий, два агента — всё быстро и даже как будто работает. Результат впечатлял: средняя фича закрывалась за два‑три часа вместо пары недель. Иксы покруче, чем в казино, не правда ли?

У вас может возникнуть вопрос — почему две недели на фичу? Ответ — потому что разработка это не основной фокус деятельности — у меня есть много операционных задач которые отнимают бОльшую часть рабочего времени, поэтому задачи кодинга часто делаются по остаточному принципу.

Под капотом — все тот же OpenCode CLI и Claude через Perplexity. Почему Claude? Два момента — теорию брал у Anthropic и подумал что логично взять и их решение, а второе — нарастающий хайп вокруг моделей семейства Claude.

Урок февраля: чтобы получить ускорение, не нужна сложная архитектура. Двух агентов и одной модели достаточно, пока задачи небольшие, а проект умещается в одной голове.

Март: нейронки не должны синхронизировать

Сложность задач, которые я делегировал агентам, росла, постановка становилась всё более комплексной. Версия конвейера на двух агентах была полностью завязана на нейросеть: проверка контрактов, синхронизация типов между бэкендом и фронтендом, отслеживание состояния между агентами.

На коротких задачах это работало, на средних и длинных — разваливалось. Примерно к четвёртому‑пятому вызову агент терял контекст: забывал, какой контракт актуален, какие файлы уже изменены, кто из агентов что сделал, и теперь локальный чат уже напоминал ту же ситуацию что была в январе.

Несмотря на это, я решил доверить нейронкам ещё один класс задач — проверку уязвимостей. Инструкция была простой: «проверь, что все зависимости не имеют критичных и высоких уязвимостей», ваншот в новой сессии без перегруженного контекста. Модель честно пишет: «всё зелёное, версии актуальны, проблем нет». Но в CI сборка падала: внутренний CodeScoring находил то, что модель «не заметила». Оказалось, что нейронка не сканирует зависимости, а в большинстве случаев генерирует правдоподобный ответ на основе своих «знаний» на момент обучения. Если в контексте нет данных, то она не придумает уязвимость, а придумает, что всё хорошо.

Но если в CI/CD уже есть инструмент для сканирования зависимостей проекта, то почему бы сразу его не использовать? Например, передать артефакты в CodeScoring, получить JSON и скормить его агентам. В этом случае агент не проверяет уязвимости, а анализирует готовый отчёт и предлагает исправления. Детерминированный инструмент сканирует, а нейронка анализирует и генерирует.

Тогда же я добавил синхронизацию между проектами в виде двух профильных агента: синхронизатор контрактов (читает OpenAPI‑контракты как обычный текст, а не как промпт) и координатор состояния (пишет в workflow_state.md построчно, а не держит состояние реализации в памяти).

К концу марта к кодеру и тестировщику добавились продакт‑менеджер, архитектор и оркестратор. Система перестала быть «двумя агентами с промптами» и начала походить на конвейер. Всё ещё на одном Claude, уже ~$150 в месяц, но счёт становился все больше.

Урок марта: нейронки хороши для генерации и анализа, детерминированный код — для синхронизации, проверок и состояния. Казалось бы, очевидно. Но когда ты внутри хайпа, очевидное видно не сразу.

Апрель: системные промпты на тысячу строк и осознание «задачи целиком»

К апрелю системные промпты каждого агента раздулись примерно до тысячи строк: инструкции, правила, граничные случаи — всё в одном файле. Выглядело логично: агенту нужен полный контекст — мы его даём. Однако на практике агент «забывал» инструкции довольно быстро. Не все, но критическую мелочь с какой‑нибудь 700-й строки он пропускал. Ты видишь ошибку, идёшь в промпт — правило есть, но агент его не учитывает.

Решение — навыки: модульные инструкции, которые агент загружает, только когда они нужны. Вместо монолита на 1 тыс. строк — набор из пяти‑восьми навыков по 50–150 строк. spec-driven-development загружается при проектировании, code-review-and-quality — перед проверкой, commit-convention — перед коммитом.

Справедливости ради, целиком проблему это всё же не решило. Да, агент стал гораздо реже что‑то забывать, но если сессия становится слишком длинной, то склероз напоминает о себе.

Навыки можно шарить между агентами. Правила пулл‑реквестов, формат коммитов, стандарты проверки кода живут в одном месте и подгружаются всем агентам‑разработчикам. Если изменился стандарт, то меняешь один навык, и его подхватывают все.

Примерно в это же время я окончательно обленился решил поменять формат работы с агентами. Раньше я использовал агентов в основном для кодогенерации: «напиши функцию», «поправь валидацию», «добавь поле в модель». Но сам процесс оставался ручным: подумать над тем как пользователь будет взаимодействовать с системой, завести задачу в Jira, расписать, скопировать. В апреле я понял, что хочу делегировать агенту задачу целиком: от бизнес‑требования до пулл‑реквеста. Не «напиши код», а «вот фича, разберись и сделай».

Урок апреля: монолитный промпт — это «спагетти‑код» для агентов. Модульные навыки — это библиотеки. А главное, кодогенерация и решение задачи целиком — два разных класса задач. Второй требует архитектуры.

Май: пять репозиториев, много денег и DeepSeek

К маю агенты взялись за самый крупный продукт, состоящий из пяти репозиториев: бэкенд, фронтенд, админка и несколько вспомогательных сервисов (консьюмеры и воркеры). Если на одном репозитории конвейер работал сносно, то на пяти начался ад. Python‑кодер меняет контракт в бэкенде, а React‑разработчик продолжает использовать старые типы. Синхронизатор контрактов должен был всё разрулить, но контракт поменялся неочевидным образом, и агент этого не заметил. Синхронизатор зависимостей пробегает по репозиториям и обновляет импорты, но один пропускает. Координатор состояния ведёт учёт, но агенты одновременно трогают пересекающиеся зоны, и workflow_state.md превращается в кашу с кучей конфликтов.

Пример: Python‑кодер изменил обязательное поле service.owner на опциональное. Синхронизатор контрактов честно обновил типы на фронтенде: owner: string → owner?: string, но не проверил, что в 14 компонентах поле используется без Null‑check. React‑разработчик не перечитывал контракт — синхронизатор же всё обновил. Сборка упала.

На отладку синхронизации я потратил больше времени, чем на всё вместе взятое. На этом этапе решение синхронизации через агентов показало свою несостоятельность и нужно было придумывать что‑то новое.

Спойлер — пока что оно продолжает жить в таком же виде, и дальше Orval не ушло

Здесь же случился финансовый триггер: счёт за Claude перевалил за $300 в месяц. Конвейер разросся, агентов стало больше. Каждая задача гоняла токены, и стоимость росла быстрее, чем я успевал получать зарплату. Стало очевидно: либо настраивать конвейер так, чтобы он потреблял меньше токенов, либо менять провайдеров.

К началу мая в конвейере появился DeepSeek V4 Pro. Claude остался для сложных задач (легаси, нетривиальная архитектура, проверка кода критичных доработок), а DeepSeek взял на себя основную массу задач (генерация кода, спецификации, оркестрация). Плюс Gemini Flash на подхвате для быстрых операций вроде написания текстов и документации по проекту. Началась оптимизация запросов, чтобы снизить итоговый чек в месяц.

Урок мая: скорость разработки упирается не в генерацию кода, а в синхронизацию между объектами управления. Стоимость подписок растёт пропорционально амбициям, и без модельного зоопарка и оптимизации бюджет улетает в космос.

Июнь: заплатки и тюнинг

К июню конвейер работал на полную мощность и поддерживал несколько боевых систем. Появилась связка с задачами Jira: задача создаётся, агенты подхватывают, результат уходит в пулл‑реквест. Ручной копипаст ушёл в прошлое — интеграция с Sentry позволила в моменте получать сообщения об ошибках и готовить фиксы, синхронизация между репозиториями частично переехала в задачи Jira, частично в задачи внутри отдельных репозиториев.

Весь месяц ушёл на мелкие правки: подкрутить промпт, обновить навыки, поправить логику оркестратора. Работа скучная, но именно она превратила прототип в инструмент, на который можно положиться.

Урок июня: когда конвейер начинает работать, наступает этап самой нудной работы — доводки. К этому нужно быть готовым.

Июль: ИИ — умножитель, а не волшебная палочка

Июль стал месяцем, когда я осознал главный парадокс: когнитивная нагрузка не снизилась, а выросла.

Раньше большую часть времени работы над проектом я тратил на написание кода, теперь — на проектирование пользовательских путей, продумывание граничных случаев и перепроверку того, что сгенерировали агенты.

Нет, не подумайте — без агентов этап проектирования тоже был, но если над ним можно было подумать в фоне или параллельно с другой задачей, потому что для этапа написания кода нужно было специально выкраивать время, то сейчас без готового понимания логики работы системы, нет смысла отдавать задачу в работу — скорость реализации кратно выше скорости обдумывания реализации.

Самый опасный миф об ИИ‑разработке звучит так: «Теперь можно просто говорить машине, что делать». На деле ИИ‑конвейер — это усилитель. Если на входе порядок, то он усилит его, а если нет, то shit in — shit out.

Я понял это, когда поставил агенту задачу с плохо проработанными граничными условиями, а контекста не хватало для того, чтобы продуктовый агент смог распознать этот сценарий. Агенты сделали фичу с тестами и документацией за час, но абсолютно неправильно: я не учёл конфликт версий API при публикации, а агент реализовал спецификацию буквально.

Об этом хорошо написал Михаил Шпаков из Timeweb Cloud в своей статье: LLM обесценили «насмотренность» — знание API, синтаксиса, библиотек. Но «суждение» — умение понять, что именно нужно строить — осталось за человеком, и стало намного дороже.

Тогда же я начал переносить логику с агентов на Python‑скрипты и внешние инструменты. Не потому, что агенты плохи, а потому что детерминированный код для проверок надёжнее. Anthropic в статье «Effective context engineering for AI agents» называет это проблемой управления контекстом: чем его больше, тем выше шанс, что модель упустит критическую деталь; чем меньше, тем выше риск неверного решения. Золотая середина — проектирование спецификации. И этому агента научить нельзя.

Урок июля: ИИ‑конвейер — инструмент, мгновенно показывающий, где у вас бардак, причём гораздо быстрее, чем вы к этому готовы.

Август: наркотик скорости

Август. Бэклог почти пуст. Когда работаешь один, это звучит как мечта, но есть нюанс. Агенты закрывают фичу за пару часов, а придумать хорошую задачу, описать её, спроектировать, проверить на конфликты, продумать UX — это дни. Список задач наполняется медленнее, чем исполняется, и в итоге конвейер простаивает не из‑за поломок, а потому что ты не успеваешь подготовить ему работу.

Начинаешь перерабатывать по вечерам и выходным — проектировать, чтобы утром было что исполнять, подкручивать пайплайн там где проседают метрики чтобы работа была еще эффективней и продуктивней.

А если у вас в компании додумались использовать метрику количества использованных токенов и она начинает падать, то возникает соблазн закидывать сырые задачи в реализацию. Я знаком с коллегой из другой компании, который через нейронки генерирует анекдоты про Ленина — просто чтобы показать метрики роста использования.

Парадокс Джевонса (интересная штука, узнал про него при написании статьи): чем эффективнее использование ресурса, тем больше его потребляется. Например, светодиоды потребляют меньше электроэнергии, в результате объём освещения увеличивается. ИИ‑конвейер стал эффективнее, и я начал проектировать в разы больше.

Может возникнуть логичный вопрос: «Почему бы не сделать сетевой доступ к этому процессу, чтобы можно было оперативнее работать над задачами? Например, ставить задачи через Telegram». Пока я не нашёл пользы в этом решении, но не потому, что сложно, а потому что бессмысленно. Узкое горлышко — это не нарезка задач, а качество проектирования. Технически, можно было бы «думать об агента» в каком‑нибудь чате, чтобы он готовил задачи для разработки, но тогда есть риск что и вне работы все свободное время будет уходить на это.

Урок августа: скорость — наркотик: доза будет расти, особенно для бизнеса. Настоящий прогресс не в ускорении, а в том, чтобы перестать терять данные на передаче между системами и агентами. Сейчас я расширяю детерминированное покрытие: подключаю внешние инструменты, чтобы проверки и синхронизация работали не на нейронках, а на коде. ИИ остаётся там, где он силён — в генерации и анализе. Всё остальное я отдаю внешним инструментам.

Эпилог

На сегодняшний день, схематично, пайплайн выглядит так

Скрытый текст

Каждый месяц я спорил с одной и той же мыслью: «наверное, нейронка сможет и это». А она не может — она не «умеет» ничего, она лишь выдает текст — не важно, код, спецификация или результаты каких‑либо проверок. Все шишки от неправильного понимания технологии, когда ты ждешь от неё человеческого, в виде памяти или ответственности за результат.

• «Она помнит проект» — нет. Памяти у модели нет: есть только то, что ты положил перед ней в этом прогоне. Всё, что ты держишь в голове как «очевидный контекст», для неё не существует, пока не записано в файл.

• «Она проверит» — нет. Модель не умеет проверять, она умеет убедительно отвечать.

• «Она скоординирует» — нет. Координация — это правила и состояние, а это код, а не генерация.

Остальное — та же ошибка, но в профиль. Монолитный промпт на тысячу строк — вера, что модель удержит сотню инструкций разом. Выросшая когнитивная нагрузка — вера, что раз модель пишет код, мне можно не думать. Пустой бэклог — вера, что скорость сама придумает себе работу.

Что сработало и прижилось

• Качество — это порог — код не попадает в репозиторий, пока не пройдёт обязательный минимум: тесты, линтер и проверку, что задача и связанная спецификация к ней вообще существует. Порог одинаковый каждый день и не зависит от того, как «сегодня себя ведёт» модель. Раньше качество держалось на дисциплине конкретного человека, теперь — на конфигурации, которую невозможно случайно обойти. Контроль этапов задачи и переходов между ними вынесен в python‑скрипты, а не промпты агента.

• Безопасность вынесена в отдельный контур. Уязвимости ищет инструмент, который работает по чётким правилам, а не угадывает по вероятности. Модель читает готовый отчёт и предлагает исправления, но вердикт «чисто или нет» принимает не она. Это закрыло целый класс ситуаций, где модель уверенно отвечала «всё в порядке», а сканер находил критичное.

• Процесс стал прозрачным — opencode отдаёт события на каждом шаге — когда началась задача, какие файлы изменились, что сделал каждый агент. Я подключился к этому потоку и собрал из него картину: каждая задача классифицируется, проходит по стадиям от постановки до сдачи, и видно, на какой именно она застряла. Раньше я «чувствовал», что конвейер работает, — теперь вижу это по данным. Данные агрегируются в дашборд и всегда можно посмотреть детали работы — где западает вызов навыка, где есть смысл написать скрипт вместо промпта, где не произошел ожидаемый переход между стадиями или агентами

• Стоимость стала предсказуемой. Каждая задача попадает в один из типов, и под каждый тип — своя глубина процесса: новая фича идёт по полному циклу, правка бага — по короткому, консультация не трогает код вовсе. Чем проще задача, тем меньше она стоит.

Где может не сработать?

Иногда слышу: «Круто, посадим одного человека с ИИ‑конвейером и порежем команду». Где не сработает:

1. Если цель — сэкономить на людях. Не сэкономите. Конвейер снимает с вас написание кода/тестов/документации и переносит работу туда, где она дороже: спецификации, приёмка, архитектурные решения. «Насмотренность» подешевела, «суждение» подорожало — и платить придётся именно за суждение. Человек, который не может сказать, что именно нужно построить, с конвейером просто будет производить мусор быстрее. Один такой «владелец продукта» работает за троих, выгорает и уходит — обратный эффект от экономии.

2. Если ждёте, что «поставил и забыл». Настройка заняла месяцы, и это кропотливая работа: подкрутить промпт, обновить навык, поправить оркестратор. После первого «оно работает» начинается бесконечная доводка, которая длится дольше чем сам запуск. Под это сразу стоит заложить ресурсы, потому что даже любой готовый пайплайн с Гитхаба требует адаптации под ваши нюансы.

3. Вы хотите разбить команду на независимые ячейки по одному человеку. Звучит заманчиво: вместо команды из пяти человек — пять разработчиков, и каждый со своим продуктом. Но чтобы в одиночку сопровождать продукт, нужен специфический склад характера. Нужно быть готовым пройти весь цикл от разговора с пользователем до ввода в эксплуатацию: без коллеги, которому можно сказать: «Посмотри, пожалуйста», без проверки кода человеком, без права заболеть и передать задачу. Это не столько техническая, сколько психологическая нагрузка. За восемь месяцев я не раз ловил себя на мысли, что мне критически не хватает второго человека, чтобы просто разгрузить голову.

4. У вас большой ключевой продукт, от которого компания получает прибыль. ИИ‑конвейер ошибается. Во внутренних инструментах цена ошибки — час простоя и недовольный коллега, а в ключевом продукте — деньги компании. Чтобы снизить риски, нужно вкладываться в митигацию, а если это требует инвестиций против уже работающей команды — может оно того не стоит?

Что дальше

Основные векторы до конца года примерно такие:

• Переход от harness к hardness — Сейчас я разбираю пайплайн проверку за проверкой: что из того, что ещё делают агенты, сводится к чётким правилам и может переехать в скрипты. Если проверка детерминированная — она уходит из агента в код, потому что код не умеет «не заметить» и даёт один и тот же ответ на один и тот же вход. Часть уже переехала (качество, безопасность, телеметрия), часть ещё сидит на агентах. Чем формальнее спецификация, тем больше таких проверок из неё можно вывести автоматически.

• Управление контекстом продукта — бизнес‑правила, стандарты и ограничения интеграций живут у меня в голове, и агенты узнают о них, только когда я вспомню им сказать. Да, часть из того уже вынесена в блок core‑rules которые импортируются в любой проект, но сейчас там есть далеко не всё.

• Допиливание синхронизации между репозиториями. Несколько агентов синхронизации — все еще лютый костыль и велосипед: мир давно не синхронизирует контракты вручную. Индустрия решает это несколькими способами. Первый — контракт как код: описал API один раз (OpenAPI, Protobuf), а типы и клиенты для всех репозиториев генерируются автоматически, без синхронизатора. Второй — контрактное тестирование: каждая сторона описывает, чего ждёт от другой, и CI сверяет эти ожидания — ломающее изменение падает на проверке, а не теряется по дороге (пример — Pact). Я пошёл другим путём — самым дорогим, поручил синхронизацию нейронке: она читает контракт как текст, пытается развезти изменения по репозиториям и не ловит неочевидное, поэтому контракт меняется, а фронтенд живёт со старыми типами. Цель теперь — сойти на первый путь: контракт в одном месте, типы и проверки генерируются из него. По логике SDD контракт между репозиториями — это та же спецификация: источник правды, а не текст, который кто‑то «синхронизирует».

  ---

А как это работает у вас? Пробовали ли делать ИИ‑конвейеры для разработки?

• Какой стек используете: OpenCode, Cursor, Copilot, Aider, или что‑то своё?

• Какие модели применяете и во сколько это обходится?

• Сколько репозиториев в работе и как решаете задачу синхронизации?

• Что для вас оказалось неожиданным?

Расскажите об этом в комментариях — соберём картину поверх моей истории.

В качестве завершения: что меня ждёт через несколько месяцев.