Евгений Пачки: упростил агентные пайплайны и стал вести 5-6 проектов вместо двух
В кейсе рассказываем, как Евгений за несколько месяцев прошел путь от обычного чата с нейросетью до собственного пайплайна разработки на Claude и Codex. Сначала он собрал тяжелую систему из десятка агентов: они планировали, проверяли и писали код почти без него. Система правда работала, но для большинства задач оказалась слишком долгой и дорогой. Тогда Евгений разобрал ее до более легкой схемы, добавил G-Brain как память решений по проектам и теперь спокойно ведет 5-6 проектов параллельно вместо прежних двух.
Сначала нейросеть была для меня просто чатом, с которым можно поговорить
По-настоящему нейросети вошли в мою работу 31 января, хотя разовые эксперименты были и раньше. Сначала это был просто чат: открываешь GPT, пишешь вопрос, обсуждаешь задачу, забираешь ответ. Codex (сервис для кода от OpenAI) у меня тоже уже был, но я не воспринимал его как место, где можно реально вести разработку.
Гайды, курсы, вебинары — и еще куча всего, чтобы нейросети работали на вас
Я относился ко всему этому скептически. Нейросеть была для меня собеседником, с которым удобно что-то проговорить, а не инструментом, которому можно отдать кусок разработки.
Так продолжалось, пока я не ушел в отпуск на две недели. Этот отпуск и стал точкой, после которой я понял, что обычного чата мне больше не хватает.
Когда я вернулся, меня ждала задача из тех, которые на словах не выглядят сложными, но быстро съедают дни: много однотипных действий, много контекста, много ручной сборки. Это не инженерная головоломка, а болото, где ты вроде бы занят весь день, но по ощущениям просто перекладываешь куски информации туда-сюда. Я посмотрел на нее и понял: привычным способом это превратится в долгую рутину. Мне нужен был уже не собеседник, который отвечает на вопросы, а инструмент, который сам двигает разработку. Я обсудил это на работе, коллеги предложили попробовать Claude, и с этого момента я полез разбираться всерьез.
За несколько дней я дошел до подписки за $200 и понял: вокруг Claude нужна система
Дальше все закрутилось быстро. Уже в первый день работы с Claude я полностью высадил подписку за $20 и сразу же оформил подписку за $100, а через четыре дня поднял ее до $200 — и ниже этого уровня с тех пор не опускался. Codex к тому моменту я тоже перестал держать в стороне: раз я всерьез взялся за разработку с нейросетями, обе подписки пошли в полную силу, и какое-то время я платил по $200 и за Claude, и за Codex.
Примерно через две недели работы с Claude до меня дошло: я использую его как умный чат, хотя он может быть частью настоящего рабочего процесса. Чтобы добраться до этого уровня, мало было задавать вопросы в чат. Нужен был процесс вокруг модели: чтобы она не просто отвечала на отдельные вопросы, а вела задачу от идеи до готового кода.
Так появилась моя первая система. Я собрал ее на Agent Teams — это режим, где задачу выполняет не один помощник, а несколько независимых агентов Claude, и каждый отвечает за свой кусок. Я даже выложил ее в открытый доступ под названием bishx.
Я построил конвейер из десяти проверяющих — и сам утонул в его поддержке
Работала система как конвейер. Сначала из моей сырой идеи собирался рабочий промпт. Дальше этот промпт уходил в планирование, и вот там начиналось самое тяжелое.
План разбирали сразу десять ролей. Был исследователь, который копался в коде и документации. Был планировщик, который собирал план реализации. А дальше его рвали на части проверяющие: скептик искал, где план врет, TDD-ревьюер следил за тестами, отдельные агенты проверяли полноту, совместимость кусков между собой, безопасность и производительность. В конце критик ставил оценку, и если плана не хватало, все уходило на новый круг — так до десяти итераций, пока план не проходил порог.
Только после этого начиналась разработка: ведущий разработчик писал код, три ревьюера параллельно искали баги, дыры в безопасности и места, где код расходится с правилами проекта, а в конце QA-агент прогонял приемку. Поэтому одно планирование могло идти два-три часа: система долго спорила сама с собой, прежде чем кто-то вообще начинал писать код.
Изначально я хотел почти убрать себя из процесса — чтобы система сама планировала, проверяла и доводила задачу до конца. На практике вышло наоборот. Руками я писал код реже, зато с головой ушел в поддержку самой системы: десять ролей, итерации, проверки — все это надо было настраивать и чинить. Я не жалею, что прошел через этот этап: именно так я понял, на что нейросеть способна, где ошибается и как с ней разговаривать. Но за такое качество приходилось платить слишком много, и скоро это стало очевидно.
Система работала отлично, но жгла деньги и время на задачах, которые того не стоили
Я постоянно ее переделывал: улучшал, добавлял шаги, закрывал слабые места. И большие пайплайны правда работали — давали качественный, вылизанный результат.
А потом я увидел цену. Те самые две подписки по $200 — на Claude и на Codex — я жег на полную, и большая часть лимитов уходила как раз в эту тяжелую махину. Задача делалась хорошо, но я платил за это деньгами, временем и вниманием.
В какой-то момент я поймал себя на простой мысли: если задача реально сложная, такой конвейер оправдан. Там и нужны проверки, ревьюеры и долгое планирование. Но в реальности таких задач меньше, чем кажется. Для примерно 70% работы вся эта махина была избыточной — я запускал тяжелую схему там, где хватило бы пары шагов. И я решил добиваться того же результата проще.
Все нейросети
в одном флаконе
ChatGPT, Claude, Gemini
и другие — в агрегаторе Нейроцеха
Я перенес идею в Codex и оставил от пайплайна только то, что реально нужно
Разбирать эту махину я начал в Codex. Из тяжелого конвейера собрал легкий скилл, который назвал bx-dev. Это уже не десять ролей с итерациями, а короткая рабочая сессия: открываешь Codex в нужном репозитории, даешь задачи обычными словами, а скилл сам заводит отдельную ветку, поручает реализацию и ревью паре агентов, делает коммиты и по команде отправляет все на проверку и вливает в основную ветку.
Логика осталась той же — реализация, ревью, последняя проверка перед вливанием. Но из нее ушло все, что раздувало время и счет. Для сложной задачи можно включить дополнительную проверку, для мелкой — вообще запустить без агентов. Теперь нагрузка подстраивается под задачу, а не висит на каждой мелочи.
Вот так на простых задачах вместо двух подписок и многочасового планирования мне стало хватать примерно $100 в месяц.
Теперь задача чаще начинается не с ТЗ, а с транскрипта созвона
Изменилось даже то, откуда начинается задача. Раньше я стартовал с технического задания, а сейчас задача часто рождается прямо из разговора. Возьмем созвон: сидят четыре-пять человек, смотрят продукт, обсуждают, что доработать, что нравится, что нет.
Внутри компании для этого есть внутренний инструмент транскрибации: после встречи я получаю текст всего разговора, разбитый по говорящим. И тут важно не только что сказали, но и кто это сказал: одна и та же фраза от разных людей значит разное. То, что говорю я, — обычно про уже сделанное или про устройство системы: почему что-то работает именно так, какие ограничения заложены. А слова заказчика я читаю в первую очередь: там появляются новые требования и обратная связь по продукту.
Дальше я вытаскиваю из транскрипта требования, решения и договоренности и отправляю его во встроенное планирование Codex через /plan. Из транскрипта собирается план задачи, и она уходит в разработку.
Когда проектов стало 5-6, я перестал держать все решения в голове
С таким простым процессом я смог брать больше проектов сразу — и тут вылезла новая проблема. В один день я делаю три проекта, во второй еще три, на третий созваниваюсь по первым. В работе одновременно крутится пять-шесть проектов, и помнить все решения по каждому невозможно.
Когда я вел один проект, было легче: я глубоко в него вникал и держал все в голове. Сейчас такое глубокое погружение в один проект только мешает — я либо застряну в нем надолго, либо начну переделывать то, что уже было нормально решено. Решения начали расползаться по чатам, созвонам и задачам, и мне понадобилось место, где они будут жить вместо моей памяти.
Этим местом стал G-Brain. Это не свалка заметок, а рабочая память решений по проектам: текстовые Markdown-файлы, индексация и быстрый поиск. Туда же уходят и транскрипты созвонов: разговор не остается записью «на всякий случай», к которой никто не вернется, — его можно найти, перечитать и взять как основу для следующей задачи. Когда нейросеть упирается в развилку и не знает, как поступить, она сначала идет туда и проверяет — а не решали ли мы похожее раньше. И только если ответа нет, спрашивает меня.
G-Brain не дает нейросети «чинить» то, что и так работает правильно
Проще всего объяснить на примере. Исходный код нейросеть видит. Но она не знает истории локальных решений: зачем в проекте оставили именно такой странный кусок и почему его лучше не трогать. Это обсуждается на одном созвоне, а через месяц-два я и сам уже не вспомню деталей.
Допустим, из одной внешней системы дата приходит в нестандартном формате. В коде это выглядит криво. И если позже появляется задача про неверный часовой пояс, нейросеть смотрит на этот кусок и уверенно решает: вот она, ошибка, надо привести дату к нормальному виду.
А на самом деле формат оставили таким специально — из-за особенностей той системы. Если нейросеть начнет его «чинить», она сломает то, что работало, и добавит новую ошибку. Вот тут и срабатывает G-Brain: он подсказывает, что это решение уже обсуждали, почему дату оставили как есть и почему здесь лучше ничего не трогать.
Для меня это снимает огромную нагрузку с головы: я больше не обязан держать в памяти все договоренности по шести проектам.
Нейросеть стала реже спрашивать меня — она сначала ищет ответ сама
Вот тут я впервые почувствовал настоящую разницу. Раньше мы максимум параллелили два проекта, да и то условно: с утра делаешь один, днем переключаешься на другой. Все равно последовательно, просто с переключением контекста.
Сейчас я запускаю несколько контекстных окон по разным проектам сразу. В каждом уже лежат файлы по задачам, транскриптам и решениям. Нейросеть читает их и не дергает меня каждый раз с вопросом, откуда взялось то или иное решение. Если контекста не хватает, она идет в G-Brain: видит, что файл собран из конкретного транскрипта созвона, открывает его и сама дочитывает, что там обсуждали.
Иногда она все же предлагает: «Иди спроси у заказчика». А я понимаю, что мы это уже когда-то обсуждали, просто я не помню где. И тут снова выручает G-Brain — старый контекст находится без того, чтобы я вручную пересказывал всю историю. В итоге я меньше объясняю одно и то же, меньше завишу от своей памяти и спокойнее держу в работе сразу несколько проектов.
Все эти системы я доводил не в стороне, а прямо на живой работе
И bishx, и bx-dev, и G-Brain, и Telepath я строил примерно одинаково. Telepath — это мой публичный пет-проект, уже про личный Telegram: он расшифровывает входящие и исходящие голосовые сообщения и видеокружки, аккуратно причесывает текст через LLM, умеет экспортировать историю чатов и управляется через отдельного бота, доступного только владельцу. Голосовые и переписки не тонут в мессенджере, а превращаются в текст, с которым можно работать.
Вся разработка у меня идет с личного ноутбука, и любую из этих систем я внедрял итерациями: запускаешь на реальной задаче, смотришь, где она спотыкается, и тут же дорабатываешь. Каждый запуск быстро показывал шероховатости. Не смертельные, но оставлять их надолго не хотелось. Поэтому я открывал параллельную сессию и сразу правил систему по тому, что увидел в деле. Я не пытался сначала довести все до идеала где-то в стороне, а потом применять. Мне важнее было увидеть, выдерживает ли это живую работу.
Мне такой ритм подошел: запускаешь, проверяешь, дорабатываешь — и со временем понимаешь, что именно хочешь видеть в системе. А заодно она становится проще, потому что лишние шаги постепенно отваливаются.
Итог: 5-6 проектов вместо двух и меньше ручных объяснений
Если коротко, путь получился такой. Я начинал с обычного GPT-чата, где можно было только поговорить. Потом перешел на рабочий Claude и построил тяжелый конвейер из десяти проверяющих ролей — он давал отличный результат, но для 70% задач был слишком долгим и дорогим. Тогда я перенес идею в Codex, выкинул лишний вес и добавил память решений по проектам.
Теперь вместо $400 в месяц на две подписки теперь на обычных задачах уходит около $100. Но главное даже не в этом. По-настоящему изменилось то, сколько работы проходит через меня: потолок вырос с двух проектов до 5-6, по каждому открыто свое контекстное окно, и я перестал быть единственным человеком, который помнит, почему система устроена именно так.
В Нейроцехе я перестал бояться быстрых запусков и пользовательского фидбека
Технически я и раньше понимал, что систему можно запускать сырой и дорабатывать на ходу — я ровно так и строил свои инструменты. Но когда дело доходило до продукта, внутри сидел другой страх. Хотелось сначала довести все до технического идеала, все проверить, потратить полгода на разработку и только потом пустить первого пользователя.
Нейроцех помог мне с этим страхом расстаться. Я начал видеть в пользователях не судей, а людей, которые дают обратную связь и помогают сделать продукт лучше. Делать все равно нужно качественно, но критика перестала быть приговором. Будет замечание — будет решение, а люди видят, что над продуктом работают и фидбек не пропадает в пустоту. Из-за этого ушло самобичевание, которое раньше тормозило и сами продукты, и обновления.
Это видно прямо на моих текущих проектах. Если бы я делал эти 5-6 штук до Нейроцеха, я бы откровенно боялся их выпускать — мне все казалось бы, что там еще не все в порядке. А сейчас я выпускаю, получаю фидбек и спокойно дорабатываю. Часто пользователи предлагают то, до чего я сам бы не дошел: без них я мог бы уйти в другую сторону, надолго застрять, а потом все равно прийти к тому, что люди предложили с самого начала. В итоге я перестал ждать стерильного момента: запускаю, смотрю, что происходит в реальности, и дорабатываю по живой обратной связи.