Как один человек строит production-CRM командой ИИ-агентов

Что это за продукт и почему один человек

Это боевая CRM для сервисной B2B-компании в РФ. Она ведёт бронирование ресурсов, считает заказы, выставляет документы, отбивает чеки по 54-ФЗ и обменивается данными с 1С. Прод, живые пользователи, реальные деньги в обороте. Под NDA я не называю ни клиента, ни отрасль, ни город. Дальше в тексте только метод и стек, без узнаваемых деталей.

Обычно такой продукт строит команда из пяти-шести человек. Продакт, два разработчика, тестировщик, безопасник, дизайнер. Я веду проект один. Штат разработки нулевой. Вместо найма я оркестрирую команду ИИ-агентов через Claude Code. Каждый агент держит свою роль, я держу общую картину и принимаю решения там, где цена ошибки высокая.

Дирижёр и команда из 13 ролей

Дирижёр это человек, который ставит задачу и принимает решения. Оркестратор это Claude Code. Он не пишет код в одну голову. Он запускает команду специализированных агентов, у каждого своя роль и зона ответственности. Владелец ставит цель. Дирижёр через Claude Code разворачивает её в задачи. Продакт-агент синтезирует мнения. Дальше за дело берутся профильные роли.

В пуле 13 ролей. Продакт-менеджер, разработчик, инженер по тестированию. Три роли по безопасности, это прикладная безопасность, пентест и разбор событий. Технический директор для архитектурных решений. Юрист по праву РФ, бухгалтер, эксперт по 54-ФЗ и фискализации, отраслевой эксперт. Дизайнер интерфейсов и бизнес-аналитик. Важная оговорка сразу. Тринадцать ролей не значит, что над каждой задачей работают тринадцать. На конкретную правку выходит подмножество, которое нужно именно ей. Кого позвать, решаю я по содержанию задачи.

Когда подключается профильный эксперт и зачем

Профильную роль включает содержание задачи, а не желание показать большую команду. Тринадцать ролей не значит, что над каждой задачей работают тринадцать. Юриста не зовут на правку кнопки. Дизайнера не зовут считать налог.

Большинство правок проходят коротким составом. Разработчик-агент пишет, ревью-панель смотрит, тесты гоняют, человек одобряет выкатку. Профильный эксперт подключается по триггеру, и сам факт вызова с результатом фиксируется в задаче. Поэтому всегда видно, кто и почему участвовал. Какой триггер какую роль зовёт, в таблице ниже.

Конвейер от цели до прода, по шагам

Конвейер тот же, что в зрелой команде разработки. Цель превращается в постановку. Постановка в задачи в трекере. Задачи в код. Код проходит ревью и автоматические проверки. На зелёном гейте идёт выкатка с заранее заданной точкой отката. Разница не в этапах, а в том, кто их проходит. Этапы проходят агенты. Я держу гейты на входе и выходе. Вот весь поток на одной схеме.

Как идёт ревью кода и кто что смотрит

Ревью каждой правки проходит командой ролей-ревьюеров, и смысл панели в том, что роли смотрят разное, а не одно глазами шестерых. Базовый контур это прикладная безопасность, пентестер, разбор событий и инженер по тестированию. Они держат блокеры по безопасности и качеству. Полная панель доходит до девяти ролей и добавляет технического директора, дизайнера, бизнес-аналитика. Юриста, отраслевого эксперта и бухгалтера подключаю, когда правка их касается.

Что после выкатки и при чём здесь Service Desk

После выкатки система живёт сама под присмотром. Здесь два потока работы. Первый это когда что-то сломалось, надо найти и починить. Второй это когда пользователь попросил что-то сделать, надо выполнить. На языке ITIL это управление инцидентами и исполнение запросов. Новизна одна. Рутинную часть обоих потоков выполняют агенты, а не дежурная смена людей.

Поток инцидентов выглядит так. Мониторинг ловит сбой и фиксирует его как тикет. Агент разбирает тикет, находит причину, чинит обратимое сам и пишет, что сделал. Если действие необратимое или затрагивает деньги, агент останавливается и ждёт меня. Поток запросов проще. Пользователь пишет, что ему нужно. Агент разбирает запрос и выполняет его, оставаясь в границах безопасного. Это и есть AI Service Desk. Рутину закрывает агент, риск-решения остаются за человеком.

Где ИИ не решает и кто отвечает за прод

Главный принцип короткий. Агент сам делает то, что безопасно и обратимо. Всё необратимое, всё, что касается денег или прод-схемы, проходит через моё явное подтверждение. За инцидент на проде отвечаю я, а не агент. Это не оговорка мелким шрифтом, а основа доверия к модели.

Честно про слабое место инструмента. ИИ убедительно ошибается. Он может выдать код, который компилируется и падает на проде, сослаться на несуществующий метод или на устаревшую документацию. Это не повод от него отказываться. Это повод не оставлять его без проверки. Поэтому ревью, тесты и явное подтверждение человека на риск-действие не бюрократия, а условие, при котором модель вообще безопасна.

Есть и отдельный класс риска именно у агентной модели. Это подмена инструкции через входные данные. Тикет или сообщение пользователя могут содержать текст, который агент примет за команду. Защита тут не магический фильтр, а та же граница ответственности. Агент не делает необратимое и не трогает деньги и схему без человека, поэтому худшее от такой подмены упирается в гейт. Специализированную защиту от инъекций я честно отношу к зоне развития, а не выдаю за готовую.

Следующие четыре факапа это не провал процесса. Это доказательство, что процесс реалистичный, а не нарисованный. Ревью и тесты не обнуляют ошибки, а сужают их. Гонку видно только под одновременной нагрузкой. Пустой ключ сборки виден только на живом проде. Каждый факап закончу тем, какую часть конвейера он закалил.

Что уже работает и что я достраиваю

По сути это AIDevSecOps. Безопасность зашита в конвейер, а не приклеена в конце. Три профиля безопасности на каждую правку, тесты безопасности в гейте, разбор событий на проде. До этого доходят не все живые команды. Но честно. Часть контура ещё в работе, и я не выдаю её за готовое.

Ролевую модель прав внедряю поэтапно. Гейты постепенно ужесточаю. Дальше в плане автоматическое сканирование секретов и состава зависимостей по релизам, отдельный контур защиты агентов от подмены инструкций. Вектор развития это и есть признак живого продукта, а не разовой поделки. Я показываю не застывшую картинку, а систему, которая растёт под присмотром.

Сколько это стоит против команды разработки

Считаю грубо и честно. Классический вариант это команда из пяти-шести специалистов. Фонд оплаты труда на несколько человек в месяц плюс налоги, оборудование и время на найм. Моя модель это ставка одного ответственного эксперта плюс расходы на инструменты. Инструменты тут порядка десятков тысяч в месяц, а не миллионы. Разница в полную стоимость получается кратной, в разы, а не в проценты. Это моя практика на моём проекте, а не обещание результата вам.

Кому эта модель подходит, а кому нет

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

Где модель не работает. Хайлоад с миллионами запросов в секунду и тонкой оптимизацией. Системы, где цена ошибки это жизнь и здоровье, и нужна формальная верификация. Глубокий R&D без понятной постановки. Продукты, где десятки людей годами наращивают одну кодовую базу. Там нужна настоящая команда, а не один дирижёр. Честный ответ «вам это не подходит» я даю на первом же разговоре.

Частые вопросы

Не готовы к разговору, это нормально. Напишите три ваши главные боли по ИТ мне в Telegram, скажу честно, ложится тут моя модель или нет. Открыть Telegram.