Ваш агент для кодування платить ціни frontier-моделей за питання з варіантами відповідей.
Які нотатки мені завантажити? Цей крок має виконувати велика модель чи маленька? Інструмент щойно видав помилку. Повторити, виправити чи здатися? Які тести запустити першими?
Кожне з них — це питання з чотирма або п'ятьма можливими відповідями. І в більшості сучасних налаштувань агентів на кожне з них відповідає найдорожча модель, яка у вас є, з увімкненим мисленням: вона читає весь контекст і пише цілий абзац, перш ніж прийняти рішення.
Ось де витікають гроші.
У цій статті я покажу, як його заткнути. Opus 5.5 залишає собі складне мислення: планування, написання коду, налагодження. Jev бере на себе чотири рішення, які виникають майже на кожному кроці. А ваш harness (оболонка) готує варіанти, перевіряє відповіді та ухвалює остаточне рішення.
У практичному прикладі нижче вартість однієї сесії розробки фічі падає з $6.42 до $2.00. Це на 69% дешевше, і кожен рядок розрахунків є в цій статті, щоб ви могли підставити власні цифри.
Це написано для всіх, хто запускає агента для кодування на реальних задачах: Claude Code, власний harness через API або щось проміжне. Вам не потрібно переписувати свого агента. Кожен шматок із цієї статті вбудовується в наявний цикл як виклик функції з прапорцем, щоб його можна було вимкнути. Якщо ви читали мою статтю про Jev + Claude Code, то це оновлена версія: та сама ідея, новіша модель для міркувань і чотири конкретні рішення замість загального принципу.
Вам знадобляться ключ API Jev, ключ API Anthropic і приблизно тиждень логів вашого власного агента для порівняння.
Давайте це побудуємо.
opus міркує, jev вирішує.
Проблема: одна модель виконує дві роботи
Поспостерігайте за роботою агента для кодування десять хвилин, і ви побачите, що він виконує два абсолютно різні типи завдань.
Перша робота — це міркування. Планування фічі. Написання функції. Читання stack trace і пошук причини, чому парсер дат ламається у високосні роки. Ця робота не має чітких меж. Відповіді немає у списку. Тут вам потрібна найрозумніша модель, яку ви можете собі дозволити, і Opus 5.5 чудово з цим справляється.
Друга робота — це прийняття рішень. Вибрати три важливі нотатки проєкту з сорока. Вирішити, що перейменування можна віддати дешевій моделі. Обрати, що робити після таймауту npm test. Визначити, які 12 тестових файлів запустити перед повним прогоном усіх 1400. Ці відповіді є у списку. Список короткий. І ваш код може діяти на основі відповіді напряму.
Більшість агентів проганяють обидві роботи через одну й ту саму модель, бо так налаштовано за замовчуванням. Цикл викликає Opus, Opus думає, Opus відповідає, цикл продовжується.
Це працює. Але це ще й повільно та дорого так непомітно, що легко пропустити, бо окремі виклики для рішень не виглядають витратними. Один запит «які нотатки мені потрібні» коштує, мабуть, цент. Але він відбувається на кожному кроці, і щоразу тягне за собою весь контекст.
І є друга витрата, яку пропустити ще легше: коли агент не може вирішити, що завантажити, він завантажує все. Кожну нотатку проєкту, кожен документ про конвенції, кожне минуле рішення — усе запихається в кожен виклик. Opus 5.5 зробив читання кешу дешевим — $0.20 за мільйон токенів, але «дешево помножити на шістдесят кроків помножити на всю вашу папку з нотатками» все одно набігає в копійчину.
Рішення: Opus міркує, Jev вирішує, ваш Harness керує
Jev — це модель від TypeSafe, створена саме для другої роботи. Вона не пише текст. Ви даєте їй контекст і типізовані запитання з фіксованим набором варіантів, а вона повертає ймовірність для кожного з них. Вона відповідає за мілісекунди, вхідні дані коштують $0.042 за мільйон токенів, а вихідні — безкоштовні.
Завдяки цьому архітектуру дуже просто описати:
Opus 5.5 займається міркуваннями. Планування, код, налагодження — усе, де відповіді немає у списку.
Jev приймає дрібні рішення. Він обирає з варіантів, які підготував ваш harness.
Ваш harness залишається головним. Він формує списки варіантів, зчитує ймовірності, застосовує пороги та повертається до 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. Він має повертати {option: probability}
для кожного переданого вами варіанта.
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, ви все одно завантажуєте два верхніх. Агент із нульовим контекстом гірший за того, що має трохи забагато.
Логуйте те, що було відкинуто. Коли агент помиляється, перше, що ви перевіряєте — чи не була відфільтрована нотатка, яка б це запобігла. Саме цей лог допоможе вам налаштувати keep і floor.
У нашому прикладі лише ця зміна скорочує частку нотаток у кожному виклику з 30 000 до 6 000 токенів. Сама по собі вона зменшує вартість сесії приблизно на 24%.
Рішення 2: Маршрутизуйте відповідні задачі до швидшого виконавця
Не кожен крок потребує Opus.
Перейменування функції у восьми файлах — ні. Додавання поля у форму, де вже є дев'ять таких самих полів — ні. Оновлення шляху імпорту — ні. Це редагування, які повторюють патерн, що вже є в кодовій базі.
Тому перед виконанням кожного кроку Jev класифікує його, а ваш harness зіставляє клас із виконавцем:
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: кожен варіант має бути чимось, із чим ваш harness знає, що робити.
І зверніть увагу на значення за замовчуванням. Якщо ймовірність нижча за 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]
Жорстке обмеження спроб живе в коді, а не в моделі. Жодній моделі, якою б дешевою вона не була, не можна дозволяти повторювати спроби нескінченно.
Кожен шлях відновлення відповідає невеликій функції у вашому harness. retry_after_install витягує назву відсутнього пакунка з помилки через regex і встановлює його. fix_path_and_retry перевіряє наявні шляхи та пропонує найближчий збіг. Лише escalate_to_opus витрачає реальні гроші, і він спрацьовує тільки тоді, коли помилка дійсно потребує роздумів.
У нашому прикладі це прибирає 6 марних кроків повтору із сесії.
Рішення 4: Запускайте точкові перевірки перед повним набором тестів
Цей крок економить більше часу, ніж грошей, а саме час створює відчуття, що агент працює швидко.
Після кожної зміни більшість агентів проганяють весь набір тестів. Якщо ваш suite виконується чотири хвилини, ваш агент чекає чотири хвилини після кожного редагування, а потім читає сотні рядків виводу, шукаючи ту саму помилку, яка має значення.
Рішення використовує той самий патерн, що й для нотаток: оцініть кожен тестовий файл відносно diff, запустіть найрелевантніші першими, і проганяйте повний 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 все одно блокує коміт
Прочитайте останній рядок двічі. Повний suite все одно виконується перед тим, як щось потрапить у коміт. Точкові перевірки — це система раннього попередження, а не заміна. Ви ловите більшість поломок за секунди, а не хвилини, і ніколи не випускаєте те, що зловив би повний suite.
Також спершу додайте дешеві перевірки: type check і lint лише для змінених файлів. Вони займають секунду і ловлять напрочуд багато помилок ще до запуску будь-яких тестів.
Збираємо все разом: цикл Harness
Ось як ці чотири рішення вписуються в один крок циклу:
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. перевірки: спочатку точкові тести, повний suite перед комітом
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] scored 41 chunks in parallel
kept: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
dropped: 37 chunks, including billing, email templates, CI
[route] new_logic (0.91) → opus
[opus] plans the change, writes middleware + config + handler edit
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, rerun
[checks] typecheck changed files: pass
focused tests (12 of 1,388): pass
full suite: pass
Прочитайте це зверху вниз і порахуйте, скільки з цих рядків раніше були повноцінним викликом Opus. Вибір нотаток: один великий виклик, або взагалі без вибору і 30 000 токенів нотаток, завантажених наосліп. Маршрутизація: нічого, кожен крок ішов в Opus. Відсутній пакунок: повноцінний крок міркувань, щоб зрозуміти, що відсутній модуль означає «встанови модуль». Вибір тестів: нічого, повний suite після кожного редагування.
Тепер лише один рядок у цьому трейсі — це Opus, і це саме той рядок, який дійсно потребував frontier-моделі: планування та написання rate limiter.
У цьому й полягає вся ідея. Дорога модель витрачає час лише на ту частину роботи, яку може виконати тільки вона.
Практичний приклад: звідки беруться 69%
Ось повна математика для однієї сесії розробки фічі: 60 кроків агента плюс 6 марних повторів, які типовий агент накопичує по дорозі. Усі ціни — актуальні публічні прайси.
До: Opus 5.5 робить усе
Кожен крок завантажує 70 000 токенів контексту: 15 000 на системний промпт та інструменти, 30 000 на всю папку з нотатками і 25 000 на діалог. Припускаємо, що 80% із цього — cache hit. Кожен крок генерує близько 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
Два чесні зауваження щодо цих розрахунків.
По-перше, це змодельовані цифри, побудовані на явних припущеннях, а не вимірювання вашого стека. Розмір вашого контексту, відсоток cache hit і кількість рішень будуть іншими. Сенс показувати кожен рядок у тому, щоб ви могли підставити власні числа. Коли виміряєте реальне «до» і «після», використовуйте свої цифри, а не мої.
По-друге, подивіться, куди насправді йдуть гроші. 102 виклики Jev коштують загалом два центи. Економія береться не з того, що Jev дешевий за виклик. Вона береться з усього, що перестає відбуватися, щойно Jev приймає рішення: роздутий контекст, повноцінні кроки міркувань для питань із варіантами відповідей, цикли повторів і виклики великої моделі для задач перейменування.
Чому б просто не використати Haiku для рішень?
Справедливе запитання. Haiku 4.5 дешевий і швидкий. Навіщо взагалі додавати нову модель?
Три причини.
Він досі пише текст. Haiku відповідає текстом. Вам треба просити його відповідати одним із ваших варіантів, потім парсити відповідь, потім обробляти випадки, коли він додає пояснення, обирає щось не зі списку або загортає відповідь у речення. Jev повертає ймовірність для кожного переданого вами варіанта. Немає що парсити, і нічого поза списком.
Ви отримуєте повний розподіл, а не лише відповідь. Коли Jev каже needed: 0.52, not_needed: 0.48, ви знаєте, що це як підкидання монети, і ваш harness може ескалювати задачу. Коли текстова модель каже «needed», ви гадки не маєте, чи була вона впевнена. Пороги працюють лише тоді, коли ви бачите ймовірності.
Математика витрат інша. Вихідні дані Jev безкоштовні, а вхідні коштують $0.042 за мільйон токенів. Оцінка 41 фрагмента нотаток на кожному кроці означає 41 маленький виклик на крок. З Jev це частка цента. З будь-якою текстовою моделлю, навіть дешевою, це 41 генерація з власною вартістю виводу та затримкою.
Використовуйте Haiku для дрібних редагувань, де йому дійсно треба писати код. Використовуйте Jev для вибору зі списків. Використовуйте Opus для роздумів. Нехай кожна модель робить те, для чого створена.
Як це впровадити, нічого не зламавши
Не вмикайте всі чотири рішення одночасно. Ось порядок, якого б дотримувався я.
Тиждень 1: shadow mode. Залиште свого поточного агента як є. Для кожного рішення, яке він приймає, також ставте те саме запитання 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: увімкніть відновлення та тести. Обидва мають жорсткі обмеження та fallback у коді, тому найгірший сценарій — повернення до того, що ви робите сьогодні.
Останнім: маршрутизація. Помилки маршрутизації найпомітніші для користувачів, бо складна задача, відправлена швидкому виконавцю, генерує поганий код. Увімкніть її останньою, з консервативним порогом, і слідкуйте за відсотком помилок на кроках швидкого виконавця.
Сховайте кожне рішення за прапорець увімкнення/вимкнення, щоб мати змогу скасувати його одним рядком.
Встановлення порогів за рівнем ризику
Один поріг для всього — це помилка. Встановлюйте їх залежно від того, що станеться, якщо відповідь буде неправильною.
Одна сесія розробки фічі, той самий результат: з $6.42 до $2.00
Низькі ставки, легко скасувати: від 0.55 до 0.65. Вибір нотаток. Порядок тестів. Неправильна відповідь коштує трохи контексту або кількох секунд.
Середні ставки: 0.8. Маршрутизація та відновлення. Неправильна відповідь коштує невдалого кроку, який ваш harness перехопить.
Високі ставки, важко скасувати: 0.9 або ніколи. Видалення файлів. Force push. Зміни конфігурації продакшену. Запуск міграції. Моя чесна порада: не дозволяйте жодній моделі приймати такі рішення самостійно. Передавайте їх людині або, як мінімум, в Opus із кроком підтвердження.
Усе, що нижче порогу, йде вище по ланцюгу: до Opus, якщо потрібні міркування, до людини, якщо потрібна оцінка ситуації.
Де це не допоможе
Ця архітектура — не магічний множник для будь-якого навантаження.
Задачі чистої генерації майже не змінюються. Якщо ваш агент проводить більшість часу, пишучи великі обсяги нового коду за чітким ТЗ, там мало рішень, які можна перенести. Ви все одно отримаєте економію на виборі нотаток, але небагато іншого.
Крихітним проєктам це не потрібно. Якщо вся ваша папка з нотатками — це 2000 токенів, а suite проганяється за вісім секунд, накладні витрати на побудову цього поки що не виправдані.
Jev не дуже підходить для самостійного прийняття фінальних рішень. Він чудово помічає деталі та обирає з короткого списку. Але це не та модель, якій варто ставити одне велике запитання «чи готовий цей pull request до merge?». Розбивайте великі запитання на малі, оцінюйте кожне та комбінуйте результати у своєму коді з власними вагами.
Якщо у вас уже є розмічені дані для фіксованого запитання, маленька модель, яку ви хостите самі, може обійти Jev за ціною. Jev сяє там, де запитання постійно змінюються і у вас немає навчальних даних, а це опис більшості агентів для кодування.
Помилок, яких я б уникав
Дозволяти моделі писати список варіантів. Уся архітектура тримається на варіантах, з якими ваш код може працювати. Якщо модель генерує варіанти, ви повертаєтесь до парсингу вільного тексту.
Питати Jev, чи він упевнений. Натомість читайте ймовірність. Самооцінка майже завжди буде «так».
Відсутність fallback. Кожне рішення Jev потребує шляху для «не впевнений», і цей шлях — Opus або людина, ніколи не вгадування.
Обмеження повторів у промпті, а не в коді. Модель, якій сказали «повторюй лише 3 рази», іноді повторюватиме 30 разів. Код — ні.
Відмова від повного набору тестів. Точкові перевірки пришвидшують вас. Повний suite тримає вас чесними. Залишайте обидва.
Вимірювати нічого. Якщо ви не зафіксуєте вартість однієї сесії до старту, то ніколи не дізнаєтесь, зекономили ви 20% чи 70%. Спочатку зберіть дані про використання за тиждень звичайної роботи. Це займе десять хвилин, і це єдина цифра, яка має значення.
Що зробити цього тижня
Ось усе це у вигляді чекліста:
- Запишіть дані за тиждень роботи агента: кроки, токени, витрати, помилки.
- Знайдіть рішення, що ховаються у вашому циклі: нотатки, маршрутизацію, відновлення, тести.
- Сформулюйте кожне з них як запитання з фіксованим списком варіантів.
- Запустіть Jev у тіньовому режимі паралельно з вашим поточним агентом на тиждень.
- Встановіть пороги на основі журналу розбіжностей, орієнтуючись на рівень ризику.
- Спершу увімкніть вибір нотаток, потім — відновлення та тести, а вже після — маршрутизацію.
- Порівняйте вартість сесії «до» і «після». Це і є ваша цифра.
Opus 5.5 — найкраща модель для міркувань, яку я використовував для коду. Помилка полягає в тому, щоб змушувати її робити ще й усе інше.
Дозвольте їй думати. Дозвольте Jev вирішувати. Нехай ваш код керує.
Якщо це було корисно, підписуйтесь на @cyrilXBT. Щотижня я детально розбираю, як будувати продукти на базі найновіших AI-моделей, із реальними цифрами.
Збережіть цю статтю в закладки, щоб мати її під рукою, коли почнете розробку.
