Quando trocar if/else e regex por uma decisão do Jev?

Toda cascata de if/else começa limpa e termina como um monumento ao caso de borda que ninguém previu

O regex nasce com duas alternações, ganha mais três no sprint seguinte, e seis meses depois tem um comentário em cima escrito "não mexer" 😅

Em 15 de setembro de 2026 a TypeSafe AI anunciou o Jev, o primeiro modelo público da classe System One, ainda em early access. A proposta é bem específica: ele não escreve texto, ele recebe o estado do programa e perguntas tipadas, e devolve decisões tipadas com probabilidade. É outra ferramenta pro mesmo lugar onde hoje mora aquela sua condição feia

E a pergunta que importa não é "o Jev é bom?", é: qual condição do meu código deixou de ser regra e virou julgamento?

if/else e regex x decisão do Jev: comparação direta

<table> <thead> <tr><th>Critério</th><th>if/else e regex</th><th>Decisão do Jev</th></tr> </thead> <tbody> <tr><td>Tipo de entrada</td><td>Estrutura conhecida, formato fechado</td><td>Texto não estruturado ou state em JSON estruturado</td></tr> <tr><td>Previsibilidade</td><td>Determinística: mesma entrada, mesma saída</td><td>Probabilística: opção escolhida + probabilidade + confiança</td></tr> <tr><td>Custo por decisão</td><td>Zero (é CPU do seu processo)</td><td>US$ 0,042 por 1M tokens de input, tokens de saída a US$ 0,00</td></tr> <tr><td>Latência</td><td>Microssegundos</td><td>70 a 500 ms ponta a ponta, número declarado pela TypeSafe</td></tr> <tr><td>Comparação de velocidade</td><td>Não se aplica</td><td>20x a 200x mais rápido que LLMs comparáveis, também segundo a TypeSafe, em avaliação interna</td></tr> <tr><td>Auditabilidade</td><td>Você lê a linha e sabe por que caiu ali</td><td>Você lê a distribuição de probabilidade e a confiança</td></tr> <tr><td>Caso novo aparece</td><td>Mais uma alternação, mais um <code>elif</code></td><td>Ajuste na descrição da pergunta tipada</td></tr> <tr><td>Limite de contexto</td><td>Sem limite relevante</td><td>64k pro state mais todas as perguntas somadas, 32k pro state mais a pergunta isolada mais longa</td></tr> <tr><td>Entrada de imagem</td><td>Não se aplica</td><td>Fora de escopo: só entrada textual ou estruturada em texto</td></tr> </tbody> </table>

Se liga num detalhe importante da tabela: os números de velocidade e a comparação com outras LLMs vêm de benchmark interno da própria TypeSafe. Não tem leaderboard público, não tem pesos abertos, não tem caminho anunciado de self-hosting. Isso não invalida nada, só muda o peso que você dá ao dado 🙂

E o preço aparece igual nos dois lugares: na documentação e na listagem viva do OpenRouter, onde a versão corrente da família aparece como jev-1.13

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Sinais de que sua cascata de if/else pediu socorro

Não é sobre o tamanho do arquivo, é sobre o TIPO de decisão que ele tenta tomar. Se você reconhecer sua base em dois ou três itens abaixo, já vale pensar no assunto

• Seu regex tem cinco alternações só pra cobrir variações de escrita. cancel(ar|amento|a)?|cancelei|quero cancelar e por aí vai… cada alternação nova é a confissão de que a informação não está na forma, está no sentido. Forma é regex, sentido não é

• A condição tenta inferir intenção. "Se a mensagem contém ‘urgente’ então prioridade alta" quebra no cliente educado que escreve "quando puderem dar uma olhada, tá parando minha operação". Intenção não tem marcador léxico confiável

• A condição tenta medir tom. Detectar frustração por palavrão é um proxy ruim. O cliente mais irritado da sua fila costuma ser o mais formal, e isso nenhum in de string pega

• A lista de palavras-chave nunca fecha. Se toda semana alguém abre PR adicionando um termo na constante TERMOS_SPAM, aquela lista não é uma regra, é uma tentativa de aproximar um julgamento por enumeração. Enumeração de julgamento nunca converge

• Você classifica texto livre digitado pelo usuário. Ticket, comentário, campo "descreva seu problema". Aqui o input não tem contrato, e código determinístico precisa de contrato pra funcionar

O fio comum: nos cinco casos você não está aplicando uma regra que conhece, você está PEDINDO PRA UM HUMANO ler e dizer o que é. Esse é o território que a documentação da TypeSafe chama de julgamento semântico

Quando NÃO trocar: os casos em que a regra escrita à mão ganha

E olha que interessante: quem diz isso é a própria documentação da TypeSafe

A orientação oficial é direta: não peça ao modelo algo que o código consegue calcular com exatidão, e deixe em paz o código determinístico que já decide certo. Um if que não custa nada continua melhor que uma chamada de modelo que pode errar

Mantenha a regra escrita à mão quando:

• Ela já acerta. Sério, é isso. Não tem prêmio por modernizar condição que funciona
• É cálculo aritmético. Soma de carrinho, rateio, desconto, imposto. Aritmética precisa está listada como fora de escopo do Jev
• É busca exata em base. WHERE cpf = ? não vira pergunta probabilística, isso é um lookup
• É validação de formato fechado. CPF, CEP, e-mail com formato definido, código de rastreio. Formato tem gramática, e gramática é exatamente onde regex brilha
• É execução de ação. Disparar e-mail, gravar no banco, chamar o gateway. O Jev decide, o seu software executa

E o fora de escopo documentado, pra não restar dúvida: escrever ou reescrever texto, resumir transcrição, aritmética precisa e qualquer entrada que seja imagem. Se a sua necessidade é gerar string, o Jev não é o endereço, porque ele simplesmente não gera string

Essa lógica de escolher a ferramenta pela natureza da tarefa é a mesma que vale na hora de decidir entre API e chat do Claude: a pergunta certa nunca é qual é mais poderoso, é qual encaixa no formato do problema

As três primitivas e qual substitui qual tipo de condição

A API expõe três primitivas de pergunta, e cada uma tem um par bem óbvio no seu código atual. Bora mapear?

Noul: substitui o if booleano de julgamento

Noul é a pergunta sim/não, e a resposta é um único número: a probabilidade de a resposta ser sim

É o par direto daquele if mensagem_parece_reclamacao(texto): que hoje é uma função de 40 linhas com lista de palavra. Em vez de um booleano cuspido por heurística, você recebe um número e decide o corte

Choice: substitui switch/case e cadeia de elif

Choice seleciona uma opção de um conjunto que você define, e devolve a opção escolhida, a probabilidade de CADA opção e um valor de confiança

É o roteamento clássico: ticket vai pra financeiro, suporte técnico ou comercial. A diferença pro seu elif é que você não recebe só o vencedor, recebe o formato da disputa. Um caso 0.51 contra 0.49 e um caso 0.97 contra 0.01 são coisas MUITO diferentes, e o elif te entregava os dois iguais

Score: substitui faixas de corte

Score avalia o state contra níveis ordenados e descritivos que você mesmo define, e devolve a nota, a probabilidade de cada nível e a confiança

Aquele if score > 0.7 com número mágico que ninguém lembra de onde saiu? Vira nível descrito em português. Em vez de calibrar um float no escuro, você escreve o que cada degrau significa

E tem um detalhe que muda o desenho da solução: as três podem ser misturadas na mesma chamada de API. O Jev ingere o state uma vez e avalia todas as perguntas contra ele em paralelo e isoladamente

Ou seja: classificar o ticket (Choice), medir a urgência (Score) e checar se precisa de aprovação humana (Noul) sai numa única passagem. Uma coisa que a documentação reforça, aliás, é não esconder vários julgamentos dentro de uma mesma pergunta. Três perguntas pequenas, não uma pergunta gigante

Veredito: o critério de decisão em quatro perguntas

Na hora de olhar uma condição específica do seu código e resolver, faz essas quatro perguntas na ordem:

1. A regra é conhecida e exata? Se você consegue escrever a regra completa sem dizer "depende do contexto", fica no código. Encerrado
2. O código consegue calcular isso? Cálculo, busca exata, validação de formato: código. Essa é meta-regra oficial da TypeSafe, não opinião minha
3. A lista de exceções está crescendo? Se todo mês entra mais um caso de borda naquela função, ela não é uma regra, é uma aproximação de julgamento. Aí sim vale a pergunta tipada
4. O custo do erro justifica escalar? Decisão barata de errar pode rodar automática. Decisão cara precisa de rede

E o padrão recomendado não é trocar uma coisa pela outra, é combinar: resposta do Jev MAIS checagens determinísticas no código

A confiança vem de 0 a 1 em Choice e Score, derivada do formato da distribuição. Você usa ela como chave: acima do threshold, age automático; abaixo, escala pra uma pessoa ou pra um modelo de raciocínio. E o threshold não se chuta, se mede nos seus próprios dados, subindo conforme o custo do erro cresce

O ponto que fecha o raciocínio: o software continua dono do workflow. O Jev responde perguntas, quem orquestra é o seu código

As ressalvas honestas antes de você planejar migração grande: o acesso direto à API segue em early access com lista de espera, as comparações de velocidade são de avaliação interna sem leaderboard público, e não tem pesos abertos nem self-hosting anunciado. Isso muda o cálculo de risco de quem depende de infra própria

E vale a mesma disciplina de usar cada ferramenta pra o que ela faz melhor, sem misturar

Conteúdo complementar do canal

Pra quem acompanha o blog, este vídeo do canal traz o papo sobre atualização de stack e quando uma mudança de versão pede reaprender de verdade:

Próximo passo: testar a hipótese antes de reescrever a cascata

Não reescreve a cascata inteira, isso é receita de fim de semana perdido 😛

O caminho é bem mais chato e bem mais seguro:

1. Isole UMA condição semântica, de preferência aquela que mais te dá manutenção. Aquele regex com nome de arquivo utils_final_v3.py
2. Escreva a pergunta tipada equivalente. Noul se é sim/não, Choice se é roteamento, Score se é faixa
3. Compare contra a regra atual nos SEUS dados. Não no exemplo da doc, nos seus casos reais, incluindo os de borda que te fizeram adicionar alternação no regex
4. Só então decide. Se a regra atual ganha, você acabou de economizar uma chamada de API e ganhar um argumento pro time

Os caminhos de acesso hoje: o modelo está disponível pelo Vercel AI Gateway desde o anúncio de 16/09/2026, está listado no OpenRouter sob o provedor Typesafe (typesafe/jev-1.13 e jev-latest), e a API direta da TypeSafe tem waitlist

Se o seu fluxo é de agente de código, a TypeSafe mantém uma agent skill oficial no repositório typesafe-ai/skills. No Claude Code a instalação é por plugin:

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

Depois é só invocar com /typesafe:typesafe-ai

Tome cuidado com um detalhe aqui: a instalação é local ao projeto por padrão. Se você quer a skill disponível em tudo, precisa usar a flag -g pra instalar globalmente. Já vi gente achando que quebrou porque abriu outro projeto e o comando sumiu…

O cliente oficial, por sua vez, lê a chave TYPESAFE_API_KEY do ambiente e chama jev-latest por padrão, que é o apelido estável apontando pro modelo mais recente da família

No fim das contas, a resposta pra quando usar o Jev é mais simples do que o hype sugere: quando a sua condição parou de ser uma regra e virou uma opinião. Enquanto for regra, o if ganha, é grátis e nunca erra 😀

Até o próximo post!