Модель бюджета ИИ-команды для небольших стартап-команд

Почему бюджеты маленьких ИИ-команд часто считают неправильно

Основатели обычно начинают с зарплат, потому что зарплаты хорошо выглядят в таблице. Один инженер стоит X, один продакт — Y, и план кажется аккуратным.

Но в ИИ-работе такая логика быстро ломается.

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

Работа с ИИ смешивает расходы на софт и время людей. Модель может за секунды написать черновик кода, тесты, разобрать обращения в поддержку или кратко пересказать документы. Но кто-то всё равно должен всё настроить, проверить результат, поймать тонкие ошибки, заново запустить неудачные попытки и решить, что делать, если ответ выглядит правильным, но на самом деле неверный.

Именно здесь стартап-бюджеты начинают уходить в сторону. Многие основатели считают ИИ-работу обычной разработкой плюс ежемесячный счёт за API. На деле команды платят в четырёх местах: использование модели, время на проверку, инфраструктура и обработка исключений.

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

Простой пример делает проблему очевидной. Если основатель видит, что ИИ берёт на себя 80% программирования, может показаться, что один инженер заменит трёх сотрудников. Но если этот же инженер тратит 18 часов в неделю на проверку результатов ИИ, 6 часов на разбор сломанных запусков и 4 часа на поддержку всей системы, программирование уже не становится узким местом. Узким местом становится контроль.

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

Четыре категории расходов, которые нужно отслеживать

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

Полезный бюджет делит расходы на четыре категории:

• использование модели
• проверка человеком
• инфраструктура
• исключения

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

Проверка человеком — это место, где ломается много бюджетов. ИИ может писать код, тесты, спецификации и ответы в поддержку, но кому-то всё равно нужно проверять рискованный результат. Если старший инженер тратит 90 минут в день на проверку сгенерированных pull request’ов, это не «фоновый шум». Это реальные затраты на труд, и они растут вместе со скоростью релизов и размером команды.

Инфраструктура — это тихий средний слой. Даже маленькой команде нужно где-то запускать задачи, хранить логи, отслеживать ошибки и следить за сбоями. Обычно это значит внешние API, CI-раннеры, базы данных, очереди, инструменты наблюдаемости и системы резервного копирования. Лёгкие команды обычно выигрывают здесь за счёт небольшого стека и отказа от дублирующих инструментов.

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

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

Если какая-то категория кажется слишком маленькой, проверьте её ещё раз. В маленьких командах время на проверку и работа с исключениями часто стоят дороже самих моделей.

Как пошагово построить бюджетную модель

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

Так бюджет будет привязан к реальной работе, а не к предположениям. Если один процесс получается понятным на бумаге, тем же способом можно считать и следующий.

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

Не оставляйте ничего расплывчатым. «ИИ помогает с программированием» — слишком размыто для расчёта. «Claude делает первую версию, а затем разработчик проверяет её 25 минут» — это уже можно заложить в бюджет.

Для каждого шага отслеживайте пять чисел:

• сколько раз он выполняется в неделю
• какая модель или инструмент его выполняет
• стоимость одного запуска для машины
• сколько минут человека нужно на один запуск
• как часто шаг сбо́ит, повторяется или требует доработки

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

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

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

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

Простой пример для одной стартап-команды

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

Начинайте с недельной мощности, а не с должностей. Если основатель может выделять 20 сфокусированных часов в неделю на работу по доставке результата, а каждый исполнитель — по 30, у команды выходит 80 реальных рабочих часов. Обычно это число ниже, чем люди ожидают, потому что встречи, админка и звонки с клиентами забирают свою долю.

Теперь разбейте планируемую работу. На задачи по продукту уходит 48 часов. На поддержку и исправление ошибок — 14. На проверку кода, контента и ответов в поддержку — 12. Итого обычная неделя составляет 74 часа.

На бумаге всё выглядит нормально. Ещё остаётся 6 часов запаса.

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

Теперь та же неделя — это уже 85 часов, а не 74.

Это на 5 часов больше, чем позволяет мощность.

За одну неделю это не значит, что нужно срочно нанимать. Это значит, что кто-то поработает допоздна, какая-то функция задержится или качество поддержки ухудшится.

Если такое случается раз в месяц, команда, скорее всего, справится. Если каждую неделю, картина быстро меняется. Тогда проблема уже не в инструментах. Она в количестве людей или в объёме задач.

Помогает простое правило. Если планируемая работа плюс среднее время на исключения остаются ниже 85% недельной мощности, команда, скорее всего, подобрана разумно. Если показатель всё время выше, сначала сократите объём задач или добавьте помощь на неполный день, а уже потом нанимайте человека на полную ставку.

Именно так часы превращаются в решение о найме, а не в догадку.

Где время на проверку растёт незаметно

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

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

Следующая утечка — переделка после слабого результата. Модель может сделать код, тесты или текст, которые на первый взгляд выглядят нормально, но всё равно не учитывают бизнес-правило. Тогда кто-то замечает проблему, переписывает промпт, запускает задачу заново и снова проверяет результат. Команды часто прячут этот цикл под «мелкими правками», хотя он может удвоить реальное время на простую задачу.

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

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

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

Через две недели картина обычно становится очевидной. Сама модель может стоить недорого, а проверка будет съедать 30–40% всей работы. Это гораздо сильнее влияет на план найма, чем стоимость модели.

Расходы на инфраструктуру без гаданий

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

Бюджет становится надёжнее, когда инфраструктуру делят на фиксированные ежемесячные расходы и расходы, зависящие от использования. Фиксированные расходы остаются примерно одинаковыми даже в тихую неделю. Переменные меняются вместе с трафиком, сборками, хранилищем и активностью команды.

На практике разделение обычно довольно простое. К фиксированным расходам относятся базовые облачные серверы, минимальный тариф базы данных, CI-раннеры, staging, базовый мониторинг, домены и минимальные резервные копии. К переменным — трафик, дополнительное хранилище, минуты сборки, объём логов, события ошибок, перерасход по оповещениям и рост резервных копий.

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

Учитывайте и среды поддержки. Продакшен — это не вся стоимость. Если команда использует staging, тестовые базы, preview-развёртывания и резервные копии, всё это нужно учитывать с самого начала. Даже очень лёгкой настройке нужно хотя бы одно безопасное место, где можно проверять изменения до того, как их увидят пользователи.

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

Дублирующие инструменты стоят дороже, чем ожидают основатели. Два продукта для мониторинга, две системы CI или отдельные инструменты для логов и оповещений могут казаться безобидными, потому что каждый счёт по отдельности небольшой. Но вместе они тормозят команду и понемногу съедают бюджет. Поэтому консультанты вроде Oleg Sotnikov на oleg.is часто советуют командам lean-стек с меньшим количеством пересекающихся инструментов и более понятной ответственностью.

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

Ошибки, которые искажают потребность в людях

Основатели часто нанимают под желаемую скорость, а не под работу, которую можно измерить. Так команда, которая должна была начать с двух человек, превращается в план на пять. И так же один человек оказывается с нагрузкой, которая уходит в ночи и выходные.

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

Средний результат тоже вводит в заблуждение. Если агент пишет чистый код 8 раз из 10, бюджет всё равно может сломаться из-за оставшихся 2 случаев. Команды не чувствуют боль от среднего качества. Они чувствуют её от плохих случаев, которые вызывают переделки, срыв сроков и проблемы у клиентов.

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

Ещё один распространённый миф — что один очень сильный инженер убирает необходимость проверки. Это почти никогда не так. Опытный специалист может сократить время на проверку, но не убрать его. Результаты ИИ всё равно нужно проверять на крайние случаи, проблемы безопасности, недостающие тесты и просто странное поведение. Иногда более сильные инженеры тратят даже больше времени на проверку, потому что замечают то, что другие пропустили бы.

Есть и потери времени, которые вообще не попадают в таблицу: повторные попытки модели после слабого ответа, ожидание заблокированных задач, простои инструментов и ручные исправления после нестабильной автоматизации. Эти часы реальны, считаете вы их или нет.

Маленькие ИИ-first команды обычно остаются маленькими только тогда, когда закладывают бюджет на исключения, а не только на хороший сценарий. Если ваш план работает только пока ничего не ломается, значит, количество людей посчитано неправильно.

Краткая проверка бюджета перед наймом

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

Начните с самих статей расходов. Если вы не можете объяснить каждую строку одним простым предложением, скорее всего, это просто догадка. «Использование модели для генерации кода», «5 часов в неделю на проверку» и «хостинг для тестовых окружений» — понятно. «AI ops» и «дополнительные инструменты» — нет. Хороший бюджет читается как простой чек.

Затем оценивайте не только успех, но и сбои. Основатели часто закладывают бюджет под чистый путь, где модель пишет неплохой код, тесты проходят, и кто-то быстро всё утверждает. Реальная работа куда сложнее. Часть результатов не проходит. Часть промптов приходится запускать второй раз. Часть изменений затрагивает billing, авторизацию или миграции и требует гораздо больше времени на проверку.

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

Краткая проверка должна ответить на пять вопросов:

• Можете ли вы объяснить каждую статью без расплывчатых слов?
• Учли ли вы повторные попытки, неудачные результаты и ручную доработку?
• Работает ли модель при сложной неделе?
• Сможет ли один проверяющий справляться, не став узким местом?
• Если в следующем месяце нагрузка удвоится, сойдутся ли цифры?

Вопрос про проверяющего важнее, чем думают многие основатели. Один человек может проверять удивительно большой объём ИИ-результатов, если задачи маленькие и похожие. Но тот же человек очень быстро становится узким местом, когда работа расползается на продукт, инфраструктуру, безопасность и клиентские проблемы. Если проверки задерживаются хотя бы на один день, тормозится вся команда.

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

Что делать дальше, если цифры всё ещё неясны

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

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

Месяца обычно достаточно, чтобы увидеть закономерности. Идеальные данные с первого дня не нужны. Нужна стабильность. Если пять похожих задач показывают время проверки от 12 до 18 минут, это полезно. Если одна задача заняла два часа, потому что промпт трижды сработал плохо, это тоже нужно записать.

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

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

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