Claude Code + Jev: o agente escreve, o Jev decide

Passo o dia no Claude Code: ele lê o repositório, escreve, roda os testes e abre o PR. O Jev, da TypeSafe, faz outra coisa. Você manda o estado da aplicação e umas perguntas tipadas, e ele devolve probabilidades. Ele não gera texto, não chama ferramenta e não mexe em arquivo.

Muita gente tenta logo de cara trocar o modelo do Claude Code pelo Jev. Não tem como: o Claude Code fala a API de mensagens da Anthropic, e o Jev só tem um endpoint, POST /v1/systemone, sem nada de chat. O que funciona é o Claude Code escrever o código, e esse código chamar o Jev quando precisar de um julgamento rápido.

Onde o Jev entra

Os candidatos são os lugares onde hoje tem um regex frágil ou um prompt pedindo "responda em JSON". Por exemplo, classificar um ticket em billing, bug ou pedido de feature, decidir se uma mensagem é urgente, ou dar nota de severidade pra um bug.

Toda chamada tem o mesmo formato, um state e várias questions:

{
  "model": "jev-latest",
  "state": "O deploy falhou duas vezes e os clientes estão vendo erro 500. Alguém pode olhar agora?",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "A mensagem transmite urgência ou prazo"
    }
  }
}

E a resposta volta como número: {"is_urgent": {"type": "noul", "noul": 0.999}}. Tem três tipos de pergunta: choice escolhe entre opções que você passa, score dá uma nota numa escala, e noul é um sim ou não com probabilidade.

Ensinando o Claude Code a chamar o Jev direito

Sem contexto, o agente trata o Jev como mais uma API de LLM e erra sempre nas mesmas coisas. A TypeSafe tem uma skill pra isso:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

Se quiser forçar, chame /typesafe:typesafe-ai ou escreva "use a skill da TypeSafe" no pedido. A skill manda o agente ler a documentação atualizada, que também existe como servidor MCP:

claude mcp add --transport http typesafe-docs https://docs.typesafe.ai/mcp

Depois que o SDK estiver instalado, quem manda nos nomes dos campos são os tipos em node_modules/@typesafe-ai/sdk.

O que eu olho no review

Quando o Claude Code escreve uma integração com o Jev, eu confiro quatro coisas.

A primeira é se ele faz uma pergunta por chamada. O Jev responde perguntas independentes em paralelo, então as perguntas sobre o mesmo state vão juntas. Fazer um loop nos tickets é normal; um loop nas perguntas é dinheiro jogado fora.

A segunda é campo inventado. A requisição só tem model, state e questions. Se aparecer messages, temperature ou max_tokens, o agente está escrevendo código de chat.

A terceira é pedir pro Jev gerar conteúdo. Ele só escolhe entre as opções que você deu. Se a tarefa é extrair alguma coisa, o código acha os candidatos (com um regex, por exemplo) e o Jev escolhe um.

E a quarta é conta ou data dentro da pergunta. "Esse boleto está vencido?" é aritmética, e aritmética fica no código.

As regras que vão pro CLAUDE.md

Pra não ter que repetir isso toda sessão, deixo as regras no arquivo de instruções do projeto:

## Jev (TypeSafe)
- Jev é um modelo de decisão: não gera texto. Use o SDK oficial.
- Perguntas e limites ficam em um arquivo só (src/jev/questions.ts).
- Perguntas independentes vão na mesma chamada.
- Toda pergunta do tipo choice tem uma opção de saída ("outro").
- Conta e data ficam no código, nunca na pergunta.
- Ação irreversível só com confiança acima do limite; abaixo dele, vai para uma pessoa.
- A chave fica no servidor. Registre a versão do modelo de cada resposta.

Sobre a última linha: a confiança que o Jev devolve mede o quanto a distribuição está concentrada, e não a chance de a resposta estar certa. Por isso os limites (0.6, 0.7, o que for) a gente ajusta com casos reais rotulados, e a versão do modelo que respondeu (jev-1.13.0, por exemplo) fica registrada pra você fixar depois de calibrar.

Por onde começar

Eu escolheria um único ponto do sistema que hoje tem parsing frágil, pediria pro Claude Code propor a troca usando a skill, e revisaria com a lista acima antes de aceitar.