FRONTIER VS ДЕШËВЫЕ МОДЕЛИ

Когда я начал погружаться в вайбкодинг, возник вопрос: нужно ли рвать жопу, чтобы всегда и всё делать на самой крутой модели? На первый взгляд ответ очевиден: frontier-модель лучше рассуждает и иногда одним prompt заменяет половину orchestration. Значит, можно выкинуть лишний harness, отдать ей задачу и пойти пить кофе. Меня смущает, что наш основной технологический процесс (а software engineering им является) внезапно становится набором надежд на хорошее настроение модели. Если хотите, позже расскажу как работают LLM, но пока договоримся, что мы понимаем, что она выдает вероятностные, а не правильные ответы

Если этапы workflow можно определить формально, они должны жить в коде. Когда обязателен review, какие поля нужно заполнить, какой budget нельзя превышать и что проверить перед deployment - это инварианты системы, а не вопрос вкуса LLM. Просить модель каждый раз придумывать ваш бизнес-процесс примерно как позволить стажёру перед каждым релизом импровизировать регламент выкладки.

Модели стоит оставлять эвристики: практические способы искать решение, когда данных мало или вариантов слишком много. Например, предположить причину бага, выбрать, какой файл изучить первым, или заметить подозрительное место в коде. Это обоснованные догадки, которые помогают двигаться дальше, но не гарантируют правильного результата. "Без пройденных тестов не мержим" - инвариант, который обеспечивает код. "Похоже, сломалось из-за кеша, проверим его первым" - эвристика, которую предлагает модель. Так LLM остаётся заменяемым компонентом: сегодня GPT, завтра Claude или Qwen, а правила процесса не приходится перепридумывать под характер каждой из них.

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

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

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

Так вот, вернёмся к стабильности. Без собственных evals легко принять пару удачных ответов за улучшение, а потом ловить странную херню в production. Модели будут меняться каждый месяц, но ваши инварианты, тесты и измеримый набор задач должны жить дольше. Иначе это не AI engineering, а дегустация чат-ботов по настроению.

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

AI Для Задротов