Por que coisas como TypeSafe IA não me interessam

#inteligencia-artificial#agentes-de-codigo#llms
16 de setembro de 2026 · 💬 Participe da Discussão
Se tem preguiça de ler, clique aqui pro TL;DR

Nos últimos dias apareceu um punhado de gente nos comentários, sempre com a mesma frase: “você já viu o TypeSafe?”. Isso liga um alarme automático na minha cabeça. Toda vez que várias pessoas diferentes aparecem recomendando a mesma coisa do nada, com o mesmo tom de “você precisa ver isso”, eu sinto cheiro de bot de propaganda ou de gente repetindo o que leu em algum grupo sem pensar duas vezes. Tem uma enxurrada de SaaS de IA brigando por atenção nesse mercado agora, e a maioria esmagadora é irrelevante pro que eu realmente faço no dia a dia.

Deixa eu adiantar minha regra antes de entrar no caso específico, porque ela vale mais que o caso em si.

Minha regra: não uso nada até doer não ter

Depois de mais de meio milhão de linha de código produzida com IA nos últimos meses, dezenas de projeto no ar, um benchmark inteiro rodado do zero três vezes, minha recomendação pra quem programa é direta: não use nenhuma ferramenta de orquestração ou camada intermediária até você sentir na pele que precisa de ajuda extra. Use o harness que você já gosta, Codex, opencode, Claude Code, sei lá qual, direto, sem intermediário, e esquece o resto.

Não vale nem a pena gastar tempo coletando pacote de skill de terceiro pra empilhar em cima do seu agente. Constrói, treina, junta experiência pro seu próprio caso de uso. Ninguém mais no mundo tem o seu projeto, o seu contexto, a sua base de código. O pacote de skill de outra pessoa foi desenhado pro problema dela, não pro seu.

Já bati nessa tecla faz um mês: quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Cria nome bonito pra encadear chamada de API, e do nada nasce curso, certificação e consultoria em cima do nome. O TypeSafe é só mais um capítulo da mesma história, então virou desculpa boa pra mostrar como eu decido se vale a pena até abrir a aba.

Pra guardar: não use ferramenta de orquestração ou camada intermediária até sentir na pele que precisa dela. Construa experiência pro seu próprio caso de uso, não colecione pacote de skill de outra pessoa.

O gatilho: TypeSafe

Abri o site e o post de lançamento deles, o Jev. Minha primeira impressão, bem superficial e crua: não gostei e não confiei. A home é um festival de jargão de IA empilhado, Kahneman aqui, Jevons ali, glifo decorativo, número de “193x mais rápido” sem o benchmark do lado. Na primeira olhada, nada daquilo faz sentido sozinho.

E tem o detalhe que sempre me deixa em guarda: toda vez que a primeira coisa que alguém diz sobre si mesmo é “eu sou um ex-pesquisador da OpenAI” ou parecido, eu desconfio primeiro e pergunto depois. Parece tentativa de colar credencial pra virar credível antes de qualquer prova real. O fundador do TypeSafe fala alto demais de si mesmo logo de cara, e isso por si só já é motivo pra apertar o botão de ceticismo.

Só que desconfiômetro ligado não é conclusão. É o ponto de partida pra investigar de verdade, não pra descartar sem olhar. Essa é a parte que eu quero mostrar aqui, meio que uma aula prática pra quem me acompanha: como eu uso IA pra correr rápido numa pesquisa preliminar, como eu leio a letra miúda antes de assinar embaixo de qualquer conclusão, minha ou de terceiro, e como eu movo a desconfiança inicial pra pesquisa de verdade até descobrir se eu estava certo ou só sendo chato.

E deixo isso registrado antes de continuar: eu posso estar errado em algum ponto específico daqui pra frente. Se você tiver contraprova de peso, manda nos comentários. Prefiro apanhar em público e corrigir o texto do que empurrar produto picareta pro meu público só porque não conferi direito.

Perguntei pras IAs, não confiei nas IAs

Mandei o mesmo prompt pro Grok e pro Claude: pesquisa isso a fundo, minha impressão inicial é muito cética, ex-OpenAI-researcher cheira a tentativa de colar credencial, o site é jargão pra todo lado, me diz qual é o discurso de venda de verdade, pra que serve na prática, e se a lógica deles, por trás do jargão, sequer faz sentido.

Os dois voltaram com pesquisa longa e detalhada, história parecida em ambos: a credencial do fundador é real, mas inflada; o produto é mais estreito e mais coerente do que a home deixa parecer; e o “não pode alucinar” é uma alegação de schema disfarçada de alegação de verdade.

Só que eu já entreguei minha própria conclusão dentro do prompt pras duas, então a concordância entre elas prova menos do que parece. Duas IAs concordando com a hipótese que eu mesmo escrevi no pedido não é confirmação independente de nada, é eco. Isso não invalida o que elas trouxeram, mas significa que eu não podia parar ali. Eu não ia publicar isso batendo o carimbo em cima do que duas IAs me contaram. Pedi uma nova rodada de pesquisa, agora comigo checando cada afirmação com fonte primária: o paper de verdade, o post de lançamento direto na fonte, os testes independentes de terceiros, e se “RLCD”, o nome que eles usam pro método de treino, é um paper de verdade ou só um nome bonito sem verificação nenhuma por trás.

O que o Jev realmente é

Tirando o marketing, o Jev é um classificador hospedado. Você manda um texto e uma lista de perguntinhas, cada uma com um tipo fixo de resposta:

  • escolher uma opção de uma lista;
  • dar uma nota numa régua;
  • responder sim ou não, com probabilidade.

Ele não escreve nada, não planeja nada, não conversa. Código decide o fluxo; o modelo só responde a perguntinha rápido, em paralelo, sem gerar texto livre.

Como produto, isso é razoável: tem gente que hoje manda um texto pra um LLM de chat só pra ele devolver um rótulo dentro de um JSON, espera oito segundos, e reza pro schema não quebrar. Trocar isso por uma chamada que devolve só o rótulo, rápido, é engenharia legítima. O problema nunca foi a ideia. É a embalagem em volta dela.

Os fatos que eu confirmei

Aqui estão as descobertas que realmente sobreviveram à checagem com fonte primária, não o que a IA me contou de segunda mão.

A credencial do fundador é real, mas a página da própria empresa exagera de um jeito que dá pra provar que é exagero. O Diogo Almeida é o quarto de vinte autores do paper do InstructGPT, publicado e revisado por pares na NeurIPS 2022, a conferência de peso da área. Autor de verdade, posição de peso, paper de verdade. Só que a página da equipe do TypeSafe diz isto, ao pé da letra:

“Diogo co-inventou o RLHF e o InstructGPT, os métodos que levaram ao ChatGPT e ao GPT-4.”

RLHF é de 2017, cinco anos antes, assinado por outro time (Christiano, Leike, Amodei e companhia), sem o Diogo em lugar nenhum. Ele ajudou a aplicar RLHF pra treinar o InstructGPT. Não inventou RLHF. É a mesma inflação de currículo que eu já desconfiava antes de checar qualquer coisa, só que agora com prova.

O financiamento é real: $40 milhões de seed liderado pela DCVC, valuation de $200 milhões confirmado pela Forbes de forma independente, não só pelo press release da própria empresa. Isso é dinheiro sério, não é golpe de um cara sozinho numa garagem.

O post de lançamento admite, com as próprias palavras, exatamente o que eu suspeitava sobre o gráfico de “zero alucinação”:

“Nosso número não é empírico. Como o casamento com o schema é garantido, podemos colocar 0% no gráfico com confiança.”

Ou seja: o zero não vem de medir nada, vem de garantir que a resposta sempre cabe dentro das opções permitidas. Isso impede o modelo de inventar uma quinta categoria quando só existem quatro. Não impede o modelo de escolher a categoria errada com confiança de 93%. É a mesma crítica que o The Register publicou: a comparação não é justa porque a saída não é linguagem, e resposta com tipo válido ainda pode estar simplesmente errada.

O próprio post também admite qual é a régua usada pra medir “precisão”: “usamos a média do GPT-6 Astra e do Fable 5.1 como resposta de referência”, e completa admitindo que isso “gera viés a favor dos modelos da OpenAI e da Anthropic”. Ou seja, o gabarito é a média do que dois outros modelos de outras empresas responderam, com viés admitido pelos próprios autores, não verdade objetiva medida por humano.

O único teste feito por alguém de fora, o da newsletter Every, achou o Jev cerca de vinte e cinco vezes mais rápido, 0,35 segundo contra 8,83 segundos por passagem, e muito mais barato que o Claude Fable 5.1, só que pegando seis de sete defeitos plantados contra os sete de sete do Fable. Mais rápido e mais barato, de verdade. Também mais fraco, de verdade.

E o achado que nem o Grok nem o Claude bateram o martelo total, mas que confirmei sozinho: o nome do método de treino deles, RLCD, já existe. Tem um paper de verdade, revisado por pares, de 2023, Reinforcement Learning from Contrastive Distillation, de um time completamente diferente, com código dos próprios autores publicado no GitHub da Facebook Research, já que dois dos cinco autores são da Meta. É uma técnica diferente, sem relação nenhuma com o que o TypeSafe descreve. O RLCD deles não tem paper, não tem arquitetura publicada, não tem nada pra revisar. É nome emprestado de pesquisa alheia colado num método que, até prova em contrário, é só um parágrafo de blog.

Minha desconfiança tinha fundamento?

Tinha. A ideia de produto é legítima e razoavelmente coerente por trás do jargão: decisão fechada e barata em volume alto é um problema real que hoje é resolvido de um jeito lento e caro, gerando texto livre só pra depois extrair um JSON dele. Resolver isso rápido tem valor de verdade.

Mas “alegação exagerada e sem muita diferença prática” também se confirma ponto a ponto:

  • o currículo do fundador é inflado de um jeito que dá pra provar com data de publicação;
  • o número mais chamativo do lançamento, zero alucinação, é definição de schema, não medição;
  • o gabarito de precisão é média de LLM de outra empresa, não verdade objetiva;
  • o único teste de fora achou o produto mais fraco que o modelo que ele promete substituir;
  • o nome do método de treino mais citado colide com um paper de verdade que não tem nada a ver com eles.

Isso não é motivo pra chamar de golpe. É motivo de sobra pra chamar de “produto pequeno com discurso grande demais pro que ele realmente entrega”. E antes de eu confiar meu dado a mais um terceiro que eu não conheço, com API fechada, lista de espera e sem paper publicado de nada que sustente o nome bonito, o cálculo de risco contra benefício não fecha pro meu caso de uso.

Pra guardar: credencial real não é a mesma coisa que credencial honesta. Confira a data de publicação antes de acreditar no currículo, e confira o paper antes de acreditar no nome do método.

Isso não é decreto final sobre o TypeSafe nem sobre o currículo do Diogo Almeida. É o resultado da checagem que consegui fazer com o que estava acessível até agora. Se você achar o paper que eu não achei, o benchmark independente que eu não vi, ou qualquer prova que derrube um ponto específico, os comentários estão abertos e eu leio. O objetivo aqui nunca foi provar que eu sou infalível. É mostrar como sair de “sinto cheiro de golpe” pra “aqui está a prova”, e estar disposto a admitir quando a prova aponta pro lado contrário.

O “193x mais rápido” denuncia um jeito errado de usar LLM

Voltando pro Jev: o choque de “193x mais rápido que um LLM” só existe porque a comparação é contra um jeito específico, e comum, de usar LLM. Manda um texto pra um modelo de chat, pede pra ele devolver um rótulo, espera o modelo escrever uma resposta inteira em linguagem natural, e depois faz o seu código catar esse rótulo lá dentro de um parágrafo ou de um JSON solto na resposta. Isso é lento, caro, e cheio de chance de o schema quebrar.

O Jev existe justamente porque essa comparação é fácil de vencer. Ele não gera texto livre, só responde perguntas de tipo fixo, uma opção de uma lista, uma nota numa régua, sim ou não com probabilidade. É o que a própria documentação chama de primitivas: Choice, Score e Noul. Trocar “LLM escrevendo um parágrafo pra você extrair um rótulo dele depois” por “chamada que já devolve o rótulo pronto” é, sim, uma vitória de engenharia. Só que essa vitória não vem de ter inventado uma categoria nova de modelo. Vem de parar de usar LLM de chat pra fazer um trabalho de classificação estruturada.

E aqui é onde eu acho que a reação de espanto de muita gente com o número do Jev revela o hábito errado: o LLM nunca devia estar gerando texto livre pra decisão fechada e repetida em cima do mesmo tipo de pergunta. Se seu produto precisa, toda hora, decidir entre um punhado fixo de categorias, a resposta certa não é implorar pro LLM “responda só com o JSON, por favor” e torcer. É construir, ou usar, um classificador de verdade pra aquele trabalho específico.

E isso não é ideia nova nem exclusividade do Jev. Existe desde muito antes dele:

O Jev empacota um pedaço disso numa API paga e conveniente. Não inventou a categoria. E tem até alternativa aberta pro mesmo padrão, o Laya servido pelo Arbiter, rodando local, sem depender de terceiro nenhum.

Então, respondendo direto: minha desconfiança inicial de que “gente estava usando LLM errado” tem fundamento real, mas com uma ressalva importante. Não é verdade que LLM é incapaz de classificar. Classificação zero-shot com LLM funciona e está documentada desde 2019. O erro específico é mais estreito: usar um LLM de chat generalista, sem restrição de formato, pra gerar uma resposta livre da qual você extrai um rótulo na mão, quando o seu problema já é um problema de classificação fechada e repetida. Esse é o antipadrão. A cura não é necessariamente comprar o Jev, é ou aplicar saída estruturada no LLM que você já usa, ou treinar um classificador de verdade pra aquele trabalho específico, dependendo do volume e da precisão que você precisa.

E “virar classificador” também não é bala de prata contra alucinação, nem no próprio Jev. Existem dois problemas diferentes escondidos atrás da palavra “alucinar”, e trocar de produto só resolve um deles:

  1. Alucinação de formato: o modelo inventa uma categoria que não existe, ou devolve algo fora do schema. Saída estruturada resolve isso, seja no Jev, seja em qualquer LLM com decodificação restrita.
  2. Erro de julgamento: o modelo escolhe a categoria errada, dentro das opções válidas, com confiança alta. Isso não desaparece só porque a saída tem tipo fixo.

O próprio documento de limitações do TypeSafe admite interpretação literal, contagem numérica fraca, erro de comparação de data, degradação com contexto irrelevante, e suscetibilidade a manipulação adversarial no próprio Jev. E o teste independente com 2 mil e-mails de phishing achou o veredito direto do Jev em 62,6% de acerto contra 81,3% do Claude Haiku 4.5, mais rápido e mais barato, só que menos preciso que o LLM de chat que ele se propõe a substituir. Um teste separado com 27 tickets achou o Jev empatado com um modelo de chat barato, amostra pequena demais pra virar regra, mas o suficiente pra deixar claro que “virou classificador” não é sinônimo automático de “ficou mais preciso”.

Justiça seja feita com o mesmo teste de phishing: quando em vez de pedir um veredito único, o Jev responde cinco perguntas de sinal separadas e o código combina as cinco numa decisão, a acurácia sobe pra 95%, batendo até a versão composta do Claude com os mesmos cinco sinais (93,2%). Isso não invalida o número anterior, o veredito único de 62,6% continua sendo o veredito único de 62,6%, mas reforça exatamente o argumento deste texto: decompor a decisão em perguntas de tipo fixo e deixar o código compor o resultado bate um LLM respondendo tudo de uma vez, seja isso feito com Jev, com saída estruturada, ou com um classificador treinado pra aquele sinal específico.

Pra guardar: se o seu problema é decidir a mesma coisa, do mesmo jeito, várias vezes, construa ou use um classificador de verdade pra esse trabalho específico, com saída estruturada ou modelo dedicado. O ganho de trocar isso é real. O que não é automático é achar que qualquer produto que se chama “classificador” vai acertar mais que o LLM que ele substitui, porque às vezes acerta menos.

E essa história de economizar token?

O caso do TypeSafe me lembrou de uma implicância separada que eu já queria colocar no papel, e não é sobre eles especificamente: a promessa de economia de token e de custo que praticamente todo produto desse tipo vende. É sobre a categoria inteira de ferramenta que promete “economize X vezes gastando com a gente em vez de gastar direto com seu provedor”, não uma acusação a mais contra o TypeSafe.

Toda nova versão de modelo, e toda atualização de harness, muda a conta inteira, às vezes de um jeito violento. Quando eu pulei do GPT Sol pro Astra, vi minha cota semanal de assinatura secar muito mais rápido do que eu esperava, sem eu ter mudado nada no meu jeito de trabalhar. Foi só o modelo novo consumindo diferente. Isso é a regra desse mercado, não exceção: OpenAI, Anthropic e companhia vão continuar mexendo em preço, em quantização, em política de cache, e em quanto raciocínio cada modelo gasta por baixo dos panos, com ou sem o meu consentimento.

Construir sua estratégia em cima de “economizar token” é apostar numa fundação que muda de mês em mês, decidida por gente que não te consulta. Uma ferramenta de meio de caminho que promete cortar custo hoje pode ficar irrelevante, ou pior, ficar mais cara que o caminho direto, na próxima atualização de modelo. É o mesmo motivo pelo qual eu não uso orquestrador nem framework de skill: quando o alicerce muda toda hora, complicar a estrutura em cima dele é ficar refém de manutenção sem necessidade.

Eu prefiro gastar token no talo e focar se o resultado que eu tiro daquele gasto vale a pena. Até agora, com minha assinatura, estou satisfeito com o que consigo produzir. Não sinto vontade nenhuma de gastar tempo cortando token, um esforço que sempre carrega o risco de piorar a qualidade da resposta em troca de uma economia que a próxima versão do modelo pode apagar sozinha.

Pra guardar: não construa estratégia em cima de preço e consumo de token, porque isso muda de mês em mês por decisão de gente que não te consulta. Meça se o resultado vale o gasto, não o gasto em si.

E se um dia eu conseguir gastar token o suficiente pra ferver um lago inteiro com o calor do datacenter, eu vou gastar com o maior prazer do mundo. É minha vingança pessoal contra quem me obrigou a usar canudo de papel que desmancha na boca por tantos anos.