Quando não usar o Jev? As situações em que a decisão tipada é a ferramenta errada

Nem toda tarefa de IA é uma decisão

Fala aí, beleza? A TypeSafe AI soltou o Jev em early access no dia 15 de setembro de 2026 e, do jeito que a internet funciona, em uma semana já tinha gente querendo trocar LLM por Jev em tudo que é canto do sistema

Só que o Jev não gera texto: ele entende entrada em linguagem natural e devolve decisão tipada com probabilidades, pro teu código consumir. A TypeSafe chama essa classe de modelo de System One Models

Esse recorte é justamente o que faz ele ser excelente numa lista curta de problemas e péssimo em todo o resto

Então esse post vai na contramão do hype: cinco situações em que a decisão tipada é a ferramenta errada, uma tabela de quando usar o quê, e um veredito honesto no fim

Situação 1: quando a saída precisa ser texto

Essa é a mais óbvia e mesmo assim é a que mais aparece

O Jev não escreve. Ele não redige resumo, não escreve e-mail, não responde o usuário no chat, não gera documentação e não escreve código. A saída dele é tipada, com probabilidade, feita pra ser consumida por programa e não lida por gente

Se o entregável final do teu fluxo é uma frase que um humano vai ler, a peça que produz aquela frase é um LLM. Ponto

O padrão híbrido: um decide, o outro redige

Agora, tem um desenho que funciona bem e é onde a confusão costuma nascer

Você usa o Jev pra decidir o CAMINHO (qual categoria, qual template, qual time, qual prioridade) e usa o modelo de texto só pra escrever a saída daquele caminho escolhido

É como ter um roteador na frente e um redator atrás: se você conhece um roteador de rotas em API, é a mesma ideia, só que a rota é escolhida por um modelo

// pseudocódigo pra ilustrar o fluxo, os nomes NÃO são a API real
decisao  = jev(estado, pergunta_choice_categoria)
texto    = llm.redigir(template[decisao.categoria], estado)

Tome cuidado com a inversão desse desenho: pedir pro LLM decidir e pro Jev escrever não existe, a segunda metade simplesmente não é possível

Situação 2: quando a regra é determinística e cabe em código

Se um if, uma regex, uma consulta ao banco ou uma validação de schema resolvem o caso com 100% de certeza, botar modelo probabilístico ali é piorar de propósito

Você troca certeza por probabilidade, adiciona uma chamada de rede no caminho e ainda paga token de entrada por algo que o teu processador resolveria sem sair do lugar

O critério de corte é simples e dá pra aplicar em trinta segundos: a regra consegue ser escrita sem ambiguidade?

• "pedido acima do limite configurado vai pra análise manual" é determinístico, isso é código
• "CPF inválido é rejeitado" é determinístico, isso é código
• "esse pedido parece fraude?" NÃO é determinístico, aqui a decisão tipada faz sentido
• "esse comentário é tóxico?" também não é, aqui faz sentido

A linha divisória é a ambiguidade, não a complexidade. Regra gigante e chata, mas sem ambiguidade, continua sendo código

E se a regra é determinística mas ninguém consegue escrever ela, o problema não é de IA, é de alguém sentar e definir a regra de negócio 😅

Situação 3: quando falta contexto para decidir

Essa aqui é a mais traiçoeira porque o modelo responde mesmo assim

A documentação do System One orienta enviar apenas o contexto relevante pras perguntas atuais (pra evitar context rot) e usar a sua própria base de conhecimento em vez de confiar no que está guardado nos pesos

Ou seja: o Jev decide sobre o estado que VOCÊ mandou. Ele não vai atrás do que faltou

Se a informação que define o caso não está no estado enviado nem na tua base, o que volta é uma decisão de baixa confiança. E aí você não automatizou nada, só terceirizou o chute pra uma API

O teste prático é honesto e meio cruel: pegue o mesmo pacote de contexto que você mandaria pro modelo, entregue pra uma pessoa da tua equipe que conhece o negócio e pergunte se ela decide com aquilo. Se ela pedir mais informação, o modelo também precisaria

Falta de contexto não vira inteligência por causa do tipo da saída

Situação 4: quando a pergunta não cabe em Choice, Score ou Noul

O Jev trabalha com três tipos de pergunta documentados, as primitivas, e cada uma tem limite:

• Choice: uma opção dentro de um conjunto fixo, aceitando até 255 opções por pergunta (cada opção adicional custa alguns tokens)
• Score: uma posição numa escala descrita em níveis, com mínimo de 2 níveis e a API aceitando até 10
• Noul: sim ou não, e aqui tem um detalhe: como a distribuição só tem dois resultados, o próprio valor do noul já descreve tudo e não existe campo de confidence separado, diferente de Choice e Score

Se a tua pergunta não entra em nenhuma dessas formas, é a ferramenta errada. Simples assim

Os dois erros mais comuns aqui

O primeiro é o espaço de saída infinito. "Qual é o nome da empresa citada nesse texto?" não é Choice, é extração, e o conjunto de respostas possíveis não é fixo

O segundo é a pergunta multidimensional. A doc do Score alerta contra descrições que medem três coisas ao mesmo tempo, tipo "pontual e inteligente e experiente": misturar dimensões derruba a confiança

A correção é chata mas é a certa: quebrar em várias perguntas de uma dimensão só. E isso casa bem com o desenho do modelo, porque ele ingere o estado uma vez e avalia várias perguntas contra esse mesmo estado em paralelo, na mesma requisição

Massa, né? Três Scores limpos custam menos dor de cabeça que um Score confuso

Situação 5: quando o erro não pode ser escalado para um humano

A documentação oficial orienta usar a confiança pra decidir quando NÃO agir sozinho, num padrão de três faixas:

1. Confiança alta: age automaticamente
2. Confiança média: confirma, sinaliza pra revisão ou busca mais informação
3. Confiança baixa: não age, manda pra um humano, pede esclarecimento ou cai em outro sistema

Repare no que sustenta esse padrão inteiro: ele pressupõe que existe alguém, ou algum outro sistema, pra receber o caso incerto

Se no teu fluxo não existe esse caminho de saída, se a decisão precisa sair automática SEMPRE e não tem revisão possível, você não tem um sistema de confiança, tem risco puro em produção

E vale deixar claro como isso funciona na prática: a escalação é lógica da tua aplicação em cima da probabilidade que já veio na resposta. Não tem nova pergunta, não tem segunda chamada de API pra "perguntar se ele tem certeza"

A própria doc sugere testar os limiares plotando confiança contra acurácia nos teus próprios dados, ou seja, o número de corte é teu, não vem pronto

Aqui entra também o desenho do que fazer quando a resposta simplesmente não chega, que é um assunto vizinho: vale olhar timeout e fallback no Jev antes de colocar isso num caminho crítico

Jev, LLM ou código puro: qual usar em cada caso

A TypeSafe posiciona o Jev como atingindo nível de inteligência similar ao de LLMs existentes em tarefas de System One, sendo duas ordens de magnitude mais rápido e mais eficiente

No preço, o modelo jev-1.12 fica em US$ 0,042 por 1 milhão de tokens de entrada, com tokens de saída a US$ 0,00. Isso muda o cálculo em volume alto de decisão repetitiva, e não muda nada se a tua tarefa é escrever texto

A leitura da tabela é essa: o Jev ocupa a faixa do meio, entre "dá pra escrever a regra" e "precisa raciocinar e escrever". Quem tenta empurrar ele pras pontas se frustra

Veredito: quando o Jev vale e quando é moda

O Jev brilha num recorte bem definido: decisão fechada, repetitiva, em volume, onde você manda o estado uma vez e avalia várias perguntas em paralelo contra ele, com um plano claro pro que fazer quando a confiança cai

Dentro disso, o desenho é ótimo e o tipo da saída resolve um problema real de quem já cansou de fazer parse de JSON que o LLM resolveu formatar diferente hoje

Fora disso é moda. Trocar um LLM que funciona por uma decisão tipada só porque o conceito é novo é reescrever sistema pra ganhar nada

Se você quer ver o outro lado dessa moeda, tem um recorte de casos de decisão dentro do software que mostra onde ele realmente encaixa

E tem uma barreira prática que pesa agora: a lista de espera caiu em 20 de setembro de 2026, mas dois dias depois, em 22/09, a TypeSafe anunciou pausa temporária de novos cadastros por excesso de demanda. Contas existentes seguem funcionando e a empresa diz que quer reabrir o quanto antes, só que até hoje não tem reabertura confirmada

Redesenhar um sistema em torno de um modelo que você talvez não consiga acessar essa semana é decisão ruim, por melhor que o modelo seja

Conclusão

Antes de adotar, roda esse teste de três perguntas:

1. A saída é tipada? Se o entregável final é texto pra humano ler, não é Jev
2. A regra é ambígua? Se dá pra escrever sem ambiguidade, é código, e código é mais rápido, mais barato e 100% certo
3. O contexto está disponível? Se a informação que decide o caso não está no estado nem na tua base, você só vai comprar chute com confiança baixa

Passou nas três, aí sim vale a conversa

O próximo passo prático é mapear no teu sistema onde JÁ existe decisão fechada rodando hoje, aquelas classificações que alguém faz na mão ou que um prompt gigante tenta resolver no grito

E quando o acesso reabrir, os caminhos de integração já documentados dão o ponto de partida: o Jev aparece como modelo na Workers AI da Cloudflare, o Pydantic AI tem página de provider TypeSafe (Jev), e o AI SDK expõe as três primitivas na função evaluate com os nomes choice, score e boolean (esse boolean é o Noul)

Ta lindo? Não sei ainda, é cedo. Mas já dá pra saber onde ele NÃO serve, e isso vale mais que hype 😀

até o próximo post!