Como passar o resultado do Jev para o Claude Code sem executar um erro como plano aprovado

Fala aí, beleza? Se você já está plugando o Jev no fluxo do Claude Code, se liga nessa frase antes de qualquer coisa:

uma decisão tipada com probabilidade alta NÃO é um plano aprovado

O Jev é o primeiro modelo "System One" da TypeSafe AI, lançado em early access em 15 de setembro de 2026

E o cenário que mais aparece agora é este: o resultado do Jev vira o pedido que você entrega pro Claude Code executar

O problema mora justamente nessa passagem de bastão…

Se teve um erro de entendimento no meio do caminho, ele chega no Claude Code com cara de coisa já revisada, e é executado como se alguém tivesse dado o ok 😛

Então este post é um checklist de handoff, passo a passo, pra você conferir o que importa antes de mandar executar

O que você precisa antes de começar

O básico é pouco:

• Acesso ao Jev: a lista de espera da API acabou em 21 de setembro de 2026 e hoje qualquer pessoa pode se cadastrar no console.typesafe.ai, que dá US$ 5 de crédito grátis; outra opção é o OpenRouter, onde o Jev está em beta
• Claude Code instalado e funcionando no seu projeto

Agora uma coisa que confunde muita gente: o Jev não substitui o modelo do Claude Code

Por quê?

Porque o Jev é um modelo de decisão, não de texto

Ele recebe estado e perguntas tipadas e devolve respostas tipadas com probabilidades calibradas, nunca prosa

Como o Claude Code precisa de um modelo que escreva código e explique o que está fazendo, o Jev entra como ferramenta ou juiz AO LADO do LLM, e não no lugar dele

Tem também o lado técnico: a API dele não é compatível com OpenAI

Nada de /chat/completions, nada de array de messages, nada de temperature, o endpoint é este aqui:

POST https://api.typesafe.ai/v1/systemone

Quais são os caminhos de integração do Jev com o Claude Code?

Hoje existem quatro jeitos de juntar as duas coisas:

• Skill oficial (TypeSafe-ai/skills), instalada como plugin
• Ferramentas MCP, como o jkudish/jev-mcp, com dez julgamentos tipados
• Plugins de fronteira da comunidade via hooks
• Roteamento de modelo por turno

Se tu ainda está decidindo em que ponto do fluxo o Jev deve atuar, vale ler sobre em que ponto do fluxo ele entra, antes, durante ou depois

E um detalhe útil: plugin no Claude Code se instala pelo comando /plugin, escolhendo o escopo User (vale pra todos os projetos) ou Project (só o repo atual)

Checklist de handoff do Jev para o Claude Code, passo a passo

Bora pro checklist 😀

1. Identifique o tipo da resposta e leia a probabilidade

O Jev responde em três tipos de pergunta:

Tipo	O que devolve
Choice	Uma escolha dentro de uma lista
Score	Uma nota numa escala ordenada
Noul	A probabilidade de uma afirmação ser verdadeira

Antes de qualquer coisa, saiba qual desses tipos você tem na mão e qual foi a probabilidade calibrada que veio junto

Erro comum deste passo: tratar probabilidade alta como prova

Probabilidade alta é o quanto o modelo está confiante, não uma garantia de que ele acertou

2. Separe a decisão do texto em volta

O Jev devolve só decisões tipadas, então qualquer explicação, trecho de código ou justificativa que aparece no pedido NÃO veio dele

Veio do LLM que montou o pedido, ou de você mesmo

Na prática, faz assim: deixa a decisão do Jev isolada (o tipo, o valor escolhido, a probabilidade) e marca todo o resto como "texto a conferir"

Erro comum deste passo: atribuir ao Jev uma frase que ele não gerou

É tipo achar que o juiz escreveu a petição só porque ele assinou a sentença haha

3. Confira cada caminho de arquivo citado contra o repo real

Se o pedido fala em src/auth/login.ts, abre o projeto e vê se esse arquivo existe MESMO, com esse nome e nesse lugar

Isso vale pra pasta, nome de função, nome de rota e por aí vai

Erro comum deste passo: aceitar um caminho plausível que não existe

Caminho plausível é o mais perigoso, porque passa no olho 🙂

4. Liste as suposições não verificadas e transforme em pergunta ou em checagem manual

Pega o pedido e caça frases do tipo "como o projeto já usa X" ou "já que esse endpoint é privado"

Cada uma dessas é uma suposição

Pra cada suposição crítica, tu tem dois caminhos:

• Vira uma pergunta Noul, que é justamente o tipo feito pra devolver a probabilidade de uma afirmação ser verdadeira
• Ou vira um item de verificação manual: você mesmo abre o código e confirma

Erro comum deste passo: deixar a suposição embutida no prompt como se fosse fato

O Claude Code vai obedecer o pedido, então se a suposição está errada, ele executa o erro com toda a boa vontade do mundo

5. Entre no plan mode e compare o plano com a decisão original

Que plan mode?

É o modo somente leitura do Claude Code: ele lê o código e propõe um plano antes de mexer em qualquer arquivo, com edições, escritas e comandos que alteram coisas bloqueados

Pra entrar, usa o comando abaixo ou aperta Shift+Tab (que alterna entre os modos):

/plan

Cola o pedido e deixa ele montar o plano

Aí vem a parte importante: compara o plano proposto com a decisão original do Jev

O plano mexe nos arquivos que você conferiu no passo 3? Ele respeita o que o Jev decidiu, ou foi além?

Erro comum deste passo: pular direto para a execução

6. Opcional: coloque um gate no PreToolUse com o jev-use

O jev-use é um plugin da comunidade (não é da TypeSafe) pra Claude Code, Codex e pi

A ideia dele é entregar ao Jev os passos do agente que não precisam de texto, com escalonamento tipado de volta pro LLM

Ele direciona as coisas assim:

Situação	Para onde vai
Fatos que já estão no contexto	Ferramenta jev_judge, com todas as perguntas numa chamada
Itens em arquivo ou saída de ferramenta	CLI jev-use judge, a partir de script
Decisão de segurança que bloqueia chamada de ferramenta	Hook PreToolUse jev-use hook gate

Os nomes que importam pro handoff são estes:

jev_judge
jev-use judge
jev-use hook gate

E por que o PreToolUse é o lugar certo pro gate?

Porque no Claude Code esse hook roda depois que o Claude monta os parâmetros da ferramenta e ANTES de a chamada ser executada, e ele pode bloquear a chamada

Ou seja, é o último ponto antes do estrago 😛

No jev-use funciona assim:

• Com limiar de 0.9, o hook só aprova quando todas as perguntas passam desse limiar
• Regras com confiança entre 0.50 e 0.80 recebem uma segunda chamada
• O que o Jev não pode ou não deve decidir volta com escalate: true e um motivo tipado, devolvendo escrita e passos incertos pro LLM

Erro comum deste passo: instalar o gate e ignorar o escalate

Se veio escalate: true, é o sistema te avisando que aquilo NÃO é decisão pro Jev

Quando o erro já virou plano: sintomas comuns no handoff

Às vezes o erro já passou e você só percebe pelo comportamento do Claude Code

Aqui vai um mapa rápido de sintoma, causa e solução:

Sintoma	Causa provável	Solução
Claude Code edita arquivo que não deveria ou procura caminho que não existe	Caminho inventado na etapa de montagem do pedido	Voltar ao passo 3 e conferir cada caminho no repo
Decisão "certa" com confiança alta que se mostra errada	A garantia do Jev é de schema, não de veracidade	Verificação independente antes de executar
Passo incerto executado sem revisão	escalate ignorado	Respeitar o escalate e devolver o passo ao LLM

Por que confiança alta pode estar errada?

Esse é o ponto que mais pega gente desavisada

A tal garantia de "zero alucinação" do Jev cobre só a conformidade com o schema: ele não devolve valor fora do que foi declarado

Mas isso não garante que a resposta escolhida é a verdadeira, o modelo pode escolher a opção errada com alta confiança dentro de um schema perfeitamente válido

E a própria TypeSafe diz que o número de 0% "não é empírico"

Tome cuidado com isso!

Como prevenir

Duas regras resolvem boa parte do problema:

• Plan mode como padrão em todo handoff que vem do Jev, sem exceção
• Gate no PreToolUse pra que chamadas de ferramenta passem por um filtro antes de executar

O que a revisão entre ferramentas mostrou na prática (Claude Code + Codex)

Antes de tudo, deixando bem claro: a experiência que eu vou contar aqui é com Claude Code + Codex, não com o Jev

Mas a lógica é exatamente a mesma do checklist: a saída de uma ferramenta vira o pedido da outra, e é nessa passagem que mora o risco

No vídeo abaixo eu mostro a integração do zero

E já começou com emoção: na primeira tentativa de instalar o plugin deu erro por causa de uma pasta bugada, tive que excluir a pasta e tentar de novo pra funcionar haha

Depois rodei o review num projeto real meu

A mudança analisada era pequena: 4 arquivos alterados e 13 inserções

E mesmo assim o Codex apontou uma regressão funcional: a alteração no signup removia o único caminho de criar conta de coach, sendo que a aplicação ainda expunha fluxos exclusivos pra esse papel

Se liga no detalhe: uma mudança desse tamanho dá pra conferir item a item, exatamente como o passo 3 pede, e mesmo assim o problema passaria batido sem uma segunda olhada

Aí rodei o adversarial review pedindo explicitamente pra questionar a abordagem de autenticação e investigar possíveis falhas no sistema de like e comentários

O veredito veio como "precisa de atenção", sem condições de deploy:

• O fluxo de coach tinha sido efetivamente removido
• Endpoints de like permitiam que não participantes interagissem com conteúdo de outros usuários
• A página de desafio vazava reflexões pra quem não participava

Depois usei o rescue pedindo pro Codex corrigir especificamente a restrição de visibilidade das reflexões e das mutações de like

Ele corrigiu assim:

• Passou a só consultar e renderizar reflexões quando o usuário participa do desafio
• Validou nas rotas de like se a reflexão existe e se o usuário participa antes de permitir a mutação
• Ajustou o componente de reflection card pra desfazer o like otimista quando a API retorna erro

Mas, e aqui está a lição que conecta com o post inteiro, o próprio fluxo pediu teste manual adicional e apareceram alguns warnings

Então eu NÃO tratei a correção como 100% finalizada sem revisão humana

É a mesma ideia do escalate no jev-use: quando a ferramenta sinaliza incerteza, o passo volta pra quem tem que revisar

Gostei muiiito da dinâmica de uma IA questionar o trabalho da outra, porque é isso que pega problema real de segurança e de lógica

Próximo passo: transforme o checklist em rotina

Recapitulando a ideia central: decisão tipada é insumo, não aprovação

O Jev devolve decisões tipadas com probabilidade calibrada, e todo o texto em volta (caminhos, trechos, justificativas) veio de outro lugar e precisa ser conferido

Pro dia a dia, o próximo passo é bem prático:

1. Salva este checklist num arquivo do seu projeto e usa ele em todo handoff
2. Entra no plan mode (/plan ou Shift+Tab) sempre que o pedido vier de uma decisão do Jev
3. Se fizer sentido pro seu fluxo, avalia o gate PreToolUse do jev-use primeiro em escopo Project, num repo só, antes de levar pra escopo User e espalhar por todos os projetos

E se depois de rodar isso por um tempo tu quiser saber se o Jev está ajudando de verdade, vale ver como testar se ele está melhorando seu resultado

Qualquer dúvida, deixa nos comentários que bora trocar uma ideia 🙂

Até o próximo post!

Perguntas frequentes

Dá pra usar o Jev no Claude Code sem pagar nada?

Dá sim, pelo menos no começo. O cadastro no console.typesafe.ai dá US$ 5 de crédito grátis pra começar. Depois que o crédito acabar, aí sim entra a cobrança normal da API.

Qual a diferença entre a skill oficial e o jev-use no Claude Code?

A skill oficial vem do repo TypeSafe-ai/skills e se instala como plugin direto no Claude Code. Já o jev-use é um plugin da comunidade (github.com/shitianfang/jev-use), feito pra Claude Code, Codex e pi, que entrega ao Jev os passos do agente que não precisam de texto. São dois caminhos de integração diferentes, não uma coisa substituindo a outra.

O hook PreToolUse do jev-use bloqueia a execução antes ou depois da chamada da ferramenta?

Antes. No Claude Code, o PreToolUse roda depois que o Claude monta os parâmetros da ferramenta, mas antes de ela ser executada, e pode bloquear essa chamada. É exatamente esse ponto que o jev-use usa pra decidir segurança via ‘jev-use hook gate’.

O que significa a garantia de zero alucinação do Jev na prática?

Significa que o Jev não devolve um valor fora do schema declarado, não que ele sempre acerta a resposta. Ele pode escolher a opção errada com alta probabilidade calibrada dentro de um schema válido. É conformidade de formato, não garantia de verdade.

Como funciona o limiar de confiança do jev-use antes de aprovar algo no Claude Code?

Com limiar de 0.9, o hook só aprova quando todas as perguntas passam desse valor. Já as que ficam entre 0.50 e 0.80 de confiança recebem uma segunda chamada antes de qualquer decisão final.

Por que uma pergunta tipo Noul é útil pra checar suposição antes de mandar executar no Claude Code?

Porque Noul é o tipo de pergunta do Jev feito justamente pra devolver a probabilidade de uma afirmação ser verdadeira. Em vez de deixar a suposição embutida no prompt como se fosse fato, você transforma ela numa pergunta Noul e confere a probabilidade calibrada antes de confiar.