Seu agente de código está pagando preços de modelo frontier para responder questões de múltipla escolha.
Quais notas devo carregar? Esta etapa vai para o modelo grande ou para um menor? A ferramenta acabou de falhar. Tentar de novo, corrigir ou desistir? Quais testes devem rodar primeiro?
Cada uma dessas é uma pergunta com quatro ou cinco respostas possíveis. E na maioria das configurações de agentes atuais, todas elas são respondidas pelo modelo mais caro que você tem, com o modo thinking ativado, lendo todo o contexto e escrevendo um parágrafo antes de tomar uma decisão.
É aí que está o vazamento.
Este artigo mostra como estancá-lo. O Opus 5.5 fica com o raciocínio pesado: planejamento, escrita de código, debugging. O Jev assume as quatro decisões que acontecem em praticamente todas as etapas. Seu harness prepara as opções, verifica as respostas e dá a palavra final.
No exemplo prático abaixo, uma sessão de desenvolvimento de feature cai de US$ 6,42 para US$ 2,00. Isso é 69% mais barato, e cada linha da conta está neste artigo para que você possa conferir com os seus próprios números.
Isso foi escrito para qualquer pessoa que roda um agente de código em trabalho real: Claude Code, seu próprio harness na API ou qualquer coisa entre os dois. Você não precisa reescrever seu agente. Cada peça deste artigo se encaixa em um loop existente como uma chamada de função com uma flag para desativá-la. Se você leu meu artigo sobre Jev + Claude Code, esta é a versão atualizada: mesma ideia, um modelo de raciocínio mais recente e quatro decisões específicas em vez de um princípio geral.
Você vai precisar de uma chave de API do Jev, uma chave de API da Anthropic e de cerca de uma semana de logs do seu próprio agente para usar como base de comparação.
Vamos construir isso.
opus raciocina jev decide.
O Problema: Um Modelo Fazendo Dois Trabalhos
Observe um agente de código trabalhando por dez minutos e você o verá fazendo dois tipos de trabalho bem diferentes.
O primeiro trabalho é raciocinar. Planejar uma feature. Escrever uma função. Ler um stack trace e descobrir por que o parser de datas quebra em anos bissextos. Esse trabalho é aberto. A resposta não está em uma lista. Aqui você quer o modelo mais inteligente que puder pagar, e o Opus 5.5 é muito bom nisso.
O segundo trabalho é decidir. Escolher as três notas de projeto que importam dentre quarenta. Decidir que uma renomeação pode ir para um modelo barato. Escolher o que fazer depois que o npm test dá timeout. Definir quais 12 arquivos de teste rodar antes dos 1.400 completos. Essas respostas estão em uma lista. A lista é curta. E seu código pode agir diretamente com base na resposta.
A maioria dos agentes executa os dois trabalhos no mesmo modelo, porque esse é o padrão. O loop chama o Opus, o Opus pensa, o Opus responde, o loop continua.
Funciona. Mas também é lento e caro de um jeito fácil de passar despercebido, porque as chamadas de decisão não parecem caras individualmente. Uma única chamada de "quais notas eu preciso" custa talvez um centavo. Mas ela acontece em cada etapa e carrega o contexto inteiro consigo todas as vezes.
E há um segundo custo ainda mais fácil de ignorar: quando o agente não consegue decidir o que carregar, ele carrega tudo. Cada nota de projeto, cada documento de convenção, cada decisão passada, tudo enfiado em cada chamada. O Opus 5.5 barateou as leituras de cache para US$ 0,20 por milhão de tokens, mas "barato vezes sessenta etapas vezes toda a sua pasta de notas" ainda soma bastante.
A Solução: Opus Raciocina, Jev Decide, Seu Harness Manda
O Jev é o modelo da TypeSafe criado exatamente para o segundo trabalho. Ele não escreve texto. Você fornece contexto e perguntas tipadas com um conjunto fixo de opções, e ele devolve uma probabilidade para cada opção. Responde em milissegundos, o input custa US$ 0,042 por milhão de tokens e o output é gratuito.
Isso torna a arquitetura simples de descrever:
O Opus 5.5 faz o raciocínio. Planejamento, código, debugging, qualquer coisa em que a resposta não esteja em uma lista.
O Jev toma as pequenas decisões. Ele escolhe entre as opções que seu harness preparou.
Seu harness continua no comando. Ele constrói as listas de opções, lê as probabilidades, aplica limites (thresholds) e recorre ao Opus quando o Jev não tem certeza.
Essa terceira linha é a que as pessoas pulam, e é justamente a que torna tudo seguro. O Jev nunca inventa uma opção. O Jev nunca tem a palavra final sobre algo que você não possa desfazer. É o seu código que decide o que significa "certeza suficiente".
Aqui está a função auxiliar na qual todo o resto deste artigo se baseia:
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Conecte isso ao seu cliente Jev: o SDK da TypeSafe, o Vercel AI Gateway,
ou o pacote LangChain. Deve retornar {opção: probabilidade}
para cada opção que você passou.
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)
Repare no que não está ali: nenhuma pergunta pedindo ao Jev para dizer qual é o seu nível de confiança. Você lê a probabilidade que ele retorna. Perguntar "tem certeza?" a qualquer modelo resulta em um "sim" quase sempre. A probabilidade é o sinal honesto.
Agora, as quatro decisões.
As quatro decisões dentro da etapa do agente
Decisão 1: Escolha as Notas de Projeto Relevantes Antes de Carregar o Contexto
Esta é a maior alavanca isolada, e é aquela que quase ninguém implementou.
Seu agente tem uma pasta de notas. Um AGENTS.md, documentos de arquitetura, convenções, decisões passadas, avisos de "nunca mexa no módulo de cobrança sem uma migração". Talvez uns 30.000 tokens disso. A maioria dos agentes carrega tudo em cada chamada, porque ninguém quer ser a pessoa que deixou de fora a nota importante.
Então, em vez de carregar tudo, você faz uma pergunta simples ao Jev sobre cada nota, tudo em paralelo: o agente precisa desta nota para esta tarefa?
Primeiro, divida suas notas em blocos por título. Cada seção do AGENTS.md vira seu próprio bloco. Cada documento de arquitetura vira um ou mais blocos.
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()]
Depois, pontue cada bloco em relação à tarefa atual:
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]]
Três detalhes importam aqui.
Sempre carregue o que é inegociável. Algumas notas devem estar em cada chamada, não importa o quê: regras de segurança, "nunca faça force push", aquela linha que diz qual banco de dados é o de produção. Marque-as como always e pule a pontuação delas.
Mantenha um piso e um plano B. Se nada passar de 0,55, você ainda carrega os dois primeiros. Um agente com zero contexto é pior do que um com contexto um pouco exagerado.
Registre o que foi descartado. Quando o agente comete um erro, a primeira coisa que você verifica é se a nota que teria evitado aquilo foi descartada pela pontuação. Esse log é como você ajusta o keep e o floor.
No exemplo prático, essa única mudança reduz a parte de notas de cada chamada de 30.000 para 6.000 tokens. Sozinha, ela corta o custo da sessão em cerca de 24%.
Decisão 2: Encaminhe Tarefas Adequadas para um Worker Mais Rápido
Nem toda etapa precisa do Opus.
Renomear uma função em oito arquivos não precisa. Adicionar um campo a um formulário que já tem nove campos idênticos não precisa. Atualizar um caminho de import não precisa. São edições que seguem um padrão que já existe no codebase.
Por isso, antes de cada etapa rodar, o Jev classifica a etapa e seu mapeia a classe para um worker:
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]
Veja como as opções foram escritas. Não são "fácil" e "difícil", e definitivamente não são "um modelo pequeno dá conta disso?". São tipos concretos de trabalho que seu código pode mapear para uma ação. Essa é a regra para toda pergunta ao Jev: cada opção precisa ser algo que seu harness saiba como executar.
E repare no padrão. Abaixo de 0,8, a etapa vai para o Opus. Erros de roteamento aqui só vão em uma direção: uma tarefa difícil enviada ao worker rápido custa uma etapa falha e uma nova tentativa, enquanto uma tarefa fácil enviada ao Opus custa apenas um pouco mais. Então, na dúvida, mande para cima.
Para o worker rápido, uso o Haiku 4.5 a US$ 1 por milhão de tokens de input e US$ 5 por milhão de output. No exemplo prático, 12 das 36 etapas de trabalho real vão para ele.
Decisão 3: Escolha um Caminho de Recuperação Quando uma Ferramenta Falhar
Ferramentas falham o tempo todo. Testes dão timeout. Um caminho de arquivo está errado. Um pacote não está instalado. Um comando shell esbarra num erro de permissão. Um linter reclama de algo não relacionado.
A maioria dos agentes lida com isso da maneira mais cara possível: devolvem o erro inteiro para o modelo grande e deixam que ele pense no que fazer. Às vezes isso é o certo. Muitas vezes a resposta é óbvia, e o Opus gasta 1.500 tokens redescobrindo que ENOENT significa que o arquivo não está lá.
Pior: os agentes ficam presos em loops. Tenta, falha, tenta, falha, pagando por uma etapa completa de raciocínio a cada vez.
Então você entrega a falha ao Jev com um conjunto fixo de caminhos de recuperação:
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # últimos n caracteres do erro
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", # rede instável ou timeout3 "retry_after_install", # pacote ou ferramenta ausente4 "fix_path_and_retry", # caminho de arquivo ou cwd errado5 "switch_tool", # esta ferramenta não consegue, outra sim6 "escalate_to_opus", # precisa de debugging real7 "stop_and_report", # precisa de um humano8]
O limite rígido de tentativas vive no código, não no modelo. Nenhum modelo, por mais barato que seja, deve ter permissão para tentar infinitamente.
Cada caminho de recuperação mapeia para uma pequena função no seu harness. retry_after_install lê o pacote ausente do erro com uma regex e o instala. fix_path_and_retry verifica os caminhos existentes e sugere a correspondência mais próxima. Só escalate_to_opus gasta dinheiro de verdade, e só dispara quando a falha realmente exige raciocínio.
No exemplo prático, isso elimina 6 etapas de repetição desperdiçadas da sessão.
Decisão 4: Rode Verificações Focadas Antes da Suíte Completa de Testes
Esta economiza mais tempo do que dinheiro, e tempo é o que faz um agente parecer rápido.
Após cada alteração, a maioria dos agentes roda a suíte inteira de testes. Se sua suíte leva quatro minutos, seu agente passa quatro minutos esperando após cada edição e depois lê centenas de linhas de saída procurando a única falha que importa.
A solução segue o mesmo padrão das notas: pontue cada arquivo de teste em relação ao diff, rode os mais relevantes primeiro e só execute a suíte completa quando as verificações focadas passarem.
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 # falhe rápido, corrija antes de qualquer outra coisa18 return run_tests(test_files) # a suíte completa ainda é o critério para o commit
Leia essa última linha duas vezes. A suíte completa ainda roda antes de qualquer commit. As verificações focadas são um alerta precoce, não um substituto. Você detecta a maioria das quebras em segundos em vez de minutos e nunca entrega algo que a suíte completa teria pego.
Adicione as verificações baratas primeiro também: checagem de tipos e lint apenas nos arquivos alterados. Levam um segundo e pegam uma parcela surpreendente de erros antes de qualquer teste rodar.
Juntando Tudo: O Loop do Harness
Veja como as quatro decisões se encaixam dentro de uma etapa do loop:
def run_step(task: str, step: str, state):
1. contexto: carrega apenas as notas que esta etapa precisa
notes = state.always_notes + pick_notes(step, state.notes)
2. roteamento: escolhe o worker para esta etapa
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. recuperação: trata quaisquer falhas de ferramentas nesta etapa
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. verificações: testes focados primeiro, suíte completa antes do commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
E aqui está o lado do Opus: é só a sua chamada normal ao Opus 5.5. Coloque seu contexto estável primeiro (prompt de sistema, definições de ferramentas, as notas "always") para que fique em cache entre as etapas, e deixe o material específico da etapa por último.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # o id do seu modelo 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}"}],
)
Nada exótico. A economia vem daquilo que você deixa de enviar para ele, não de um prompt genial.
Uma Etapa Rastreada
Veja como uma única etapa aparece no log quando as quatro decisões estão ativas. A tarefa: adicionar limitação de taxa (rate limiting) ao endpoint público de cadastro. Este trace é ilustrativo, mas é o formato que você verá nos seus próprios logs.
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
Leia de cima para baixo e conte quantas dessas linhas costumavam ser uma chamada completa ao Opus. Escolher notas: uma chamada enorme, ou nenhuma escolha e 30.000 tokens de notas carregados às cegas. Roteamento: nada, toda etapa ia para o Opus. O pacote ausente: uma etapa inteira de raciocínio para concluir que um módulo faltando significa "instale o módulo". Escolher testes: nada, a suíte completa em cada edição.
Agora, apenas uma linha desse trace é Opus, e é a linha que realmente precisava de um modelo frontier: planejar e escrever o rate limiter.
Essa é a ideia inteira em uma imagem. O modelo caro gasta seu tempo na parte do trabalho que só ele consegue fazer.
O Exemplo Prático: De Onde Vêm os 69%
Aqui está a conta completa de uma sessão de feature: 60 etapas de agente mais as 6 repetições desperdiçadas que um agente típico acumula pelo caminho. Todos os preços são os valores de tabela públicos atuais.
Antes: Opus 5.5 faz tudo
Cada etapa carrega 70.000 tokens de contexto: 15.000 para o prompt de sistema e ferramentas, 30.000 para a pasta de notas completa e 25.000 para a conversa até então. Assumo que 80% disso seja cache hit. Cada etapa gera cerca de 1.500 tokens de output, porque o thinking está sempre ligado no 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
Depois: a camada de decisão
O contexto cai para 46.000 tokens por etapa, porque o Jev escolhe 6.000 tokens de notas em vez de carregar todos os 30.000. As 24 etapas puramente de decisão passam para o Jev. Os 6 loops de repetição desaparecem. E 12 das 36 etapas de trabalho restantes vão para o 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
De US$ 6,42 para US$ 2,00. Isso é 68,8% mais barato para a mesma feature.
defina o threshold pelo custo de uma resposta errada
E aqui está quanto cada alavanca contribui, empilhadas em ordem:
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
Duas observações honestas sobre essa conta.
Primeiro, esses são números modelados com base em premissas explícitas, não uma medição do seu stack. Seu tamanho de contexto, taxa de cache hit e contagem de decisões serão diferentes. O motivo de mostrar cada linha é para que você possa substituir pelos seus próprios números. Depois de medir o seu antes e depois real, use o seu número, não o meu.
Segundo, veja para onde o dinheiro realmente vai. As 102 chamadas do Jev custam dois centavos no total. A economia não vem do Jev ser barato por chamada. Ela vem de tudo que deixa de acontecer depois que o Jev toma a decisão: contexto inchado, etapas completas de raciocínio para perguntas de múltipla escolha, loops de repetição e chamadas ao modelo grande para tarefas de renomeação.
Por Que Não Usar Apenas o Haiku para as Decisões?
Pergunta justa. O Haiku 4.5 é barato e rápido. Por que adicionar um modelo novo?
Três motivos.
Ele ainda escreve. O Haiku responde em texto. Você precisa instruí-lo a responder com uma das suas opções, depois fazer o parse da resposta e lidar com as vezes em que ele adiciona uma explicação, escolhe algo que não está na lista ou embute a resposta numa frase. O Jev retorna uma probabilidade para cada opção que você passou. Não há nada para fazer parse e nada fora da lista.
Você recebe a distribuição completa, não apenas uma resposta. Quando o Jev diz needed: 0.52, not_needed: 0.48, você sabe que é cara ou coroa e seu harness pode escalar. Quando um modelo de texto diz "needed", você não faz ideia se ele tinha certeza. Thresholds só funcionam quando você consegue ver as probabilidades.
A matemática de custos é diferente. O output do Jev é gratuito e seu input custa US$ 0,042 por milhão de tokens. Pontuar 41 blocos de notas a cada etapa significa 41 chamadas pequenas por etapa. Com o Jev, isso é fração de centavo. Com qualquer modelo de texto, mesmo um barato, são 41 gerações com seu próprio custo de output e latência.
Use o Haiku para edições pequenas, onde ele realmente precisa escrever código. Use o Jev para escolher em listas. Use o Opus para pensar. Cada modelo faz o trabalho para o qual foi criado.
Como Implementar Sem Quebrar Nada
Não ative as quatro decisões de uma vez. Aqui está a ordem que eu usaria.
Semana 1: shadow mode. Mantenha seu agente atual exatamente como está. Para cada decisão que ele tomar, faça também a mesma pergunta ao Jev e registre ambas as respostas mais a probabilidade do Jev. Não aja com base na resposta do Jev de forma alguma.
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 )
Semana 2: leia as divergências. Olhe apenas para as linhas em que o Jev e seu agente atual discordaram. Ordene-as pela probabilidade do Jev. Você geralmente encontrará uma linha clara: acima de certa probabilidade, o Jev acerta quase tão frequentemente quanto o Opus. Essa linha é o seu threshold. Essas linhas de divergência também viram seu conjunto de testes, montado de graça a partir do seu tráfego real.
Semana 3: ative a seleção de notas. É a maior alavanca e a mais fácil de desfazer, já que uma nota esquecida aparece rápido nos seus logs.
Semana 4: ative recuperação e testes. Ambos têm limites rígidos e fallbacks no código, então o pior caso é voltar ao que você faz hoje.
Por último: roteamento. Erros de roteamento são os mais visíveis para os usuários, porque uma tarefa difícil enviada ao worker rápido produz código ruim. Ative-o por último, com um threshold conservador, e monitore a taxa de falha nas etapas do worker rápido.
Coloque cada decisão atrás de uma flag de liga/desliga para que você possa desfazê-la com uma linha.
Definindo Thresholds por Risco
Um único threshold para tudo é um erro. Defina-os pelo que acontece quando a resposta está errada.
Uma sessão de feature, mesmo resultado: de US$ 6,42 para US$ 2,00
Risco baixo, fácil de desfazer: 0,55 a 0,65. Escolher notas. Ordenar testes. Uma resposta errada custa um pouco de contexto ou alguns segundos.
Risco médio: 0,8. Roteamento e recuperação. Uma resposta errada custa uma etapa falha, que seu harness detecta.
Risco alto, difícil de desfazer: 0,9 ou nunca. Apagar arquivos. Fazer force push. Mexer em configuração de produção. Rodar uma migração. Meu conselho sincero: não deixe nenhum modelo tomar essas decisões sozinho. Encaminhe-as para um humano ou, no mínimo, para o Opus com uma etapa de confirmação.
Qualquer coisa abaixo do threshold sobe na hierarquia: para o Opus se exigir raciocínio, para um humano se exigir julgamento.
Onde Isso Não Ajuda
Essa arquitetura não é um multiplicador mágico para qualquer carga de trabalho.
Cargas de geração pura quase não mudam. Se seu agente passa a maior parte do tempo escrevendo grandes volumes de código novo a partir de uma especificação clara, não há muitas decisões para mover. Você ainda terá a economia da seleção de notas, mas pouco além disso.
Projetos minúsculos não precisam disso. Se toda a sua pasta de notas tem 2.000 tokens e sua suíte roda em oito segundos, o overhead de construir isso ainda não compensa.
O Jev não é ótimo para dar a palavra final sozinho. Ele é excelente em notar coisas e escolher em uma lista curta. Não é o modelo ideal para decidir "este pull request está pronto para merge?" como uma pergunta única. Divida perguntas grandes em pequenas, pontue cada uma e combine os resultados no seu próprio código com seus próprios pesos.
Se você já tem dados rotulados para uma pergunta fixa, um modelo pequeno hospedado por você pode bater o Jev no preço. O Jev brilha quando as perguntas continuam mudando e você não tem dados de treinamento, o que descreve a maioria dos agentes de código.
Os Erros Que Eu Evitaria
Deixar o modelo escrever a lista de opções. Toda a arquitetura depende de opções nas quais seu código possa agir. Se um modelo gera as opções, você volta a fazer parse de texto livre.
Perguntar ao Jev se ele está confiante. Leia a probabilidade em vez disso. Um autorrelato é quase sempre "sim".
Sem fallback. Toda decisão do Jev precisa de um caminho para "não tenho certeza", e esse caminho é o Opus ou um humano, nunca um palpite.
Limites de repetição no prompt em vez de no código. Um modelo instruído a "tentar apenas 3 vezes" ocasionalmente tentará 30 vezes. Código não.
Descartar a suíte completa de testes. As verificações focadas aceleram você. A suíte completa mantém você honesto. Fique com as duas.
Medir nada. Se você não registrar o custo por sessão antes de começar, nunca vai saber se economizou 20% ou 70%. Primeiro, levante o seu uso durante uma semana de trabalho normal. Leva dez minutos e é o único número que realmente importa.
O que fazer esta semana
Aqui está o processo completo em formato de checklist:
- Registre uma semana de sessões do agente: etapas, tokens, custo e falhas.
- Identifique as decisões escondidas no seu loop: notas, roteamento, recuperação e testes.
- Escreva cada uma delas como uma pergunta com uma lista fixa de opções.
- Rode o Jev em modo shadow ao lado do seu agente atual por uma semana.
- Defina os limites a partir do log de divergências, com base no risco.
- Ative primeiro a seleção de notas, depois a recuperação e os testes e, por fim, o roteamento.
- Compare o custo por sessão antes e depois. Esse é o seu número.
O Opus 5.5 é o melhor modelo de raciocínio que já usei para código. O erro é obrigá-lo a fazer todo o resto também.
Deixe-o pensar. Deixe o Jev decidir. Deixe o seu código ditar as regras.
Se este conteúdo foi útil, siga @cyrilXBT. Toda semana eu detalho como construir produtos com os modelos de IA mais recentes, sempre com os números reais.
Salve este artigo nos favoritos para tê-lo à mão quando for começar a construir.
