Использование двух моделей ИИ для одной задачи без пустых расходов

Почему одна модель на все шаги — это трата денег

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

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

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

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

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

Вам не нужен огромный стек или сложный оркестратор. Для многих команд первый полезный сплит прост: более сильная модель планирует и проверяет, а более дешёвая пишет первый черновик. В AI-first наборах, которые Oleg Sotnikov строит для клиентов, такой роутинг часто экономит расходы ещё до того, как команда меняет остальную часть процесса.

Что должна делать каждая модель

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

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

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

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

Верификация тоже заслуживает сильную модель, когда ошибка дорого обходится. Сюда входят изменения в auth, биллинге, миграции данных, конкурентности, правах доступа и всё, что может тихо нарушить продакшн. Хорошая верификация требует рассуждений больше, чем скорости печати. Модель должна сравнить код с планом, проверить, доказывают ли тесты поведение, и задать вопрос: "Что это изменение могло сломать, о чём никто не подумал?"

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

Простой сплит, который работает на практике

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

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

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

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

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

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

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

Как настроить: пошагово

Начните с одной задачи, достаточно маленькой, чтобы завершить за день или два. Хорошие примеры: добавить CSV-экспорт, починить баг с ретраями или написать тесты для одного эндпоинта. Если тестировать это на огромной фиче, вы не поймёте, провалился ли сплит или задача просто была слишком большой.

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

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

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

Простой пример делает это понятнее. Допустим задача — "добавить CSV-экспорт на страницу админа пользователей." Планер решает, где разместить кнопку, какие изменения маршрутов нужны, какие права важны и какие тесты добавить. Черновик пишет код по этому плану. Ревьюер проверяет, уважает ли экспорт фильтры, корректно ли обрабатывает пустые результаты и возвращает ли нужные колонки.

Отслеживайте одни и те же показатели при каждом запуске потока:

• общая стоимость
• общее время
• количество переделок
• комментарии ревью, найденные до мёржа
• дефекты, обнаруженные после мёржа

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

Пример: от запроса фичи до ревью

Возьмём небольшое изменение API: продуктовая команда хочет фильтр archived в списке проектов. Сейчас GET /projects возвращает только активные элементы. Саппорт постоянно получает тикеты от админов, которым нужно найти старые проекты, не лазая в базу.

Это хороший тест: задача маленькая, легко проверяется и повторяема. Одна сильная модель занимается планированием и ревью. Одна лёгкая модель пишет первый черновик кода и тестов.

Планер получает запрос, краткую заметку о текущем эндпоинте и правила кодирования. Он должен вернуть список задач и acceptance checks, без кода. Пример плана:

• Добавить опциональный query-параметр archived к GET /projects
• Сохранить текущее поведение, если параметр отсутствует
• Принимать true и false, отвергать другие значения
• Обновить запрос так, чтобы фильтрация шла на уровне базы данных
• Добавить тесты для поведения по умолчанию, archived=true, archived=false и неверного ввода

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

Теперь сильная модель возвращается для ревью. Она сравнивает черновик с планом и ищет пробелы. В этом примере она может поймать две распространённые ошибки.

Во-первых, черновик добавил фильтр, но забыл тест на случай отсутствия параметра, так что никто не доказал, что старые клиенты получают прежний результат. Во-вторых, черновик принял любую строку и трактовал неизвестные значения как false, что скрывает некорректные запросы вместо их отклонения.

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

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

Как понять, что сплит действительно помогает

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

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

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

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

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

Небольшая табличка достаточна для каждой завершённой задачи:

• Стоимость: общие токены и потраченные деньги на API за всю задачу
• Скорость: время от запроса до готовности к финальному человеческому одобрению
• Точность: число повторов, повторяющиеся комментарии ревью и минуты доработки

Держите оценку простой. Оценка от 1 до 5 работает, если команда использует её одинаково каждый раз. После 10–20 похожих задач паттерн станет очевиден.

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

Ошибки, которые быстро жрут бюджет

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

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

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

Часто это происходит на мелких задачах. Модель находит один стильный недочёт, переписывает половину модуля, создаёт новые различия и запускает ещё одно ревью. Теперь вы платите за хвостовик, а не за прогресс.

Большая часть расточительства идёт от нескольких привычек:

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

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

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

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

Быстрая проверка перед внедрением

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

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

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

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

Используйте короткий чеклист:

• Сделал ли план объём достаточно понятным для быстрого человеческого одобрения?
• Удержался ли черновик в пределах этого объёма?
• Поймало ли ревью реальные риски, крайние случаи и пробелы в тестах?
• Записали ли вы общую стоимость и общее время для всего прогона, включая повторы и доработки?
• Доверил бы человек финальному результату после одного внимательного чтения?

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

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

Если результат всё ещё шумный или ненадёжный, сначала улучшите шаблон плана. Лучшее планирование обычно экономит больше, чем очередная смена моделей.

Следующие шаги для вашей команды

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

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

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

Простой план испытания:

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

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

Команды часто усложняют этот этап. Вам не нужен сложный роутер, большая панель или шесть моделей, спорящих между собой. Маленький скрипт и таблица — достаточно, чтобы понять, снижает ли сплит реальные затраты.

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

Если команде нужна помощь в проектировании AI-first инженерного процесса, oleg.is — полезная отправная точка. Oleg Sotnikov работает как Fractional CTO и советник стартапов, помогая компаниям строить практичные AI-augmented рабочие процессы без лишних тулов.