Финансисты против 10 тысяч строк: как AI‑агент помог настроить систему премирования

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

Меня зовут Андрей Калашников, я финансовый менеджер в облачном интеграторе и дата‑центре OXYGEN. Если вам интересна тема отделов продаж, денег, вайбкодинга — добро пожаловать под кат.

Зачем вообще вайбкодинг? Что не так со стандартными инструментами?

Есть 1С и Excel. Есть инструменты для расчётов, которые называют «специализированными» — различные модули, HR‑платформы, CRM‑ки.

Казалось бы, внедри да радуйся?

Не всё так просто!

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

Вам надо купить пиджак. Есть стандартные лекала (S, M, L, XL). Такой пиджак сядет на тысячи людей — кому‑то лучше, кому‑то хуже. Он универсален, но не идеален. И он не будет подходить отдельному человеку так, как сшитый в ателье по индивидуальным меркам.

Готовые системы закрывают базовые потребности ^[1], но не кастомные. Если задачу нельзя решить стандартными инструментами, придётся делать костыли и допиливать. У поставочного продукта или SaaS это доработки за отдельные деньги (от сотен тысяч до десятков миллионов рублей). Но дело даже не в деньгах, а в сложности взаимодействия заказчика и разработчика — иногда месяцы топтания на месте. Это демотивирует.

Excel позволяет многое в no/low‑code, но чем больше условий, исключений и источников данных, тем сложнее поддерживать конструкцию. Формулы разрастаются, появляются технические вкладки, ручные операции, файлы плодятся. Excel прекрасен для анализа, но превращать его в полноценное приложение мы не захотели.

Нам нужна была система под себя — достаточно сложная в хорошем смысле и удобная. Мы решили ничего не покупать и не достраивать, а сделать самостоятельно.

Что сложного в расчете премий

Когда мы впервые рассказываем коллегам о нашей системе, вопрос всегда один и тот же: а зачем вообще городить огород, если премию можно посчитать в одно действие — привёл клиента, получил условных 10 процентов?

Для каких‑то бизнесов это будет работать. Но у современного поставщика облачных вычислений всё устроено сложнее. Мотивация ^[2] продавца должна решать сразу несколько задач. Как писал классик — слона надо есть по кусочкам.

Это:

• Контроль выполнения плана. Мы не сводим к бинарному «выполнил / не выполнил». Применяем линейную шкалу: выполнил план на 89% — коэффициент 0,89, выполнил на 76% — коэффициент 0,76. Это способ поощрять любой прогресс, а не только 100%‑достижение.

  

• Тримминг парусов. Мы можем гибко направлять отдел продаж в нужное русло. Работа с новыми и действующими клиентами (HOLD / KEEP / FARM / HUNT), размер компаний (SMB/Enterprise или SMA/LA/KA), сегменты/отрасли, регионы/территории, кластеры/плечи, конкретные услуги (SKU) — всё это имеет значение и может менять свой вес. Это тонкая настройка. И чем она тоньше, тем точнее система приводит к нужному результату.

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

В миниатюре все эти блоки выглядят просто. Но затем они умножаются друг на друга, накладываются на десятки менеджеров, сотни клиентов, обширный портфель облачных услуг — и вот мы сидим на берегу озера данных без конца и начала. Вы сможете перемножить в уме две цифры; может быть, сможете даже три. Но для 12 значений нужен блокнот, калькулятор, Excel. А чтобы управлять ста тысячами уникальных строк (Excel ещё справится, человек — нет), десятками коэффициентов, сотнями взаимосвязей и сложной логикой ^[3] их взаимодействия — пора пилить собственный софт на TypeScript, Python или чём‑нибудь ещё.

Вручную можно считать бесконечно, зато с ошибками

Ещё в ручных расчётах риск ошибки ^[4] велик — это не вероятность, а неизбежность. Люди устают, теряют концентрацию, путают строки: внимание ^[5] при монотонной работе с однотипными операциями ограничено.

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

А ведь есть ещё вопросы менеджеров

Менеджер хочет не только видеть результат, но и доверять ему: «Откуда эта цифра? А здесь почему такой маленький процент? Нет, это была не разовая продажа, а абонентская плата!». Мы тратим время на объяснения. Хотелось сократить путь: чтобы коллега смотрел детализацию, не разбираясь в формулах на двадцати листах. В перспективе — сделать интерактив и срезы данных.

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

Как мы пришли к вайбкодингу

Вайбкодинг — это программирование в режиме zero‑code: вернее, код есть, но пишет его агент, не человек. Пользователь описывает задачу простым языком и получает ответ от LLM‑агента, который так же легко вносит исправления по описанию.

Я видел, насколько загружены коллеги из разработки: задач много, приоритеты меняются, ресурсы не бесконечны. И подумал: можем ли мы взять часть работы на себя? Хотя бы попробовать собрать инструмент для задачи, в которой хорошо разбираемся, и пройти первые итерации. Так расчёт премий стал нашим первым экспериментом с AI‑агентом.

Что конкретно мы сделали по шагам

Шаг 1. Установили среду разработки. Выбрали Visual Studio Code — бесплатный редактор для написания и редактирования кода. Он подсвечивает синтаксис и в целом удобнее для работы, особенно если в него встроен AI‑агент, об этом дальше.

Шаг 2. Подключили AI через расширение. У VS Code есть система подключаемых модулей (расширений). Один из вариантов — Codex, интеграция от OpenAI. Альтернатива — Claude Code от Anthropic. Мы выбрали Codex, далее рассказываем о работе именно с ним: это вопрос личных предпочтений, кто‑то работает с одной моделью, кто‑то с другой. Модуль скачивается и появляется отдельной панелью прямо в интерфейсе редактора.

Способ доступа и оплаты зависит от выбранного агента. Для работы Codex необходимо авторизоваться через аккаунт ChatGPT или подключить API‑ключ. Условия доступа и оплаты зависят от выбранного способа подключения.

Шаг 3. Создали пустую папку проекта — это и есть будущий проект. Открываем именно ее в VS Code. Как только редактор открывает эту папку, агент получает доступ к ней и начинает воспринимать ее как рабочее пространство, в котором будет создавать файлы.

Шаг 4. Сформулировали задачу. Я описал задачу агенту очень подробно и последовательно, как если бы общался с разработчиком. Например: «Мы будем разрабатывать систему мотивации ^[6], расчетный движок для премий менеджеров по продажам». Агент в ответ задал уточняющие вопросы — о структуре данных, о нужной логике, — и по мере ответов начал создавать файлы проекта.

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

Шаг 5. Запустили приложение на своем компьютере. Наш инструмент написан на TypeScript с использованием React и Next.js. В текущей конфигурации для его запуска используется Node.js. Агент подготовил файлы проекта и команды: «npm install» устанавливает необходимые библиотеки, а «npm run dev» запускает сервер разработки.

Шаг 6. Проверили результат в браузере. Когда агент сообщает, что часть работы готова, смотрим результат на локальном хосте. После запуска в терминале появляется адрес, обычно http://localhost:3000 ^[7]. Открываем его в браузере и видим интерфейс приложения. localhost ^[8] означает этот же компьютер: для проверки инструмента не требуется покупать домен или размещать сайт в интернете. Пока сервер работает, изменения в коде можно сразу проверять в браузере.

Шаг 7. Наращиваем логику итеративно. Дальше в диалоге с агентом постепенно добавляется бизнес‑логика — теми же словами: «если продукт такой‑то, премия умножается на такой‑то коэффициент». Агент переводит эту формулировку в код, а результат снова проверяем в браузере — сходится ли расчет с ожиданиями.

Шаг 8. Донастраиваем и переспрашиваем. Если что‑то считается не так, прямо говорим: «здесь неправильно, переделай». С агентом можно советоваться, просить проверить формулировки из законодательства, уточнять непонятные моменты — по сути, вести диалог.

Конечно, первое время результат получается сырым и примитивным, а чтобы довести инструмент до рабочего состояния, нужно время. Но все приходит с опытом ^[9]. Главная ценность — можно сразу, почти мгновенно, посмотреть некое MVP системы, которое можно доработать.

Что оказалось сложнее, чем мы ожидали?

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

Главная трудность — точное понимание бизнес‑правил. Агент может написать работающий код, который реализует не то, что имелось в виду. Хотя интерфейс нормальный, ошибок нет, результат правдоподобен. Заметить проблему можно, только зная правильный ответ. Здесь помогают контрольные примеры и self‑checks.

При расхождении я показывал AI конкретный случай: исходные значения, ожидаемый и фактический ответ, просил объяснить вычисления и найти расхождение. Так находились ошибки в коде и неоднозначности правила.

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

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

Вот реальный пример одного из моих боданий.

Обнаружилась ошибка в отображении прироста маржи. На условных цифрах: в сентябре выручка составляла 800, себестоимость — 600, маржа — 200. В октябре: выручка — 900, себестоимость — 650 тысяч, маржа — 250. Прирост маржи 250 — 200 = 50. Подробная расшифровка (в уровне 5) показывала правильное значение (50), а сводная таблица (в уровне 4) — 250. Сам расчёт премии в этом примере был корректным, но объясняющая его таблица вводила пользователя в заблуждение. Полночи я не мог понять, из‑за чего это происходит. Оказалось, интерфейс выбирал только месяцы текущего квартала и терял сентябрьскую базу, заменяя её нулем.

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

А что с безопасностью?

Вопрос безопасности возникает в двух местах: при разработке с агентом и при использовании готового приложения.

Сейчас калькулятор запускается локально. Пользователь выбирает Excel‑файл через интерфейс, приложение читает его и рассчитывает премии непосредственно в браузере. В коде этого расчета нет обращения к AI‑сервису: для начисления премий участие Codex не требуется.

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

Что получилось в цифрах

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

Куда идти дальше

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

Сейчас у нас уже несколько слоёв:

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

• Второй слой детализирует месяцы в разрезе клиентов.

• Третий слой открывает разбивку по конкретным параметрам, которые повлияли.

• И так далее — вплоть до самой глубокой детализации.

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

У этого есть и обратная сторона: постоянная видимость собственного прогресса может работать двояко — для одних это будет мотивацией ^[10] ускориться, для других, наоборот, источником тревоги, если дела идут не так, как хотелось бы. Но этот вопрос мы оставим психологам.

Вместо вывода

Я не говорю, что AI заменит разработчиков. Я делюсь идеей, как финансистам и аналитикам, которые лучше всех знают свою предметную область, снизить порог входа в разработку инструментов. Сейчас я встречаю всё больше резюме, где помимо финансов молодые специалисты указывают Python, SQL, UX/UI, что‑то ещё явно не из мира TradFi. В конце концов, такую систему можно показать отделу айти как прототип, пример того, что надо реализовать. Иногда ведь лучше один раз увидеть.

Если вам интересна тема вайбкодинга, мы с коллегами расскажем и про другие прикладные проекты в компании. Не стесняйтесь написать об этом в комментариях, делитесь мнением, задавайте вопросы. И подписывайтесь на наш Telegram ^[11], там регулярно пишем про облака и кибербез, делимся новостями компании.