Ваш агент-программист платит по тарифам frontier-моделей за вопросы с вариантами ответов.
Какие заметки подгрузить? Отправить этот шаг большой модели или маленькой? Инструмент упал — повторить, починить или сдаться? Какие тесты запустить первыми?
Каждый из этих вопросов подразумевает четыре-пять возможных ответов. И в большинстве современных агентов на каждый из них отвечает самая дорогая модель, которая у вас есть: с включенным режимом рассуждений, чтением всего контекста и написанием целого абзаца перед тем, как принять решение.
Вот где утекают деньги.
В этой статье я покажу, как её устранить. Opus 5.5 оставляет сложную работу: планирование, написание кода, отладку. Jev забирает на себя те четыре решения, которые нужно принимать почти на каждом шаге. А ваша обвязка (harness) готовит варианты, проверяет ответы и принимает финальное решение.
В разобранном ниже примере стоимость одной сессии разработки фичи падает с $6.42 до $2.00. Это на 69% дешевле, причём каждая строчка расчётов приведена в статье — вы легко сможете подставить свои цифры.
Статья написана для всех, кто запускает агента-программиста на реальных задачах: будь то Claude Code, собственная обвязка поверх API или что-то среднее. Переписывать агента не придётся. Каждый элемент из статьи встраивается в существующий цикл как обычный вызов функции с флагом для отключения. Если вы читали мою статью про Jev + Claude Code, считайте это обновлённой версией: та же идея, но с более свежей reasoning-моделью и четырьмя конкретными точками принятия решений вместо общего принципа.
Вам понадобятся API-ключ Jev, API-ключ Anthropic и примерно неделя логов вашего собственного агента, чтобы было с чем сравнивать.
Поехали.
opus думает, jev решает.
Проблема: одна модель делает две разные работы
Понаблюдайте за работой агента-программиста минут десять, и вы увидите, что он выполняет два совершенно разных типа задач.
Первая работа — рассуждать. Спланировать фичу. Написать функцию. Прочитать стек-трейс и понять, почему парсер дат ломается в високосный год. Эта работа не имеет чётких границ. Ответа нет в списке. Здесь нужна самая умная модель, которую вы можете себе позволить, и Opus 5.5 справляется с этим отлично.
Вторая работа — принимать решения. Выбрать три важные проектные заметки из сорока. Решить, что переименование можно отдать дешёвой модели. Выбрать, что делать после таймаута npm test. Определить, какие 12 тестовых файлов прогнать до запуска всех 1400. Эти ответы уже есть в списке. Список короткий. И ваш код может сразу использовать ответ.
Большинство агентов прогоняют обе задачи через одну модель просто потому, что так настроено по умолчанию. Цикл вызывает Opus, Opus думает, Opus отвечает, цикл продолжается.
Это работает. Но это медленно и дорого — причём так незаметно, что легко упустить. По отдельности вызовы для принятия решений не выглядят затратными. Один запрос «какие заметки мне нужны» стоит, может быть, цент. Но он происходит на каждом шаге и каждый раз тащит за собой весь контекст.
И есть вторая статья расходов, которую заметить ещё сложнее: когда агент не может решить, что именно загружать, он грузит всё. Каждая проектная заметка, каждый документ о соглашениях, каждое прошлое решение впихивается в каждый вызов. Opus 5.5 сделал чтение из кэша дешёвым — $0.20 за миллион токенов, — но «дёшево × шестьдесят шагов × вся папка с заметками» всё равно складывается в приличную сумму.
Решение: Opus рассуждает, Jev решает, ваша обвязка управляет
Jev — это модель от TypeSafe, созданная ровно для второй работы. Она не пишет текст. Вы даёте ей контекст и типизированные вопросы с фиксированным набором вариантов, а она возвращает вероятность для каждого из них. Ответ приходит за миллисекунды, вход стоит $0.042 за миллион токенов, а выход вообще бесплатный.
Архитектура получается предельно простой:
Opus 5.5 занимается рассуждениями. Планирование, код, отладка — всё, где ответа нет в готовом списке.
Jev принимает мелкие решения. Он выбирает из вариантов, которые подготовила ваша обвязка.
Ваша обвязка остаётся главной. Она формирует списки вариантов, читает вероятности, применяет пороги и откатывается на Opus, если Jev сомневается.
Третий пункт обычно пропускают, а ведь именно он делает всю систему безопасной. Jev никогда не придумывает варианты. Jev никогда не получает последнего слова в том, что нельзя отменить. Ваш код сам решает, что значит «достаточно уверен».
Вот хелпер, на котором построено всё остальное в этой статье:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Подключите сюда ваш Jev-клиент: TypeSafe SDK, Vercel AI Gateway
или пакет LangChain. Он должен возвращать {вариант: вероятность}
для каждого переданного варианта.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Обратите внимание, чего здесь нет: мы не спрашиваем Jev, насколько он уверен. Мы просто читаем возвращённую вероятность. Вопрос «ты уверен?» любой модели почти всегда даёт ответ «да». Вероятность — вот честный сигнал.
А теперь перейдём к четырём решениям.
четыре решения внутри шага агента
Решение 1: выбрать нужные проектные заметки до загрузки контекста
Это самый мощный рычаг, который при этом почти никто не использует.
У вашего агента есть папка с заметками. AGENTS.md, архитектурные документы, соглашения, прошлые решения, предупреждения вроде «никогда не трогай модуль биллинга без миграции». Тысяч на 30 000 токенов. Большинство агентов грузят всё это в каждом вызове, потому что никто не хочет оказаться тем, кто забыл важную заметку.
Поэтому вместо загрузки всего подряд задайте Jev простой вопрос по каждой заметке, причём параллельно: нужна ли агенту эта заметка для текущей задачи?
Сначала разбейте заметки на куски по заголовкам. Каждый раздел AGENTS.md становится отдельным чанком. Каждый архитектурный документ — одним или несколькими чанками.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Затем оцените каждый чанк применительно к текущей задаче:
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Здесь важны три детали.
Всегда загружайте то, что не обсуждается. Некоторые заметки должны быть в каждом вызове при любых условиях: правила безопасности, «никогда не делай force push», строчка с указанием, какая база данных является продом. Пометьте их тегом always и не тратьте время на их оценку.
Держите нижний порог и запасной план. Если ничего не преодолело порог 0.55, всё равно загрузите топ-2. Агент вообще без контекста хуже, чем агент с чуть избыточным контекстом.
Логируйте то, что отсеяли. Когда агент ошибается, первое, что вы проверяете — не была ли отсеяна заметка, которая предотвратила бы ошибку. Именно по этому логу вы будете настраивать параметры keep и floor.
В нашем примере одно только это изменение сокращает объём заметок в каждом вызове с 30 000 до 6 000 токенов. Само по себе это снижает стоимость сессии примерно на 24%.
Решение 2: маршрутизировать подходящие задачи на быстрый воркер
Не каждому шагу нужен Opus.
Переименование функции в восьми файлах — не нужен. Добавление поля в форму, где уже есть девять точно таких же полей — не нужно. Обновление пути импорта — не нужно. Это правки, которые следуют паттерну, уже существующему в кодовой базе.
Поэтому перед выполнением каждого шага Jev классифицирует его, а ваша обвязка маппит класс на воркер:
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Посмотрите, как сформулированы варианты. Это не «легко» и «сложно», и уж точно не «справится ли маленькая модель?». Это конкретные виды работ, которые ваш код может превратить в действие. Это правило для любого вопроса к Jev: каждый вариант должен быть чем-то, с чем ваша обвязка знает, что делать.
И обратите внимание на поведение по умолчанию. При вероятности ниже 0.8 шаг уходит в Opus. Ошибки маршрутизации здесь работают только в одну сторону: сложная задача, отправленная быстрому воркеру, обойдётся вам в сломанный шаг и повтор, а лёгкая задача, ушедшая в Opus, — лишь в небольшие переплаты. Так что при сомнениях отправляйте наверх.
В качестве быстрого воркера я использую Haiku 4.5: $1 за миллион токенов на входе и $5 на выходе. В разбираемом примере 12 из 36 шагов реальной работы уходят ему.
Решение 3: выбрать путь восстановления при падении инструмента
Инструменты падают постоянно. Тесты падают по таймауту. Путь к файлу неверный. Пакет не установлен. Shell-команда ловит ошибку прав доступа. Линтер ругается на что-то постороннее.
Большинство агентов решают это самым дорогим способом из возможных: они скармливают всю ошибку обратно большой модели и дают ей подумать, что делать. Иногда это оправданно. Но часто ответ очевиден, и Opus тратит 1500 токенов, чтобы заново открыть для себя, что ENOENT означает отсутствие файла.
Что ещё хуже, агенты залипают в циклах. Повтор, ошибка, повтор, ошибка — и за каждый шаг оплата полного цикла рассуждений.
Поэтому отдайте ошибку Jev вместе с фиксированным набором путей восстановления:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # последние n символов ошибки
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # нестабильная сеть или таймаут3 "retry_after_install", # отсутствует пакет или инструмент4 "fix_path_and_retry", # неверный путь к файлу или cwd5 "switch_tool", # этот инструмент не справится, другой сможет6 "escalate_to_opus", # нужна настоящая отладка7 "stop_and_report", # нужен человек8]
Жёсткий лимит попыток живёт в коде, а не в модели. Ни одной модели, какой бы дешёвой она ни была, нельзя позволять повторять попытки бесконечно.
Каждый путь восстановления маппится на небольшую функцию в вашей обвязке. retry_after_install вытаскивает название отсутствующего пакета из ошибки регуляркой и устанавливает его. fix_path_and_retry проверяет существующие пути и предлагает ближайший подходящий. Реальные деньги тратит только escalate_to_opus, и срабатывает он лишь тогда, когда ошибка действительно требует размышлений.
В разбираемом примере это убирает из сессии 6 пустых шагов с повторами.
Решение 4: запускать точечные проверки перед полным набором тестов
Этот приём экономит скорее время, чем деньги, а именно время создаёт ощущение, что агент работает быстро.
После каждого изменения большинство агентов прогоняют весь набор тестов. Если ваш suite выполняется четыре минуты, агент будет тратить четыре минуты на ожидание после каждой правки, а затем читать сотни строк вывода в поисках того самого падения, которое имеет значение.
Решение строится по тому же паттерну, что и с заметками: оцените каждый тестовый файл относительно диффа, запустите сначала самые релевантные, а полный набор прогоняйте только если точечные проверки прошли успешно.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # фейлимся быстро, чиним до всего остального18 return run_tests(test_files) # полный набор всё равно блокирует коммит
Перечитайте последнюю строчку дважды. Полный набор тестов всё равно прогоняется до того, как что-либо попадёт в коммит. Точечные проверки — это система раннего оповещения, а не замена. Вы ловите большинство поломок за секунды, а не за минуты, и при этом никогда не выкатите то, что поймал бы полный suite.
Сначала добавьте и дешёвые проверки: проверку типов и линтинг только для изменённых файлов. Они занимают секунду и ловят удивительно большую долю ошибок ещё до запуска любых тестов.
Собираем всё вместе: цикл обвязки
Вот как эти четыре решения укладываются в один шаг цикла:
def run_step(task: str, step: str, state):
1. контекст: загружаем только те заметки, которые нужны этому шагу
notes = state.always_notes + pick_notes(step, state.notes)
2. маршрутизация: выбираем воркер для этого шага
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. восстановление: обрабатываем любые падения инструментов на этом шаге
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. проверки: сначала точечные тесты, полный набор перед коммитом
if result.diff:
state.log_check(check(result.diff, state.test_files))
А вот сторона Opus: это просто ваш обычный вызов Opus 5.5. Ставьте стабильный контекст первым (системный промпт, определения инструментов, заметки с тегом «always»), чтобы он оставался в кэше между шагами, а специфичные для шага материалы — в конец.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # id вашей модели Opus 5.5
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Никакой экзотики. Экономия берётся не из хитрого промпта, а из того, что вы перестаёте туда отправлять.
Один шаг под микроскопом
Вот как выглядит один шаг в логах, когда все четыре решения уже работают. Задача: добавить rate limiting на публичный эндпоинт регистрации. Этот трейс иллюстративный, но именно такую картину вы увидите в своих логах.
step 14 "add a per IP rate limit to POST /signup"
[notes] параллельно оценено 41 чанков
оставлено: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
отсеяно: 37 чанков, включая биллинг, шаблоны писем, CI
[route] new_logic (0.91) → opus
[opus] планирует изменение, пишет middleware + конфиг + правку обработчика
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, перезапуск
[checks] проверка типов изменённых файлов: pass
точечные тесты (12 из 1388): pass
полный набор: pass
Пройдитесь по нему сверху вниз и посчитайте, сколько из этих строк раньше требовали полноценного вызова Opus. Выбор заметок: один огромный вызов, либо никакого выбора и 30 000 токенов заметок, загруженных вслепую. Маршрутизация: ничего, каждый шаг шёл в Opus. Отсутствующий пакет: полноценный шаг рассуждений, чтобы выяснить, что отсутствующий модуль означает «установи модуль». Выбор тестов: ничего, полный набор после каждой правки.
Теперь в этом трейсе только одна строка — Opus, и это та самая строка, которой действительно нужна frontier-модель: планирование и написание rate limiter'а.
В этом и заключается вся суть. Дорогая модель тратит время только на ту часть работы, которую кроме неё никто не сделает.
Разбор примера: откуда берутся 69%
Вот полная математика для одной сессии разработки фичи: 60 шагов агента плюс 6 пустых повторов, которые типичный агент набирает по ходу дела. Все цены — актуальные публичные прайс-листы.
До: Opus 5.5 делает всё
Каждый шаг загружает 70 000 токенов контекста: 15 000 на системный промпт и инструменты, 30 000 на всю папку с заметками и 25 000 на историю диалога. Предположим, что 80% из этого попадает в кэш. Каждый шаг генерирует около 1500 токенов на выходе, потому что режим рассуждений в Opus 5.5 включён всегда.
cache reads: 56,000 × $0.20/M = $0.0112
fresh input: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
per step = $0.0972
66 steps × $0.0972 = $6.42
После: слой принятия решений
Контекст падает до 46 000 токенов на шаг, потому что Jev выбирает 6 000 токенов заметок вместо загрузки всех 30 000. 24 чисто «решательных» шага переходят на Jev. 6 циклов повторов исчезают. А 12 из оставшихся 36 рабочих шагов уходят в Haiku 4.5.
Opus 5.5: 24 steps × $0.0742 = $1.78
Haiku 4.5: 12 steps × $0.0169 = $0.20
Jev: 102 calls × 5,000 tokens
× $0.042/M, output free = $0.02
total = $2.00
С $6.42 до $2.00. Это на 68.8% дешевле за ту же самую фичу.
порог определяется ценой ошибки
А вот вклад каждого рычага, сложенный по порядку:
notes selection only $4.89 23.7% saved
- decisions moved to Jev $3.13 51.2% saved
- recovery paths $2.69 58.1% saved
- routing to a fast worker $2.00 68.8% saved
Два честных замечания об этих расчётах.
Во-первых, это смоделированные цифры, построенные на явных допущениях, а не замер вашего стека. Размер вашего контекста, процент попаданий в кэш и количество решений будут другими. Смысл приводить каждую строчку в том, чтобы вы могли подставить свои числа. Как только замерите реальное «до» и «после», используйте свои цифры, а не мои.
Во-вторых, посмотрите, куда реально уходят деньги. 102 вызова Jev стоят в сумме два цента. Экономия берётся не из того, что Jev дешёвый за вызов. Она берётся из всего того, что перестаёт происходить, когда решение принимает Jev: раздутый контекст, полные шаги рассуждений для вопросов с вариантами ответов, циклы повторов и вызовы большой модели для переименований.
Почему просто не взять Haiku для решений?
Справедливый вопрос. Haiku 4.5 дешёвый и быстрый. Зачем вообще добавлять новую модель?
Три причины.
Он всё ещё пишет текст. Haiku отвечает текстом. Вам нужно просить его отвечать одним из ваших вариантов, затем парсить ответ, а потом обрабатывать случаи, когда он добавляет пояснения, выбирает то, чего нет в списке, или заворачивает ответ в предложение. Jev возвращает вероятность для каждого переданного вами варианта. Парсить нечего, и вариантов вне списка не бывает.
Вы получаете полное распределение, а не просто ответ. Когда Jev говорит needed: 0.52, not_needed: 0.48, вы понимаете, что это подбрасывание монетки, и ваша обвязка может эскалировать задачу. Когда текстовая модель говорит «needed», вы понятия не имеете, была ли она уверена. Пороги работают только тогда, когда вы видите вероятности.
Математика стоимости другая. Выход у Jev бесплатный, а вход — $0.042 за миллион токенов. Оценка 41 чанка заметок на каждом шаге означает 41 мелкий вызов на шаг. С Jev это доли цента. С любой текстовой моделью, даже дешёвой, это 41 генерация со своей стоимостью выхода и задержкой.
Используйте Haiku для мелких правок, где ему реально нужно писать код. Используйте Jev для выбора из списков. Используйте Opus для размышлений. Пусть каждая модель делает то, для чего создана.
Как внедрить это и ничего не сломать
Не включайте все четыре решения разом. Вот порядок, который я бы использовал.
Неделя 1: теневой режим. Оставьте текущего агента как есть. Для каждого решения, которое он принимает, задавайте тот же вопрос Jev и логируйте оба ответа плюс вероятность от Jev. Вообще не реагируйте на ответы Jev.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Неделя 2: разбор расхождений. Смотрите только на те строки, где Jev и ваш текущий агент разошлись во мнениях. Отсортируйте их по вероятности Jev. Обычно вы найдёте чёткую границу: выше определённой вероятности Jev прав примерно так же часто, как Opus. Эта граница и есть ваш порог. А строки с расхождениями бесплатно становятся вашим тестовым набором, собранным на реальном трафике.
Неделя 3: включаем выбор заметок. Это самый мощный рычаг, и его проще всего откатить, поскольку пропущенная заметка очень быстро проявляется в логах.
Неделя 4: включаем восстановление и тесты. У обоих есть жёсткие лимиты и запасные пути в коде, так что худшее, что случится — откат к тому, что вы делаете сейчас.
Последней — маршрутизация. Ошибки маршрутизации заметнее всего для пользователей, потому что сложная задача, отправленная быстрому воркеру, выдаёт плохой код. Включайте её последней, с консервативным порогом, и следите за процентом падений на шагах быстрого воркера.
Выводите каждое решение под on/off-флаг, чтобы можно было отключить его одной строчкой.
Настройка порогов по уровню риска
Единый порог для всего — ошибка. Настраивайте их исходя из того, что произойдёт при неверном ответе.
Одна сессия разработки фичи, тот же результат: с $6.42 до $2.00
Низкие ставки, легко отменить: от 0.55 до 0.65. Выбор заметок. Порядок тестов. Неверный ответ стоит немного лишнего контекста или пары секунд.
Средние ставки: 0.8. Маршрутизация и восстановление. Неверный ответ стоит сломанного шага, который ваша обвязка поймает.
Высокие ставки, сложно отменить: 0.9 или никогда. Удаление файлов. Force push. Изменение прод-конфига. Запуск миграции. Мой честный совет: не позволяйте ни одной модели принимать такие решения в одиночку. Отправляйте их человеку или, как минимум, в Opus с шагом подтверждения.
Всё, что ниже порога, идёт по эскалации: в Opus, если нужны рассуждения, или человеку, если нужна оценка ситуации.
Где это не поможет
Эта архитектура — не волшебный множитель для любой нагрузки.
Чистая генерация почти не меняется. Если ваш агент большую часть времени пишет большие объёмы нового кода по чёткому ТЗ, переносить особо нечего. Экономию на выборе заметок вы получите, но не более.
Крошечным проектам это не нужно. Если вся ваша папка с заметками — это 2000 токенов, а тесты прогоняются за восемь секунд, накладные расходы на создание такой системы пока не окупятся.
Jev не очень хорош в принятии финальных решений в одиночку. Он отлично замечает детали и выбирает из короткого списка. Но это не та модель, которой стоит задавать вопрос «готов ли этот pull request к мёрджу?» как единственную задачу. Разбивайте большие вопросы на мелкие, оценивайте каждый и комбинируйте результаты в своём коде с собственными весами.
Если у вас уже есть размеченные данные для фиксированного вопроса, маленькая self-hosted модель может обойти Jev по цене. Jev сияет там, где вопросы постоянно меняются и нет обучающей выборки, а это описание подходит большинству агентов-программистов.
Ошибки, которых я бы избегал
Позволить модели составлять список вариантов. Вся архитектура держится на вариантах, с которыми ваш код умеет работать. Если варианты генерирует модель, вы возвращаетесь к парсингу свободного текста.
Спрашивать Jev, уверен ли он. Вместо этого читайте вероятность. Самооценка почти всегда равна «да».
Отсутствие запасного пути. Каждому решению Jev нужен маршрут для случая «не уверен», и этот маршрут — Opus или человек, но никогда не догадка.
Лимиты повторов в промпте, а не в коде. Модель, которой сказали «повторяй не больше 3 раз», иногда будет повторять 30 раз. Код — нет.
Отказ от полного набора тестов. Точечные проверки ускоряют вас. Полный набор держит вас в рамках. Оставьте и то, и другое.
Измерять пустоту. Если вы не зафиксируете стоимость сессии до старта, то никогда не узнаете, сэкономили ли вы 20% или 70%. Сначала соберите статистику использования за неделю обычной работы. Это займет десять минут, но это единственная цифра, которая действительно имеет значение.
Что сделать на этой неделе
Вот весь план в виде чек-листа:
- Зафиксируйте одну неделю работы сессий агента: шаги, токены, затраты, ошибки.
- Найдите решения, спрятанные внутри вашего цикла: заметки, маршрутизацию, восстановление, тесты.
- Сформулируйте каждое из них как вопрос с фиксированным списком вариантов ответа.
- Запустите Jev в теневом режиме параллельно с вашим текущим агентом на неделю.
- Установите пороговые значения на основе журнала расхождений, ориентируясь на уровень риска.
- Сначала включите выбор заметок, затем восстановление и тесты, а после — маршрутизацию.
- Сравните стоимость сессии «до» и «после». Это и есть ваша главная метрика.
Opus 5.5 — лучшая модель для рассуждений о коде из всех, что я использовал. Ошибка — заставлять её делать вообще всё остальное.
Позвольте ей думать. Позвольте Jev принимать решения. А ваш код пусть управляет всем процессом.
Если материал был полезен, подписывайтесь на @cyrilXBT. Каждую неделю я разбираю, как разрабатывать продукты на базе новейших AI-моделей, и показываю реальные цифры.
Добавьте статью в закладки, чтобы она была под рукой, когда вы начнете разработку.
