За два месяца моя система AI‑агентов принесла компании около 350 тысяч рублей дополнительного дохода и он только растет. Она самостоятельно выполняет задачи в реальных коммерческих проектах, работает с существующими репозиториями и позволяет закрывать часть задач практически без участия разработчиков. С точки зрения бизнеса эксперимент оказался успешным, а с инженерной точки зрения у меня накопилось достаточно претензий к собственной архитектуре, чтобы начать разработку новой системы.
Обычно истории об AI‑агентах строятся вокруг их возможностей: какую модель использовали, сколько агентов запустили и какие задачи удалось автоматизировать. Но в коммерческой разработке рано или поздно возникает более приземленный вопрос: какую пользу все это приносит компании? Мне удалось получить на него вполне конкретный ответ, а заодно выяснить, что работающий продукт и надежный продукт далеко не всегда одно и то же.
Как разработчики превратились в поисковик с зарплатой
В нашей компании однажды появился мем: «Разработчики — это поисковик с зарплатой». И возник он не на пустом месте. Менеджеры по пять‑десять раз в день обращались к разработчикам с вопросами от клиентов: почему определенная функция работает именно так, где реализована конкретная логика, можно ли изменить поведение системы и что вообще происходит внутри проекта. Зачастую для ответа достаточно было открыть код и разобраться в нескольких файлах, но менеджер не всегда мог сделать это самостоятельно. В результате разработчик отвлекался от своей работы, менеджер нервничал в ожидании ответа, а заказчик ждал. Замечательная организация процесса, в которой все заняты, но никто особенно не счастлив.
Изначально я хотел решить именно эту проблему. Так появился Repo Chat, позволяющий менеджеру задать вопрос на обычном языке и получить ответ на основании исходного кода проекта со ссылками на конкретные файлы. Постепенно идея развивалась: если система уже умеет анализировать существующий код, почему бы не научить ее самостоятельно выполнять небольшие задачи? В результате появился второй компонент AI Workflow, автоматизирующий разработку от постановки задачи до создания запроса на слияние. Человек описывает требования и критерии приемки, агент выполняет изменения, запускает проверки и передает результат на ревью. Если обнаруживаются замечания, задача возвращается на доработку через того же агента.
Отдельно отмечу, что проект я разрабатывал не один. В реализации системы также участвовал мой коллега, и было бы несправедливо приписывать весь результат исключительно себе. Идея и развитие архитектуры были лишь частью работы, без которой проект не дошел бы до реального использования.
А почему просто не использовать Claude Code или Codex?
Вполне закономерный вопрос. На рынке уже существуют инструменты, способные анализировать репозитории, писать код и самостоятельно выполнять задачи. Зачем разрабатывать собственную систему, если можно воспользоваться готовым решением? Проблема в том, что технические возможности AI‑агента и возможность безопасно предоставить его сотрудникам компании — совершенно разные вещи. Claude Code и Codex умеют работать с кодом, но для этого им необходим доступ к соответствующему контексту. И именно здесь начинаются организационные ограничения.
Представим обычного менеджера, которому необходимо ответить на вопрос заказчика о поведении определенной функции сайта. Чтобы использовать стандартный coding‑агент напрямую, ему потребуется организовать доступ к проекту и соответствующему окружению. Но выдавать менеджерам прямой доступ к исходным кодам коммерческих проектов, Git‑репозиториям и инструментам разработки ради подобных вопросов — сомнительная идея с точки зрения безопасности и управления правами. Даже если сотрудник хорошо разбирается в программировании, это не означает, что ему необходимы такие полномочия для выполнения рабочих обязанностей.
AI Workflow решает проблему иначе. Система централизованно подключается к разрешенным репозиториям, а сотрудники получают доступ к конкретным функциям через единый интерфейс. Менеджер может задать вопрос о коде или поставить задачу на разработку, не получая прямого доступа к репозиторию и учетным данным Git. Права на проекты и доступные действия определяются централизованно, а результат разработки проходит предусмотренный процесс проверки и приемки.
В этом и заключается главное отличие моей системы от простого использования coding‑агента. Я не пытался создать модель, которая пишет код лучше Claude или Codex. Мне нужен был управляемый инструмент, который позволит использовать возможности AI‑разработки сотрудникам, не имеющим прямого доступа к исходникам. И, как оказалось, для бизнеса эта разница гораздо важнее очередного сравнения качества генерации кода.
Как эксперимент начал приносить деньги
В коммерческой разработке существует множество задач, которые не требуют сложных архитектурных решений, но регулярно отнимают время команды. Исправить поведение формы, изменить интерфейс, доработать существующий компонент или устранить небольшой дефект бизнес‑логики. Каждая такая задача требует изучения контекста, реализации, проверки и передачи результата, причем непосредственно написание кода иногда занимает меньшую часть времени. AI Workflow позволил автоматизировать значительную часть этого процесса, оставив человеку постановку задачи и приемку результата.
На реальных проектах система оказалась способна выполнять не только простейшие изменения. Она анализировала существующие репозитории, работала с несколькими файлами, проходила автоматические проверки и могла самостоятельно разбивать крупные задачи на этапы. По моей оценке, около 70% задач завершались без существенных доработок: часть принималась сразу, часть требовала небольших исправлений через того же агента. Это эксплуатационное наблюдение, но результат оказался достаточно убедительным, чтобы продолжить использование системы в коммерческой работе.
За первые два месяца дополнительный доход компании, связанный с использованием этой системы, составил, по нашим внутренним оценкам, около 200 тысяч рублей. Еще примерно 150 тысяч мы оценили как экономию рабочего времени и ресурсов. Вместе они дают ориентировочный экономический эффект в 350 тысяч рублей. Но даже с этой оговоркой результат оказался показательным: внутренний эксперимент начал приносить компании измеримую пользу, а не просто демонстрировать возможности современных языковых моделей.
Именно здесь я столкнулся с главным противоречием проекта. Для бизнеса важны стоимость выполнения работы, сроки, качество результата и возможность освободить ресурсы команды. Для разработчика к этому добавляются надежность архитектуры, воспроизводимость процессов, технический долг и потенциальные точки отказа. Пока система выполняет задачи и экономически оправдывает свое существование, далеко не все ее внутренние проблемы заметны бизнесу. И, как выяснилось, коммерчески успешный продукт вполне может быть построен на архитектуре, которую его автор впоследствии сочтет неудачной.
Что пошло не так
Проблемы начали проявляться по мере эксплуатации, причем далеко не всегда были связаны с качеством работы самих моделей. Например, при проверке рабочих копий репозиториев выяснилось, что некоторые из них не обновлялись месяцами. При этом Repo Chat продолжал отвечать на вопросы пользователей и ссылаться на исходные файлы, не предупреждая об устаревшем состоянии данных. Важно уточнить, что это касалось копий для анализа и просмотра файлов: при выполнении задач разработки использовался отдельный механизм получения актуального состояния репозитория. Но сама ситуация выглядела довольно абсурдно: система уверенно объясняла устройство проекта, не проверяя, насколько ее представление о нем соответствует действительности.
Обнаружились и другие проблемы. Обновления служебных файлов подготовки не всегда попадали в уже созданные рабочие ветки, из‑за чего существующие проекты продолжали использовать старые механизмы. Общий лимит параллельных задач мог приводить к задержкам независимых проектов, несмотря на изолированные рабочие окружения.
Главная ошибка моего первоначального подхода заключалась в чрезмерной концентрации на возможностях агентов. Меня интересовало, какие задачи они могут выполнить, насколько качественно пишут код и сколько действий способны совершить без участия человека. При этом надежность окружающей инфраструктуры оставалась на втором плане, хотя именно она определяет, можно ли доверять системе продолжительную самостоятельную работу. Способность агента успешно выполнить задачу еще не означает, что оркестратор способен корректно управлять окружениями, учитывать изменения состояния и безопасно обрабатывать сбои.
Деньги
Было бы удобно закончить эту историю выводом о том, что первая архитектура оказалась неудачной и автономные AI‑агенты пока не готовы к коммерческой разработке. Проблема только в том, что система продолжает работать, выполнять реальные задачи и приносить компании пользу. Ее недостатки не отменяют экономической ценности подхода, а скорее показывают, какие проблемы необходимо решить, прежде чем увеличивать масштаб автономности. Отказываться от технологии, которая уже продемонстрировала практический результат, исключительно из‑за недовольства первой реализацией было бы довольно странным бизнес‑решением.
Именно поэтому сейчас я работаю над новым проектом. В отличие от AI Workflow, который создавался для выполнения отдельных задач в существующих репозиториях, новая система ориентирована на управление целыми проектами: их состоянием, зависимостями, исполнителями, памятью и восстановлением после сбоев. При проектировании я стараюсь уделять больше внимания не количеству действий, которые способен совершить агент, а надежности механизмов, управляющих этими действиями. Впрочем, объявлять новую архитектуру успешной до ее проверки в реальной эксплуатации я больше не собираюсь.
Первая версия оставила после себя два результата. Как создатель, я не считаю ее архитектуру достижением, которым стоит гордиться. Как человек, заинтересованный в коммерческом применении AI, я вижу работающий инструмент, который подтвердил экономический потенциал автономной разработки. И теперь у меня есть вполне рациональная причина продолжать работу, несмотря на все обнаруженные недостатки.
Деньги, оказались убедительнее моих архитектурных претензий.
P. S. О безопасности данных
Поскольку речь идет о коммерческих репозиториях, отдельно предусмотрел ограничения доступа к исходному коду. Каждая сессия запускается в отдельной чистой виртуальной машине, задачи изолированы друг от друга, если при постановке явно не указана связь между ними. Агент получает карту зависимостей проекта и только тот контекст, который необходим для выполнения задачи. Если для работы требуется доступ к закрытому модулю с чувствительными данными, система сообщает об ограничении, а не предоставляет доступ автоматически.
Для задач с конфиденциальной информацией предусмотрен отдельный флажок «Чувствительная информация», который переключает выполнение на локальную модель. Таким образом, менеджеру не требуется прямой доступ к репозиторию, а агент работает в пределах выданных ему полномочий. Разумеется, это не делает систему неуязвимой, но позволяет централизованно контролировать доступ к исходному коду и среду выполнения.
Автор: BladeConjuror
