Один из авторов Habr описал рабочую схему распределения задач между несколькими языковыми моделями — и объяснил, почему вопрос «какая модель лучше» давно устарел. Нужный вопрос звучит иначе: какая модель должна делать эту задачу, с этим контекстом, сегодня?
Поведение модели меняется вместе с продуктом. Название в меню остаётся тем же, но ассистент за ним уже другой: одно обновление делает модель сильнее в планировании и слабее в редактировании, другое — аккуратнее с кодом, но многословнее в обычном разговоре. Это не баг, а свойство продуктового цикла: каждый релиз приносит новое обучение, новые правила безопасности и новый «вкус» компании.
| Модель | Основные задачи | Типичный сбой |
|---|---|---|
| Codex | Работа с репозиторием, ремонт тестов, узкие патчи, локальные инструкции | Может быть слишком сдержан там, где нужна более широкая переработка |
| Claude | Быстрая реализация при жёстко заданных рамках | Строит лишнее: трёхстрочный патч превращается в новый модуль |
| Gemini | Архитектура, продуктовое направление, разбор компромиссов до кода | Может остаться слишком далеко от файлов |
| Kimi | Второе мнение, черновая стратегия, широкое рассуждение | Менее отполирован, не так чист на финише |
| Локальные модели | Личные заметки, дешёвые черновики, классификация, приватные задачи | Слабее в ревью кода по сравнению с облачными моделями |
Автор выработал простое правило распределения. Codex получает работу с репозиторием: ремонт тестов, узкие патчи, задачи, где важны локальные инструкции. Он сдержан — чаще сохраняет форму проекта и делает небольшое полезное изменение. В зрелой кодовой базе это ценно: самая трудная часть часто не в том, чтобы написать код, а в том, чтобы не написать лишний.
Claude быстро берётся писать код — трёхстрочное исправление может вырасти в новый модуль и переписанные тесты.
Claude получает быструю реализацию, когда рамки уже жёстко заданы. Проблема в том, что он слишком охотно берётся писать: исправление на три строки может стать хелпером, потом новым модулем, потом переписанным тестом. Иногда такая энергия полезна, чаще — это просто новая площадь для обслуживания.
Gemini получает архитектуру, продуктовое направление и разбор компромиссов до начала правки кода. Автор не всегда хочет запускать его первым внутри грязного репозитория, но часто хочет услышать его до начала работы: Gemini лучше помогает понять, что это за проблема — баг, непринятое продуктовое решение, плохая абстракция или тест, который проверяет не то.
Kimi оказался неожиданно полезным. Он менее отполирован, чем Codex, и не так чист на финише, но в широком рассуждении не сильно отстаёт от Gemini. Поэтому он ценен как второе мнение — особенно когда первый ответ звучит слишком гладко.
Практический приём — отделить планирование от исполнения. Сначала Gemini или Kimi определяют проблему и риски. Потом Codex или Claude вносят изменение. После патча результат уходит на ревью другой модели. Ревьюер не переписывает работу — он ищет баги, пропущенные тесты, слишком широкие изменения и места, где реализация не совпадает с исходной целью. Промпт для ревью должен быть прямым: не «это хорошо?», а «какой файл изменился сильнее, чем нужно» и «какое допущение не доказано».
Автор рекомендует вести простую таблицу с пятью полями: модель, задача, цена, результат и потребовался ли второй проход. После десяти задач рисунок обычно виден — возможно, Claude двигался быстрее всех, но дважды построил лишнее, а Codex исправлял тесты меньшим числом правок.
Проблема цены реальна. Работа с несколькими моделями быстро дорожает: платные аккаунты, кредиты API, лимиты запросов и корпоративные планы превращают лучший процесс в то, что многие не могут себе позволить. Именно поэтому китайские провайдеры и модели с открытыми весами важны — они давят на цены и делают локальные процессы реальнее. Локальные модели с открытыми весами закрывают личные заметки, дешёвые черновики, простую классификацию и задачи, где цена важнее качества.
Отдельный раздел посвящён тексту. Код можно запустить, тесты могут упасть, тайпчекер скажет, что утверждение о функции неверно. У прозы другие отказы: абзац может быть грамматически чистым и при этом мёртвым. Автор советует держать ИИ в роли клерка или критика — разобрать заметки, оспорить план, найти слабые утверждения. Не отдавать ему роль автора. Чем больше финального голоса передаётся модели, тем сильнее текст перенимает её привычки: мягкую нейтральность, фальшивые концовки, ровный ритм и общие фразы.
Для команд следующий шаг — политика: какие задачи можно отдавать локальным моделям, какие промпты могут содержать данные клиентов, какая модель имеет право редактировать продакшен-код, а какая — только проверять. Каждый ответ на эти вопросы меняет счёт, риск для приватности или нагрузку на ревью.
