Projeto novo do zero: começar já com o Jev ou prototipar com um LLM e trocar depois?

Todo projeto novo tem aquele momento em que você decide o formato da resposta do modelo, e essa escolha costuma durar mais que o projeto inteiro

A pergunta ficou concreta agora: a TypeSafe lançou o Jev em 15 de setembro de 2026, e desde então o acesso deixou de ter lista de espera, qualquer pessoa cadastra no console e sai usando

Então vale sentar e pensar de verdade: no commit inicial, você já coloca decisão tipada no lugar certo, ou prototipa rápido com prompt e troca depois? 🙂

O que é o Jev e por que ele muda a decisão de arquitetura

O Jev é o primeiro modelo do que a TypeSafe chama de System One: ele recebe estado não estruturado e devolve decisão tipada com probabilidade calibrada, em vez de texto

Se você conhece a diferença entre chamar uma API que devolve JSON e chamar uma que devolve HTML pra você raspar, é mais ou menos essa a sensação

A API tem três tipos de pergunta (as primitivas), e toda resposta vem com um valor de confiança entre 0 e 1:

• Choice: escolher uma opção de um conjunto
• Score: posição em uma escala de níveis ordenados
• Noul: sim/não com a probabilidade de sim

O modelo disponível hoje na documentação é o jev-1.13, acessível pela rota jev-latest

E tem uma coisa que a própria documentação faz questão de dizer: o Jev não substitui o LLM que roda atrás do Claude Code, Cursor, opencode ou Copilot

O agente continua escrevendo o código, e o código é que chama o Jev pra decidir

Ou seja: a pergunta não é Jev ou LLM em tudo, é onde cada um entra no seu desenho… e é exatamente isso que muda quando você decide no primeiro commit em vez de decidir depois. Se quiser ir mais fundo nesse recorte, escrevi sobre trocar o prompt por uma decisão tipada em outro post

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

Começar com o Jev x prototipar com LLM e migrar: comparação direta

Os números abaixo de acerto, latência e custo por caso vêm do benchmark de 4 workflows publicado pela própria TypeSafe, que mede concordância com rótulos de consenso do GPT-6 Astra e do Claude Fable 5.1, e não verdade verificada de forma independente

Repara no que salta: o acerto do Jev na tabela fica na faixa do modelo mais fraco da comparação, não do mais forte

O que muda de ordem de grandeza é latência e custo… e é aí que mora a decisão de arquitetura, não no acerto

Como cada caminho desenha o seu código (e onde o retrabalho aparece)

Aqui está o ponto que ninguém fala no greenfield: o formato da saída desenha o código todo em volta dela

Com saída tipada, o padrão recomendado pela TypeSafe é decompor a decisão em perguntas atômicas e combinar as respostas com regra própria, no seu código

E perguntas sobre o mesmo estado rodam em paralelo, sem round trips extras

Na prática o seu módulo de decisão vira isso: uma lista de perguntas pequenas, uma função que combina as respostas e thresholds que você ajusta olhando a confiança

Com texto livre, o desenho nasce diferente. Nasce um prompt grande que tenta fazer tudo de uma vez, e em volta dele:

• um parser pra transformar a resposta em algo que o código entenda
• um retry pra quando o modelo devolve fora do formato
• uma validação de schema pra segurar o que passou
• e tratamento de caso estranho que você só descobre em produção

Nenhuma dessas quatro coisas é feature. É estrutura que existe só porque a saída é texto

E é por isso que migrar depois custa: você não troca uma chamada de API, você desmonta o prompt gigante em perguntas atômicas, joga o parser fora, reescreve os testes que validavam string e ainda reaprende onde ficava cada regra que tinha virado frase dentro do prompt

Já vi projeto inteiro em que a regra de negócio morava no prompt, e ninguém queria mexer

Tome cuidado com isso desde o começo: regra de negócio em português dentro de prompt é regra que não tem teste

Sinais de que o seu projeto nunca vai precisar de texto gerado

Checklist rápido. Se a maioria bater, você provavelmente pode começar tipado no primeiro commit:

• a saída do modelo alimenta um if, e não uma tela
• a resposta define um roteamento (pra qual fila, pra qual time, pra qual fluxo)
• a saída vira um score de risco, ou manda o caso pra uma fila de moderação
• a saída é um gate: libera ou não libera a execução de uma tool call
• ninguém lê a resposta do modelo, só o código lê
• você precisa de confiança numérica pra calibrar um threshold, e não de uma explicação bonita

Esse último é o mais subestimado. Com Choice, Score e Noul você tem um número de 0 a 1 por resposta, dá pra ter comportamento diferente pra caso confiante e caso duvidoso

Um exemplo real do formato, reportado pelo VentureBeat: a LangChain publicou um middleware que usa o Jev pra decidir se tool calls rodam, excluindo a saída de ferramenta da entrada do classificador

A decisão é do Jev, o texto continua sendo trabalho do LLM, e a separação de papéis fica limpa. Falei sobre dividir os papéis dentro do agente com mais calma em outro texto

E o contraponto honesto: se em algum momento alguém precisa ler a saída (uma justificativa pro usuário, um resumo pro analista, uma mensagem), o texto volta pro projeto

Nesse caso não é Jev ou LLM, são os dois: o Jev decide, o LLM escreve

Sinais de que é melhor prototipar com LLM primeiro

Agora o outro lado, e esse lado é mais forte do que o hype sugere

Prototipar com prompt primeiro faz muito sentido quando:

• o conjunto de opções ainda não existe. Choice exige que você saiba quais são as categorias, e às vezes descobrir as categorias É o projeto
• o problema é aritmética ou precisão numérica: a documentação do jev-1.13 diz pra deixar conta no código
• envolve data: o modelo lê data como texto, comparar ou medir intervalo é pouco confiável
• o enunciado tem negação e escopo que precisam de interpretação, porque o modelo responde ao pé da letra
• a decisão depende de indireção e múltiplos saltos, onde a própria doc registra perda de acerto
• o estado é grande e cheio de coisa que não tem relação com a decisão: detalhe irrelevante age como distrator (o tal context rot) e ainda dificulta achar o que causou a resposta errada

Repara numa coisa: essa lista não é de defeito escondido, é a própria TypeSafe documentando onde o modelo é irregular

E aqui o LLM não é rascunho descartável. Parte disso continua no LLM pra sempre, e parte vai virar código determinístico mesmo (conta, data, comparação numérica)

Como começar tipado no commit inicial (e manter porta de saída)

Se o checklist bateu e você vai começar tipado, o caminho mínimo é esse

1. Crie a conta no console em console.typesafe.ai. Não tem mais lista de espera, e contas novas recebem US$ 5 de crédito promocional (cerca de 120 milhões de tokens de entrada no preço de tabela)

O erro comum aqui: achar que crédito grátis é licença pra mandar o estado inteiro sem filtrar. Não é só custo, estado inchado derruba acurácia

2. Instale o SDK da linguagem do projeto

# Python (>= 3.10)
pip install typesafe-sdk

# JavaScript / TypeScript (Node 20+)
npm install @typesafe-ai/sdk

O erro comum: subir com versão velha de runtime e ficar caçando erro de import que não é erro de import

3. Exporte a chave no ambiente, porque o cliente lê TYPESAFE_API_KEY sozinho e já usa jev-latest por padrão

export TYPESAFE_API_KEY=sua_chave_aqui

O erro comum: commitar a chave no primeiro push do projeto novo. Clássico… 😅

4. Escreva as perguntas atômicas antes de escrever qualquer outra coisa, e só depois chame client.system_one() com o estado e a lista de perguntas, lendo o resultado em response.answers

# importe Choice, Noul, Score e TypeSafeClient do SDK que você instalou

client = TypeSafeClient()   # lê TYPESAFE_API_KEY do ambiente e usa jev-latest

response = client.system_one(
    state=estado_do_caso,   # o estado não estruturado, já filtrado
    questions=[
        Choice(...),        # escolher uma opção de um conjunto
        Score(...),         # posição em uma escala de níveis ordenados
        Noul(...),          # sim/não, com a probabilidade de sim
    ],
)

for answer in response.answers:
    print(answer)

Os argumentos exatos de cada primitiva estão no quickstart oficial da TypeSafe, vale abrir e copiar de lá em vez de chutar

O erro comum deste passo: fazer uma pergunta composta (algo do tipo qual o tipo E qual a urgência E se precisa de humano) em vez de três perguntas separadas. Perguntas sobre o mesmo estado rodam em paralelo, então decompor não te custa round trip, e ainda te dá confiança separada por dimensão

5. Deixe aritmética, data e comparação numérica no código, sempre. Combine as respostas do modelo com a sua regra própria, em Python ou TypeScript mesmo

O erro comum: pedir pro modelo calcular o total, comparar dois prazos ou dizer se passou de 30 dias. Isso está listado como ponto irregular do jev-1.13

6. Se você não usa SDK, o endpoint HTTP oficial da API System One é POST https://api.typesafe.ai/v1/systemone

7. Se o seu fluxo é com agente de código, a TypeSafe mantém uma skill oficial no repositório typesafe-ai/skills

# Claude Code
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai
# e invoque com: /typesafe:typesafe-ai

# outros agentes
npx skills add typesafe-ai/skills --skill typesafe-ai

O erro comum: instalar a skill e esperar que o agente troque o modelo dele pelo Jev. Não é isso. O agente segue com o LLM dele e escreve o código que chama o Jev

8. Guarde a porta de saída. O Jev também está listado no OpenRouter, chamado pela Decisions API (POST /api/alpha/decisions) e não pelo endpoint de chat compatível com OpenAI, e o Pydantic AI documenta o provedor TypeSafe (Jev)

Ou seja: dá pra isolar a camada de decisão atrás de uma interface sua desde o commit inicial, e trocar o provedor depois sem mexer na regra de negócio

Veredito: qual caminho escolher no seu projeto novo

Vou ser direto por perfil de projeto

Projeto cuja saída só o código lê (roteamento, moderação, score de risco, gate de tool call): comece tipado. O retrabalho de migrar parser, retry e prompt gigante depois é caro e chato, e o ganho de latência e custo por caso na tabela do fornecedor é de outra ordem de grandeza

Projeto em que as categorias ainda não existem: prototipe com prompt. Use o LLM pra descobrir quais são as opções, e só então escreva as perguntas atômicas

Projeto que precisa de texto pro usuário final: os dois convivem, e o desenho bom é decisão de um lado, redação do outro

Agora a parte honesta, que é a que importa num post de decisão

O benchmark que embasa os números é da própria TypeSafe, e os rótulos vêm de consenso entre GPT-6 Astra e Claude Fable 5.1, ou seja, mede concordância com outros modelos, não verdade verificada

E nele o Jev faz 67,8% de acerto, contra 74,1% do melhor concorrente da tabela. Isso não é detalhe, isso é o trade-off explícito: você troca um naco de acerto por latência e custo

Tem mais: a decisão do Jev pode ser influenciada por conteúdo adversarial dentro do próprio estado. Por isso o middleware da LangChain exclui saída de ferramenta da entrada do classificador, e a orientação é parear com aprovação humana em ações consequentes

A documentação do Pydantic ainda alerta que reordenar as opções pode mudar a resposta

Traduzindo: use o Jev junto de checagens determinísticas, nunca no lugar delas

Conclusão

Se eu fosse abrir um projeto novo amanhã, faria nesta ordem

Primeiro, escolheria a decisão mais estável do sistema, aquela cujas opções não vão mudar toda semana

Segundo, escreveria as perguntas atômicas dela em papel, ANTES de escrever qualquer prompt. Se elas saem fácil, é sinal forte de que o projeto pode nascer tipado. Se elas não saem, é sinal de que você ainda está descobrindo o problema, e aí o protótipo com prompt é o caminho

Terceiro, testaria com o crédito inicial antes de fixar a arquitetura, porque decidir isso no slide é fácil, decidir olhando a confiança de 0 a 1 nos seus próprios casos é outra conversa

No fim, Jev ou LLM é menos uma briga e mais uma divisão de trabalho… e quem define a divisão é quem lê a saída

Até o próximo post! 😀