Jev vs. Clef: qual decision model funciona melhor na prática?

Autoria: Rafael Quintanilha – QuantBrasil · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Jev vs Clef: qual decision model funciona melhor na prática? · Canal: Rafael Quintanilha – QuantBrasil · 27:13 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Modelos de IA, Modelos locais e open source

Resumo

O vídeo explica o que são decision models e compara Jev com Clef, da Cloudflare, destacando diferenças de recursos, preço, contexto e latência. Clef aceita imagens, tem context window maior e é open source, enquanto Jev se mostrou mais rápido e, nos testes apresentados, teve resultados considerados melhores. O apresentador demonstra uma aplicação que recomenda aulas com base no tema que a pessoa quer estudar e alterna entre os dois modelos usando uma interface compatível. A conclusão é que Jev foi superior nessa comparação, mas Clef pode ser mais adequado quando é necessário processar imagens ou mais contexto.

Pontos-chave

Decision models respondem a perguntas com um conjunto limitado de respostas e podem produzir saídas estruturadas para fluxos de trabalho.
Eles podem ser usados para classificar conteúdo, encaminhar solicitações e ajudar a escolher a próxima ação de um agent.
Clef aceita imagens, oferece um context window de 64 mil tokens e tem pesos open source.
Jev tem um context window de 32 mil tokens, não aceita imagens e, nos testes mostrados, foi mais rápido.
O apresentador compara os modelos em uma aplicação que recomenda aulas a partir do objetivo de aprendizagem informado pelo usuário.
No teste apresentado, Jev foi considerado superior em velocidade e qualidade das recomendações.
Clef pode ser preferível quando o caso de uso exige imagens ou mais contexto; Jev exige outro modelo no workflow para processar imagens.
Os decision models podem usar probabilidades e níveis de confiança para determinar ações, solicitar mais informações ou encaminhar casos para revisão humana.

Capítulos

Início	Capítulo	Resumo
00:01	O que são decision models	O apresentador introduz Jev, explica a ideia de decisões estruturadas e situa a chegada de alternativas.
02:04	A API de decisões da OpenAI	O vídeo apresenta a proposta da OpenAI e explica como perguntas com respostas limitadas diferem de um workflow baseado em chat.
05:12	Clef e o conceito de decision model	O apresentador introduz Clef, explica o papel de classificações e descreve como probabilidades e limites de resposta podem orientar ações.
10:24	Recursos, preço e treinamento de Clef	A comparação aborda o suporte a imagens, o context window, o custo, a latência e a base técnica de Clef.
14:34	Construindo uma recomendação de aulas	O apresentador demonstra como usar decision models para recomendar aulas a partir do objetivo de aprendizagem informado.
18:44	Código e integração dos modelos	O vídeo mostra como a aplicação envia solicitações compatíveis a Clef e Jev e seleciona entre as aulas disponíveis.
22:58	Teste prático: Jev vs. Clef	O apresentador alterna entre os modelos e compara as recomendações e os tempos de resposta.
25:39	Conclusões e limitações	Jev é considerado superior nos testes, enquanto Clef se destaca quando é necessário usar imagens ou mais contexto.
26:42	Encerramento	O apresentador convida o público a comentar a comparação e divulga o canal e o programa de formação.

Citações

Um modelo que produz saídas estruturadas de forma limitada, barata, rápida e consistente. — 06:13

Esses modelos são probabilísticos, mas abertos o suficiente para raciocinar, pensar, gerar texto e fazer tool calling. — 07:18

Ter visão e um contexto maior ajuda bastante. — 11:26

Jev ainda não aceita imagens e tem um context window menor. — 25:39

Conceitos e entidades

decision model (conceito): Modelo voltado a tomar decisões estruturadas entre opções delimitadas, como classificar uma solicitação ou recomendar uma aula.
Jev (modelo): Decision model comparado a Clef que, nos testes do vídeo, foi mais rápido e apresentou resultados considerados melhores.
Clef (modelo): Decision model open source da Cloudflare que aceita imagens e oferece um context window de 64 mil tokens.
OpenAI Decisions API (ferramenta): API anunciada pela OpenAI para decisões em tempo real com perguntas definidas pelo usuário e respostas limitadas.
Cloudflare (empresa): Empresa que lançou Clef e oferece a plataforma Workers AI.
Workers AI (ferramenta): Plataforma de inference da Cloudflare por meio da qual o vídeo demonstra o uso de Clef.
OpenRouter (ferramenta): Serviço citado como outra opção para usar Clef.
Qwen (modelo): Modelo mencionado como base usada no desenvolvimento de Clef e Clef Flash.
TestRigor (empresa): Parceira do canal apresentada como serviço para testar o comportamento de agentes em diferentes configurações.
Rafael Quintanilha (pessoa): Apresentador do vídeo e criador da aplicação de recomendação de aulas demonstrada.

Tradução completa (pt-BR)

00:01 Com o lançamento do Jev, testemunhamos o nascimento de uma nova classe de modelos de inteligência artificial chamados decision models. No entanto, o sucesso do Jev foi tão grande que logo surgiram alternativas, como a Decisions API da OpenAI e o Clef, uma alternativa open source da Cloudflare. Por isso, no vídeo de hoje, quero contar tudo sobre decision models: o que são e quando você deve usá-los. Quero fazer um teste prático

00:32 comparando o Jev com o Clef e responder à pergunta: o Jev continua sendo o rei dos decision models? Pessoal, recentemente trouxe aqui para o canal uma análise bem completa sobre o Jev e sobre o que, na época, era chamado de modelos System One, um nome de que não gosto muito e que, aparentemente, não pegou. O conceito se baseia em System One e System Two, certo? Uma terminologia que vem do livro Rápido e devagar: duas formas de pensar, de Daniel Kahneman, certo?

01:02 E basicamente significa que System One é o que dá respostas mais rápidas, certo? Respostas instantâneas. A ideia do Jev, então, é funcionar como um classificador. Costumamos usar LLMs para essa tarefa. Pedimos ao LLM que faça uma classificação, muitas vezes forçando-o a usar algo chamado outputs estruturados, para que sempre retorne o formato que queremos. Mas isso é

01:34 uma espécie de uso abusivo do LLM, que não foi feito para resolver esse tipo de problema. Por isso, a novidade trazida pelo Jev foi sua própria arquitetura, para que a resposta do modelo seja tipada, ou seja, siga sempre um padrão específico predefinido, um schema. Entenderam? Então, falei bastante sobre o Jev e até o comparei com o DeepSeek V4 Flash em uma tarefa de classificação para análise de sentimento, no vídeo que fiz aqui no canal, que rapidamente se tornou o mais assistido

02:04 vídeo que publiquei aqui no canal em quase dois anos. Vou deixar o link para vocês assistirem a esse vídeo depois, mas o que eu queria abordar no vídeo de hoje era, primeiro, aprofundar um pouco esse assunto, porque, depois do Jev, vimos muitas outras empresas trazendo esse termo à tona. Em particular, queria falar da OpenAI, que anunciou no DevDay uma nova API chamada OpenAI Decisions API, cujo objetivo é basicamente fazer a mesma coisa: funcionar como um classificador, só que muito mais rápido e barato.

02:36 No entanto, no caso da OpenAI, ela se baseia no Luna, certo? Então, no momento em que estou gravando este vídeo, ainda não está disponível para testarmos essa API, mas podemos dar uma olhada no que propuseram aqui na Decisions API. Diz que essa API permite tomar decisões em tempo real, usando a inteligência do Luna, um dos modelos da OpenAI, com base em um conjunto específico de perguntas definidas pelo usuário e um grupo finito de respostas, certo?

03:08 Basicamente, você já informa ao modelo quais são as respostas possíveis, e é por isso que a resposta é muito mais rápida: o LLM precisa explorar um conjunto enorme de alternativas e, por isso, muitas vezes acaba sendo mais lento, certo? E eles mencionam algo interessante: os desenvolvedores podem fornecer contexto usando texto ou imagens e receber respostas que podem usar para classificar conteúdo, encaminhar solicitações ou escolher a

03:39 próxima ação do agent. Bem, como eu disse, isso ainda não está disponível, mas vale destacar que os desenvolvedores podem usar imagens como contexto, algo que não temos no Jev. No Jev, só há texto, certo? Mas, como eu disse, ainda não conseguimos testar. O que temos aqui são alguns artigos da comunidade que explicam mais ou menos como funciona, certo? A ideia é que, em um workflow baseado em chat, você tenha o contexto. Para esse contexto, você vai passar um prompt

04:09 que vai gerar uma explicação. Depois, você analisa e valida esse resultado e o passa para a aplicação. Em um workflow baseado em decisões, esse contexto recebe uma pergunta com limite, ou seja, com um número finito de respostas, certo? Em outras palavras, são as chamadas “respostas permitidas”. Isso já retorna, por padrão, uma decisão estruturada, certo? Então, você pode simular esse workflow usando chat, com um LLM, mas não está

04:41 usando a ferramenta certa para a tarefa. Foi isso que a OpenAI se propôs a fazer com a Decisions API. E várias outras soluções também surgiram por aqui, certo? Temos o Jev, mas o Kev também apareceu. E as pessoas começaram a usar vários nomes parecidos com Jev, certo, tentando aproveitar um pouco do hype que ele gerou, que foi realmente enorme. Mas o que chamou minha atenção e me fez querer gravar este vídeo foi o lançamento do Clef,

05:12 outro modelo parecido, com um nome semelhante, mas desta vez da Cloudflare. Tudo certo? O Clef tem algumas características bem interessantes. É um modelo open source, e eles estão chamando esses modelos de decision models. O que o Jev queria chamar de modelos System One, parece que a comunidade vai querer chamar de decision models, o que, sinceramente, também parece um nome muito melhor, certo? Então, vamos dar uma olhada no anúncio do Clef, porque, como podemos testá-lo hoje,

05:42 vou criar um exemplo prático em uma aplicação real, comparando o Clef com o Jev, para vocês verem como funcionam, certo? Mas, antes de irmos para o código, vamos dar uma olhada no anúncio da Cloudflare. Bem, eles começam destacando que, nas últimas semanas, houve todo esse hype em torno desses decision models, como o Jev, da empresa chamada TypeSh, e continuam dizendo que, embora modelos classificadores existam há muito tempo — portanto, não são novidade —, muitas

06:13 pessoas comentaram no meu vídeo dizendo: “Ah, isso é só um classificador zero-shot”, tentando minimizar o lançamento do Jev, mas há algumas diferenças aqui, certo? O Jev introduziu um novo conceito de decision models no mundo da IA. É um modelo que produz outputs estruturados de forma limitada, barata, rápida e consistente. E isso pode ser colocado em um workflow quando é preciso tomar uma decisão,

06:45 certo? Como eu disse, os engenheiros gostam de usar a ferramenta certa para a tarefa certa. Então, em vez de colocar ali um LLM, que é algo grande e lento e, às vezes, potencialmente caro, muitas vezes você pode usar um modelo menor, feito exclusivamente para essa tarefa, e obter um resultado ainda melhor, certo? Esses modelos são capazes de trabalhar com qualquer conjunto de entradas, sem precisar retreinar o modelo constantemente para incorporar novas categorias de classificação. Isso

07:18 contrasta com o mundo dos LLMs, que são em grande parte não determinísticos; são probabilísticos, mas têm abertura suficiente para raciocinar, pensar e gerar texto e chamadas de ferramentas para workflows agênticos, certo? Então, qual foi a resposta da Cloudflare? O lançamento do Clef. Certo? E você já pode usar o Clef hoje no Workers AI, a plataforma de inference de IA da Cloudflare, mas também pode usá-lo no OpenRouter. Vou mostrar uma

07:51 comparação com o Jev, certo? Eles dizem que o Clef está atualmente na liderança quando avaliado em relação ao índice de decisões do Jev. Há alguns benchmarks aqui que parecem mostrar que o Clef tem um desempenho melhor que o Jev. Esses modelos são mais rápidos, mais inteligentes e totalmente compatíveis com a API do Jev. Isso é muito legal, pessoal. Por quê? Porque nos permite substituir rapidamente um modelo pelo outro. E vamos ver

08:21 isso mais adiante neste vídeo, para que vocês possam experimentar com muito mais facilidade esses modelos hospedados por um provedor. Os pesos são open source no Hugging Face, e qualquer pessoa pode executá-los localmente. Isso é bem interessante, certo? Vamos ver o que a Cloudflare chama de decision model. O decision model faz classificações que ajudam agents a decidir como agir com base em probabilidades. Imaginem que a entrada ou o contexto seja uma mensagem de suporte dizendo: “

08:51 Olha, nossa API começou a retornar erros 500 há 20 minutos, não conseguimos continuar, certo? Preciso de ajuda.” Essa é a mensagem que o cliente enviou. E você tem um conjunto de categorias. Por exemplo: qual equipe? Para qual equipe devo encaminhar essa solicitação? E ela é urgente ou não, certo? Isso é o que chamamos de perguntas limitadas ou respostas permitidas. Você só pode responder com uma dessas opções. Para a pergunta “qual equipe?”, só pode responder cobrança, suporte técnico ou vendas.

09:23 E, para a pergunta sobre ser urgente, você só pode responder sim ou não. Então, isso vai passar pelo decision model. O decision model vai analisar todas as probabilidades e, em seguida, retornar a probabilidade de cada resposta. Neste caso, “suporte técnico” teve 100% e “sim” teve 100%. Então, você recebe esta informação: “Olha, o modelo disse que tem 100% de certeza de que é esta categoria aqui.” Ou o modelo me respondeu com 85% de certeza que sim, é urgente

09:54 solicitação. E então, com base nessas probabilidades, você, como desenvolvedor da aplicação, vai definir o que fazer. Pode estabelecer um determinado limite, um gatilho específico e, acima desse limite, executar uma ação específica. Ou, se ficar abaixo ou dentro de certa faixa, pode pedir mais informações. Ou, se sua confiança no resultado for muito baixa, pode, por exemplo, solicitar que um agente humano vá até lá manualmente e entre em contato com a

10:24 pessoa, certo? Então, esse é um workflow possível de criar com um decision model. Mas o interessante aqui é ver como o Clef, isto é, o decision model da Cloudflare, é diferente dos outros decision models, porque vários surgiram, certo? O Kev surgiu, o LIA surgiu, então vários outros modelos apareceram para competir. E a Cloudflare tem algumas diferenças interessantes. Em primeiro lugar, certo? Ele tem visão, o que é muito legal, porque você pode usar uma imagem como contexto para

10:56 seu decision model. Vimos que a OpenAI pretende incluir isso na Decisions API, que ainda não está disponível. O Jev ainda não tem esse recurso no momento em que estou gravando este vídeo, então isso já é algo legal, certo? E a segunda coisa muito interessante é que o Clef tem um contexto de 64.000 tokens, enquanto o Jev só tem 32.000. E 32.000 é muito pouco, dependendo do que você quiser fazer. Por exemplo, imagine que você queira criar um revisor de código, certo? Você quer um revisor de código, e

11:26 esse revisor de código precisa receber, por exemplo, todas as alterações de um determinado pull request para decidir se ele precisa de uma revisão humana. Um exemplo clássico de workflow. Se o meu pull request for muito grande, essa context window de apenas 32.000 tokens é pequena, certo? Não vamos conseguir fazer isso. Então, dobrar esse tamanho já é algo interessante. Ter visão e um contexto maior ajuda bastante. Essa é uma das principais vantagens que o Clef tem hoje. Agora, nem tudo é perfeito, porque, se compararmos preço e latência, a história muda um pouco, certo? Eu comparei aqui no OpenRouter o Clef, a versão Clef Flash, que é uma versão um pouco mais leve do Clef, e o Jev.

11:57 Entenderam? Então vocês podem ver que tanto o Clef quanto o Clef Flash aceitam imagens como entrada, mas olhem o preço, certo? O Jev custa, arredondando aqui, 4 centavos por milhão de tokens de entrada, certo? Basicamente, metade do preço do Clef Flash, e o Clef normal é seis vezes mais caro, certo? É uma

12:29 diferença bem significativa. E, se olharmos a latência, a latência do Jev aqui também é menor que a do Clef. É verdade que a latência dos dois é muito baixa, certo? Quer dizer, todos são bem rápidos. Em no máximo meio segundo, você já tem a resposta. Isso é legal. Mas observem que, embora o Clef tenha visão e um contexto maior, ele será mais caro e possivelmente mais lento. Agora, o último detalhe técnico que eu queria compartilhar com vocês é que aqui

13:00 neste blog, que vou deixar linkado na descrição caso vocês queiram ler depois, eles falam sobre como treinaram o Clef. Certo, há muitos argumentos técnicos aqui nos quais não vou entrar neste vídeo, mas uma coisa me chamou a atenção: o Clef 3.8 B. Curioso, não? Um LLM local que você pode executar na sua própria máquina. Na verdade, já testei o Qwen 3.8 B aqui no canal. Vou deixar o link caso queiram assistir depois. Então,

13:31 com base no modelo local, eles conseguiram gerar o Clef e o Clef Flash. É basicamente a mesma coisa, só que em cima do Qwen 3.5 B. Esse modelo roda em computadores bem mais simples, certo? Por exemplo, um Mac Mini consegue executá-lo facilmente. Então, eles pegaram essa arquitetura-base open source e fizeram várias etapas de pós-treinamento, fine-tuning etc. Usaram a técnica RLCD, que também vimos no vídeo original sobre o JV, para gerar esse modelo e o disponibilizaram

14:02 pela Workers API na Cloudflare. Então, é interessante ver como os modelos open source acumulam ganhos uns sobre os outros, certo? Porque às vezes tendemos a olhar para as melhorias que vêm do mundo open source e pensar que talvez elas não sejam práticas para nós no momento — por exemplo, eu não vou programar com o Qwen 3.8 B no meu dia a dia, vou usar o 5.5 — e isso é verdade. Mas vejam: esses pequenos avanços se acumulam e dão origem a novos modelos

14:34 que servem de base para outras tecnologias que podem surgir no futuro. Então, no fim das contas, é sempre interessante haver uma oferta maior de modelos e tecnologia open source no mercado. Maravilha, pessoal. Agora quero testar isso com vocês na prática. Como já tenho meu app programado lá na Cloudflare, vou testá-lo diretamente aqui com o Workers AI deles, certo? Então vocês podem vir aqui, vejam, em Models, certo? E, nos modelos, se pesquisarem por Clef, vão aparecer tanto o Clef padrão quanto o Clef Flash.

15:05 Ao clicar neles, vocês podem ver todos os detalhes, inclusive como usá-los. E a configuração é exatamente a mesma da API do JV que vimos no vídeo anterior. Isso é muito legal porque facilita bastante a troca de modelos se surgir em breve um muito melhor. Entenderam? Agora, outro serviço que traz muito mais tranquilidade na hora de trocar de modelo, garantindo que o resultado final não mude, é o TestRigor, nosso parceiro aqui no canal. Isso é

15:37 porque, pessoal, com o TestRigor vocês podem testar tudo o que o agente faz, garantindo que ele só retorne resultados quando todos os testes forem aprovados. Então, não importa se vocês estão usando o modelo A ou B, porque podem escrever um PRD, criar um cenário de teste e ter certeza de que o modelo vai funcionar até que o teste seja aprovado, independentemente da tecnologia usada nos bastidores, certo? Então, o TestRigor é nosso parceiro aqui no canal e pode ser usado no seu workflow agêntico

16:10 por meio de API, CLI ou até mesmo do dashboard deles. E, se quiserem conhecer o TestRigor e usá-lo de graça, o link para testá-lo estará na descrição e no comentário fixado. Maravilha, pessoal. Então, o que quero mostrar para vocês hoje? Bem, lancei minha plataforma de cursos na semana passada, incluindo a trilha de AI Engineer, que conta com três cursos, certo? O curso de Programação Agêntica, o curso de Fundamentos de Engenharia de IA e o curso de Engenharia de Prompts. Algumas perguntas que recebi das pessoas durante o lançamento foram:

16:41 Rafael, por onde eu começo, certo? Por onde devo começar a estudar? Já que teremos muitas aulas aqui, certo? No total, serão cerca de 80 aulas nesses três cursos, certo? Na trilha completa. Pensei em criar uma forma de quem entrar na plataforma pesquisar o que quer estudar naquele dia e, então, retornarmos a aula mais adequada para essa pessoa. Isso parece um exemplo perfeito de decision model. Por quê? Porque a resposta

17:12 é limitada: só pode retornar uma das aulas às quais o aluno tem acesso. Entenderam? Então, como construí isso? Peguei a transcrição de todas as aulas e gerei um resumo de cada uma. Rafael, por que você precisou gerar um resumo? Porque as aulas completas excederiam o contexto. E, como vimos que esses modelos têm um contexto menor — 32.000 tokens para o Jev e 64.000 tokens para o Cleff —, precisei reduzir o contexto resumindo as aulas. Criei esta interface aqui,

17:43 Vou mostrar o código, mas primeiro, para vocês entenderem como funciona, vou mostrar aqui na interface, certo? O aluno pode ir à área dos cursos e pesquisar o que quer aprender hoje. Não sei, vamos colocar aqui: quero aprender sobre TDD. Fiz a busca e apareceu uma aula: Spec Driven Development como método. Então, posso clicar aqui; é uma aula do curso de programação agêntica. Funcionou perfeitamente. E posso fazer outro teste aqui. Quero aprender sobre gerenciamento de contexto. E isso

18:13 Levou mais ou menos o quê? 1 segundo, 2 segundos. E aqui está a aula: degradação e gerenciamento de contexto. Maravilhoso. E se eu perguntar algo que não tem nada a ver com isso, sei lá, quero aprender a plantar batatas. Aí está. Nenhuma aula publicada nos seus cursos aborda esse assunto. Então, muito legal. Achei essa funcionalidade muito interessante. E agora vou mostrar como fiz isso na prática usando Clef. Depois vamos mudar para Jev para ver se há alguma diferença. Certo? Então, pessoal, vou mostrar a parte mais relevante do código. Criei aqui um arquivo

18:44 chamado Decision Model, onde estão todas as possibilidades de decision model que podemos usar neste momento. E aqui temos tanto Clef quanto Jev. Vocês veem aqui que, no Clef, que é um produto da Cloudflare e roda na Cloudflare, é muito fácil, certo? Basicamente, executo aqui env.ai.run, AI.RUN. Passo o ID do Clef, que é basicamente só o ID do modelo dentro da Cloudflare, e passo esta solicitação. E olhem só que legal: esta solicitação aqui, pessoal, é exatamente a mesma para Jev e

19:16 para Clef. Essa é a ideia de que ele é compatível com Jev, ou seja, passamos a mesma assinatura de solicitação, certo? Agora, com Jev, precisamos fazer uma solicitação. O código é um pouco mais longo, mas nada demais. Simplesmente fazemos uma solicitação HTTP normal, com um fetch passando a URL do Jev. E aqui é preciso ter uma conta Typefe e fornecer sua chave de API. Basicamente, você fornece sua chave de API e recebe a mesma resposta. Então, é muito fácil criar um roteador, um switch,

19:46 em que você pode configurar qual dos dois vai chamar. Neste caso, estou configurando isso por meio de uma variável de ambiente, certo? A própria variável de ambiente vai me dizer se devo usar Clef ou Jev para fazer a classificação. E vejam aqui: tenho o esquema da solicitação, que é do tipo escolha, certo? Em outras palavras, ele terá que escolher dentro de um grupo. Teremos as probabilidades de cada escolha e a confiança do modelo nessas probabilidades, certo? De novo, falei muito mais sobre isso

20:18 no vídeo original sobre Jev. Então, se ainda não assistiu, recomendo que veja esse vídeo logo depois deste, certo? E também temos aqui as respostas possíveis, certo? E então as respostas seguirão esse esquema de escolhas. Então, ótimo, é muito fácil de entender. É a mesma solicitação, é o mesmo formato que você fornece tanto para Jev quanto para Clef. E vamos ver aqui no backend como isso funciona, certo? Basicamente, é o endpoint de recomendações. E olhem só que legal: vou até lá e obtenho todas as aulas disponíveis para aquele aluno. E

20:50 dessas aulas, vou pegar o resumo, o resumo da aula. Gere esse resumo com base na transcrição, como eu disse, certo? Então, temos aqui a solicitação que vamos fazer, e ela vai receber o estado, as instruções e os critérios. Vamos ver cada um deles aqui, certo? No estado, que é basicamente o contexto, vamos passar a consulta como objetivo de aprendizagem. A consulta, pessoal, é o que o usuário vai digitar, é o que vimos ali na entrada, certo? Então, “plantar batatas”, neste

21:22 caso, é exatamente a entrada que será enviada à nossa API, certo, ao endpoint de recomendações, como consulta. Mas também temos instruções, e é justamente nelas que dizemos o que o modelo precisa escolher. Então, vamos dizer algo como: escolha a aula que melhor ensina o objetivo de aprendizagem do usuário. E a consulta é exatamente esse objetivo de aprendizagem. Depois, dizemos para escolher “nenhuma correspondência” se nenhuma aula, certo, se encaixar ou se a solicitação for vaga demais, certo? Então, sei lá,

21:54 se eu pegar isto, por exemplo, e disser o que quero aprender hoje, quero aprender… e ele encontrou uma aula aqui, o que talvez faça sentido, não sei. Deixe-me tentar outra coisa. Quero aprender a ser um bom programador. E aqui ele já mostra que é vago demais; não vai haver nada assim no curso, certo? Então, é exatamente isso que acontece quando a solicitação é vaga demais, certo? Vamos voltar à solicitação. E vejam aqui a parte legal: percorremos todos os candidatos. O que são os candidatos? São as aulas disponíveis para o usuário. E aqui temos

22:27 esses candidatos como um objeto com este esquema. Então, temos aqui o resumo, o título e várias outras coisas que passamos como opções para que o modelo, ao receber essas informações, possa decidir qual aula tem mais chances de ajudar o aluno, entenderam? E, no fim, teremos uma resposta. E, se olharmos aqui a função choose option, que mostramos antes, nossa resposta, como eu disse, será a que tiver a maior probabilidade, de acordo com o

22:58 modelo, certo? Então, é basicamente isso, pessoal. Quando encontro a aula, simplesmente a retorno para poder criar esse widget para vocês, certo? É muito fácil e realmente legal usar esse tipo de modelo na prática. Agora vou fazer o seguinte: vou trocar Clef por Jev e vamos ver se notamos alguma diferença. Ótimo, pessoal, já estamos com Jev funcionando. Então, vou executar aquela última consulta que fizemos. Ah, me pareceu um pouco mais rápido, certo? “Quero aprender a usar IA” e aqui ele gerou esta resposta para mim, certo? “prompt como organização de treinamento de SDD”.

23:30 Nossa, Jev é muito mais rápido. Jev é bem mais rápido. Olhem aqui. Muito melhor. É assim que a inferência funciona. Muito melhor aqui. “Quero aprender a plantar batatas.” É, pessoal, testando aqui de um jeito não muito científico, ficou bem claro para mim que Jev é mais rápido, certo? Estou vendo aqui o que o meu Cloud fez. Vou até colocar aqui para vocês verem. Ah, troquei aqui com Cloud. Então, basicamente, mudei a variável de ambiente para Jev. Ah, a diferença de tempo, certo? Ela

24:05 levava mais ou menos isso, um segundo e um pouco, para Clef. E aqui, com Jev, meio segundo; foi o mais rápido, certo? Vou até dizer para ele aqui, olhem. Vamos executar a mesma solicitação com CLV para vermos a diferença no tempo e qual é a resposta. Assim, para termos um teste mais completo, estou pedindo ao Claude para trocar Jev de volta para Clef, executar essas mesmas consultas que ele fez aqui e comparar a resposta e o tempo, para sabermos quem venceu. Ótimo, pessoal.

24:37 Claude já terminou a comparação aqui e vejam: para a solicitação “a IA está esquecendo decisões de uma conversa longa”, Clef retornou “contexto e raciocínio”, e Jev retornou “degradação e gerenciamento de contexto”. Para mim, Jev foi melhor aqui. E olhem só: basicamente cinco vezes mais rápido. Para a solicitação “criar um loop de agent sem um framework”, os dois responderam a mesma coisa e, de novo, Jev foi quatro vezes mais rápido. Depois, “o agent fez um monte de coisas que eu não pedi”, e

25:07 aqui, vejam: Clef, “prompt como organização de informações”, e Jev, “prompts vagos falham”. Muito bom também. Vou escolher a resposta do Jev aqui, que também foi quatro, cinco vezes mais rápido. Para a pergunta “fazer pão de fermentação natural”, nenhum dos dois respondeu nada. E, de novo, Jev foi muito mais rápido. E nossa, para a solicitação “OK”, Clef respondeu algo completamente sem relação e Jev respondeu “nenhuma correspondência”. Então, para mim, ficou claro aqui, pessoal, tanto no teste “de impressão” quanto nesta comparação um pouco melhor com Opus, que Jev ainda é o melhor modelo para tomada de decisões.

25:39 Agora, ele tem uma desvantagem. A primeira desvantagem é que é de código fechado; você não pode hospedá-lo na sua própria máquina nem executá-lo localmente, certo? A segunda desvantagem é que ainda não aceita imagens e tem uma context window menor. Então, se você precisar passar mais informações para o modelo ou enviar uma imagem, é melhor usar Clef, porque não poderá fazer isso com Jev. Para usar Jev, você vai precisar combinar um workflow com outro modelo

26:09 que simplesmente faz, sabe, a parte de visão, fornece a descrição da imagem e depois a insere no contexto com Jev. Mesmo assim, é possível que seja melhor, porque estamos vendo que talvez até na precisão do próprio modelo Jev seja superior. Mas agora quero ouvir de você o que achou dessa comparação e o que tem pensado sobre os novos modelos de decisão. Você consegue imaginar um caso de uso ou ainda acha que é só empolgação? Me conte nos comentários. Além disso, me diga se você está usando JV ou Clef para alguma outra coisa.

26:42 Quero saber o que a comunidade está criando. Então, inscreva-se no canal. Aqui falamos sobre tudo relacionado à inteligência artificial. Avaliamos modelos, fazemos testes práticos e conversamos sobre as notícias que saem toda semana. Tenho certeza de que você vai gostar. Então, por favor, deixe seu like e compartilhe com seus amigos. Se você quer aprender os fundamentos da engenharia de IA, da programação agêntica e da Engenharia de harness, convido você a conferir a trilha AI Engineer, que é a ferramenta do programa de IA que mostrei a você.

27:13 e, em breve, essa funcionalidade que mostrei neste vídeo estará disponível para os alunos de lá. O link para você conferir o programa de IA estará tanto na descrição quanto no comentário fixado. Agradeço imensamente por ter ficado comigo até agora. Agradeço à Test Pride por ser parceira e acreditar no nosso projeto.

Transcrição original

[00:01] With the release of JEV, we witnessed the birth of a new class of artificial intelligence models christened as decision models. However, JEV’s success was so great that alternatives soon emerged, such as OpenAI’s Decisions API and Clef, an open-source alternative from Cloudflare. That is why, in today’s video, I want to tell you everything about decision models, what they are, and when you should use them. I want to perform a practical test

[00:32] comparing JEV with Clef and answer the question: does JEV remain the king of decision models? Folks, I recently brought a very complete analysis here on the channel about JEV and what at the time was called System One Models, which is a name I don’t like very much, and apparently, it didn’t catch on. It is based on System One and System Two, right? A terminology that comes from the book Thinking, Fast and Slow, by

[01:02] Daniel Kahneman, right? And it basically means that System One is the one that gives faster answers, right? Instant answers. And the idea of JEV, then, is to serve as a classifier. We tend to use LLMs for this task. We ask the LLM to perform a classification, often forcing it with something called structured outputs, so that it always returns the format we want. But this is

[01:34] sort of an abuse of what the LLM was made to solve. And therefore, what JEV brought that was new is its own architecture so that the model’s response is typed, meaning it always follows a specific stipulated pattern, a schema. Got it? So, I went into a lot of detail about JEV, and I even compared it to DeepSeek V4 Flash for a sentiment analysis classification task in the video I made here on the channel , which quickly became the most-watched

[02:04] video I’ve had here in almost 2 years on the channel. I will leave the link for you to watch that video later, but what I wanted to talk about in today’s video was, first, to expand a bit on this subject, because post-JEV we saw many other companies bringing this term to the table. In particular, I wanted to talk about OpenAI, which announced at DevDay a new API called the OpenAI Decisions API, which basically aims to do the same thing: be a classifier, only much faster and much cheaper.

[02:36] However, in OpenAI’s case, it’s based on Luna, okay? So, it’s not available at the moment I’m recording this video for us to test this API, but we can take a look at what they proposed here in the Decisions API. It says that this API allows for real-time decision-making, using the intelligence of Luna, one of OpenAI’s models, on a specific set of user-defined questions with a finite group of answers, okay?

[03:08] So, basically, you already provide the model with what the possible answers are, and that’s why the response is much faster, because the LLM needs to explore a very large set of alternatives, and therefore, it often ends up being slower, okay? And they mention something interesting, that developers can provide context using text or images and receive back answers that they can use to classify content, route requests, or choose the agent’s

[03:39] next action. Well, this isn’t available , as I said, but what’s noteworthy here is that developers can use images as context, which is something we don’t have in JV. In JV, it’s only text, alright? But as I said, we haven’t been able to test it yet. What we have here are some community articles explaining more or less how it works, right? So, the idea is that in a chat-based workflow, you have the context. For this context, you will pass a prompt

[04:09] that will generate an explanation. And then you parse and validate that result and then pass it to the application. In a decision-based workflow, this context receives a question that is limited, it has a finite limit of answers, okay? In other words, it’s what they called here “allowed answers,” answers that are permitted. So this by default already returns a structured decision, right? So you can simulate this workflow using chat, using an LLM, but you aren’t

[04:41] using the right tool for the task. So that is what OpenAI set out to do with the Decisions API. And we have several other solutions that have appeared here , right? We have JV here, but Kev has also emerged. And people started using various names similar to JV, right, to try to take advantage of a bit of the hype it generated, which was indeed very big. But what really caught my attention and made me want to record this video was the launch of Clef,

[05:12] another similar model with a similar name, but this time from Cloudflare. All good? And Clef has some very interesting features. It is an open-source model, and they are calling them decision models. So, what Jev wanted to call system one models, it seems the community will want to call decision models, which honestly also seems like a much better name, right? So let’s take a look at this Clef announcement, because since we can test

[05:42] Clef today, I’m going to create a practical example in a real application comparing Clef to Jev, so you can see how they work, okay? But before we head to the code part, let’s take a look at the Cloudflare announcement. Well, they start by pointing out that in the last few weeks there has been all this hype around these decision models, like Jev from the company called TypeSh, and they continue saying that, while classifier models have existed for a long time—so it’s nothing new—many

[06:13] people came to my video comments saying , “oh, this is just a zero-shot classifier,” trying to downplay the Jev release, but there are some things that are different here, okay? So, Jev introduced a new concept of decision models to the AI world. So, it is a model that produces structured outputs, limited in a cheap, fast, and consistent way. And this can be placed in a workflow when a decision is needed

[06:45] , okay? So I said it, engineers like to have the right tool for the right task. So, instead of putting an LLM there, which is something big and slow and sometimes potentially expensive, you can often use a smaller model made exclusively for that task with an even better result, okay? So, these models are capable of working on any set of inputs, without constantly having to retrain the model to incorporate new classification categories. So, this

[07:18] contrasts with the world of LLMs, which are largely non-deterministic, they are probabilistic, but are open enough to reason, to think and generate text and tool calls for agentic workflows, okay? So, what was Cloudflare’s response? It was the launch of Clef. All right? And you can already use Clef today over at Workers AI, which is Cloudflare’s AI inference platform, but you can also use it on OpenRouter. I’ll show you a

[07:51] comparison with GJF, okay? So they say that Clef is currently the leader when you evaluate it against the GJF Decision index. So there are some benchmarks here where it seems Clef performs better than GJF. So these models are faster, smarter, and completely compatible with the GJF API. This here is really cool, guys. Why? Because it allows us to quickly replace one model with the other. And we’ll see

[08:21] that later in this video, so you can experiment with these models hosted by a provider much more easily. The weights are open source on Hugging Face , and anyone can run them locally. So this is quite interesting, okay? Let’s get into what Cloudflare calls a decision model. So the decision model performs classifications that help agents decide how to act based on probabilities. So imagine the input or context is a support message saying: “

[08:51] Look, our API started returning 500 errors 20 minutes ago, we can’t proceed , right?““Need help.” So this is the message your customer sent. And you have a set of categories, for example, which team? To which team should I route this request and is it urgent or not, right? So this is what we call bounded questions or allowed answers. You can only respond with one of these things. You can only answer billing, technical, or sales for the question “

[09:23] which team?” And you can only answer yes or no when the question is whether it is urgent. So this will pass through here to the decision model. The decision model will analyze all the probabilities and then it will return the probability for each of the answers . So in this case, technical was 100% and yes was 100%. So you receive this information: “Look, the model said it is 100%certain that it’s this category here.” Or the model answered me with 85 %certainty that yes, it is an urgent

[09:54] request. And then, based on these probabilities, you, as the application developer, will define what to do. You can set a certain threshold, a certain trigger, and then above that threshold you proceed with a specific action. Or if you are below or between a certain range, you can ask for more information . Or if your confidence in the result is very low, you can, for example, request that a human agent, someone manually, go there and contact the

[10:24] person, okay? So that is a possible workflow you could build with a decision model. But what is interesting here is to see how Clef, that is, Cloudflare’s decision model, is different from other decision models, because several have appeared, okay? Kev appeared, LIA appeared, so several other models have emerged to compete. And Cloudflare has some interesting differences. First of all, okay? They have vision, which is very cool because you can put an image as context for

[10:56] your decision model. We have seen that OpenAI will want to put this in the Decisions API, which is not yet available. Jev still doesn’t have it at the moment I’m recording this video, so that’s already something cool, okay? And the second very interesting thing is that Clef has a context of 64,000 tokens, because Jev is only 32, and 32,000 is very small, depending on what you want to do. For example, imagine you want to build a code reviewer, right? You want a code reviewer, and

[11:26] then this code reviewer has to receive, for example, all the changes of a certain pull request to decide if that needs a human review. A classic example of a workflow here. If my pull request is very large, this window of only 32,000 tokens is small, right? We won’t be able to do that. So, doubling it is already something interesting. So, having vision and a larger context helps a lot. This is one of the main advantages that Clef has today. Now, not everything is perfect, because if we compare price and latency, then the

[11:57] story changes a bit, okay? I compared here on OpenRouter, Clef, the Clef Flash version, which is a slightly lighter version of Clef, and Jev. Got it? So you can see that Clef, as well as Clef Flash, both can receive images as input, but look at the price, okay? Jev costs, rounding up here, 4 cents per million input tokens, okay? So it is basically half of Clef Flash, and regular Clef is six times more expensive, okay? So it is a very

[12:29] significant difference. And if we look at latency, the latency here for Jeff is also faster than Clef’s latency. It is true that the latency for both is very fast, okay? I mean, they are all quite quick. In half a second at most, you already have your answer. So that is cool. But note that although Clef has vision and a larger context, it will be more expensive and potentially slower. Now, the last technical detail I wanted to share with you is that here

[13:00] in this blog, which I will link in the description if you want to read it later, they talk about how they trained Clef. Okay, there are a lot of technical arguments here that I won’t go into in this video, but one thing that caught my attention is that Clef 3.8 B. Isn’t that curious? A local LLM that you can run on your own machine. I have actually tested the Qwen 3.8 B here on the channel. I will leave the link if you want to watch it later. So,

[13:31] based on the local model, they managed to generate Clef and Clef Flash. It’s basically the same thing, just on top of Qwen 3.5 B. That one runs on much simpler computers, okay? Like, a Mac Mini, for example, it runs it easily. So they took this open-source base architecture and performed several post-training steps, fine-tuning, etc. They used the RLCD technique, which we also saw in the original JV video, to generate this model and made it

[14:02] available via Workers API on Cloudflare . So this is interesting for us to see how open-source models stack gains on top of each other, right? Because we tend to sometimes look at improvements coming from the open-source world and think that, perhaps, because it isn’t practical for us at the moment—like, I won’t program with Qwen 3.8 B in my daily life, I’ll use the 5.5—it’s true, but look, these small advances compound to become new models that

[14:34] serve as a base for other technologies that may emerge in the future. So, at the end of the day, it is always interesting for us to have a greater supply of models and open-source technology in the market. Wonderful, guys. So, now I want to test it with you in practice. Since I already have my app programmed there on Cloudflare, I will test it here directly with their Workers AI, right? So you can come here , look, to models, okay? And for models , if you search for Clef, both the standard Clef and Clef Flash will

[15:05] appear here. Clicking on them, you can see all the details, including how you can use them. And it’s the exact same setup as the JV API we saw in the previous video. So this is really cool because it makes it much easier to swap models if a much better one comes along soon. Got it? Now, another service that gives you much more peace of mind when switching models, knowing the final result won’t change, is TestRigor, our partner here on the channel. That’s

[15:37] because, guys, with TestRigor you can test everything your agent does, ensuring it only returns results once all tests are passing. So it doesn’t matter if you’re using model A or B, because you can write a PRD, write a test scenario, and be sure the model will work until that test passes, regardless of the tech you use behind the scenes, okay? So TestRigor is a partner of ours here on the channel that you can use within your agentic

[16:10] workflow via API, CLI, or even their dashboard. And if you want to check out TestRigor and use it for free, the link to test it will be in the description and in the pinned comment. Wonderful, everyone. So what do I want to show you today? Well, I launched my course platform last week, including the AI Engineer track which features three courses, okay? The Agentic Programming course, the AI Engineering Fundamentals course, and the Prompt Engineering course. Some questions I received from

[16:41] people during the launch were: Rafael, where do I start, right? Where should I begin studying? Since we’re going to have many lessons here, right? In total , there will be about 80 lessons across these three courses, right? In the full track. I thought about creating a way for someone entering the platform to search for what they want to study that day, and then we will return the most suitable lesson for them. This seems like a perfect example of a decision model. Why? Because the answer is

[17:12] bounded, meaning it can only return one of the lessons the student has access to. Got it? So, how did I build this? I took the transcript of all the lessons and generated a summary of them. Rafael , why did you need to generate a summary? Because the full lessons would exceed the context. And since we saw that these models have a smaller context, 32,000 tokens for Jeev and 64,000 tokens for Cleff, I needed to reduce the context by summarizing the lessons. I created this interface here,

[17:43] I’ll show you the code, but first, so you understand how it works, let me show you here in the interface, okay? So the student can go here to the course area and search for what they want to learn today. I don’t know, let’s put here, I want to learn about TDD. And then I did the search and it landed here on a lesson, Spec Driven Development as a method. And then I can click here, it’s a lesson from the agentic programming course. So it worked perfectly. And I don’t know, I can do another test here. I want to learn about context management. And it

[18:13] took more or less what? 1 second, 2 seconds. And here is the lesson, degradation and context management. Wonderful. And if I ask something that has nothing to do with it, I don’t know , I want to learn how to plant potatoes . There it is. No published lesson in your courses covers this subject. So, pretty cool. I found this functionality very interesting. And let me show you, then, how I made it in practice using Clef. And then we will switch to Jeev to see if there is any difference. Alright? So there you go guys, I will show you the part of the code that is most relevant. I created here a file

[18:44] called Decision Model, where there are all the possibilities of decision models that we can use at this moment. And here we have both Clef and Jeev. You see here that in Clef, which is a Cloudflare product and the program runs on Cloudflare, it is very easy, right? I basically run here, env.ai.run, AI.RUN. I pass the Clef ID, which is basically just the model ID within Cloudflare, and I pass this request. And look how cool, this request here, folks, is exactly the same for Jeev and

[19:16] for Clef. It’s that idea that it is Jeev-compatible, that is, it is the same request signature that we pass, right? Now with Jeev, we need to make a request, the code is a little bit longer, but nothing too much. We just make a normal HTTP request, which does a fetch passing the Jeev URL. And here you need to have a Typefe account, providing your, your API key. And basically, you provide your API key and get the same response. So, it is very easy to create a router, a switch,

[19:46] where you can configure which of these two you will call. In this case, I am configuring it through an environment variable, okay? So, an environment variable itself will tell me if I should use Clef or if I should use JV to perform my classification. And look here, I have the request schema, so it is a choice type, right? In other words , it will need to choose from within a group. We will have the probabilities of each choice and the model’s confidence in those probabilities, okay ? Again, I spoke much more about this

[20:18] in the original Jeff video. So, if you haven’t seen it yet, I recommend that you watch that video right after this one, okay? And we also have the possible answers here, okay? And then the answers will follow this choices schema. So, wonderful, very easy for you to understand. It is the same request, it is the same format that you provide to both JV and Clef. And let’s look here at the back end at how this works, okay? So, it is basically the recommendation endpoint. And look how cool, I go there and get all the classes available for that student. And

[20:50] from those classes there, I will take the summary, the class summary. This summary I generated based on the transcript, as I told you, okay? So we have here the request that we are going to make, and this request will receive the state, instructions, and criteria. Let’s look at them one by one here, okay? So here in the state, which is basically the context, we will pass the query as the learning objective. The query, guys, is what the user will type , it is what we saw there in the input, right? So “planting potatoes” here, in

[21:22] this case, is exactly the input that will be sent to our API, right, to the recommendation endpoint as a query. But we also have instructions, and it is precisely in the instruction that we tell what the model has to choose. So, we will say something like, choose the class that best teaches that user’s learning objective. And then the query is exactly that learning objective. And then we tell it to choose “no match” if no class, right, fits or if the request is too vague, okay? So, I don’t know,

[21:54] if I take this, for example, and say what I want to learn today, I want to learn, and then it found a class here, which could make sense, I don’t know, let me try something else. I want to learn how to be a good programmer. And here it already shows it’s too vague, there won’t be anything like that in the course, okay? So this is exactly when the request is too vague, right? So let’s go back to the request. And look here at the cool part. We go through all the candidates. What are the candidates? They are the classes available to the user. And here we have

[22:27] these candidates as an object with this schema. So, we have here, the summary, the title, and several other things that we pass as an option so that the model, receiving that information, can make the decision on which class has the best chance of helping the student, got it? And then in the end, we will have a response. And if we look here at the choose option function, which is what we showed earlier, our response, as I said, will be the one with the highest probability according to the

[22:58] model, right? So, that’s basically it, guys. Once I find the class, I basically just return it to be able to build that widget for you, okay? So, very easy, really cool to use this type of model in practice. Now I’ll do the following, I’ll switch from clef to Jev and we’ll see if we can notice any difference. Wonderful, guys. We already have JV running, so let me even run that last query we did. Oh, it seemed a bit faster to me, right? I want to learn how to use AI and here it generated this one for me, right? The prompt as SDD training organization.

[23:30] Wow, much faster is JV. JV is much faster. Here, look. Much better. Here is how inference works. Much better here. I want to learn how to plant potatoes. Yeah, guys, testing here in a not-very-scientific way, it seemed quite clear to me that JV is faster, okay? I’m looking here at what my cloud did. Let me even put it here so you can see. Oh, I switched here with cloud. So , basically, I changed the enviable to jeev, oh, the time difference, okay? It

[24:05] was taking more or less that, a second and a bit for Clef. And here with Jev, half a second, it was the fastest, okay ? I’ll even tell him here, look. Let’s run the same request with CLV for us to see the difference in time and what the answer is. So, just so we can have a more complete test here, I’m asking Claude to switch from Jev back to Clef, run these same queries that he did here , and compare the answer and the time so we know who won. Wonderful, guys.

[24:37] Claude has already finished our comparison here and look, for the request “AI is forgetting decisions from a long conversation.” Clef returned context and reasoning, and Jev returned degradation and context management. It seems to me that Jev was better here. And look at that, basically five times faster. For the request “build an agent loop without a framework,” both answered the same thing, and again Jev was four times faster than it. Then “the agent did a bunch of stuff I didn’t ask for,” and

[25:07] here look, Clef, “prompt as information organization” and Jev, “vague prompts fail.” Very good as well. I’ll also go with Jev’s choice here, which was also four, five times faster. For the question “make sourdough bread,” neither of them answered anything. And again, Jev, much faster. And wow, on the request, “OK,” Clef answered something completely unrelated and Jev, “no match.” So, it seems clear to me here, guys, in the “feeling” test and here by doing this slightly better comparison with Opus, that Jev is still

[25:39] the superior model for decision-making. Now, it comes with a downside. First downside, it’s closed source; you can’t host it on your own machine or run it locally, okay? Second downside, it still doesn’t accept images and has a smaller context window. So, if you need to pass more information to the model or pass an image, it’s better to use Clef because you won’t be able to do it with Jev. To use Jev, you’ll need to combine a workflow with another model

[26:09] that just does, you know, the Vision part, provides the image description, and then feed that into the context with Jev. Even so, it’s possible it’s better, because we’re seeing that perhaps even in the model’s own accuracy, Jev is superior. But now I want to hear from you what you thought of this comparison and what you’ve been thinking of the new Decisions. Can you see a use case or do you still think it’s just hype? Let me know down in the comments. Also, let me know if you are using JV or Clef for anything else.

[26:42] I want to know what the community is building. So go ahead and subscribe to the channel. Here we talk about everything, artificial intelligence. We review models, run practical tests, and talk about the news that comes out every week. I’m sure you’re going to like it. So, please, leave your like , and share it with your friends. If you want to learn about the fundamentals of AI engineering, agentic programming, and Harness Engineering, I invite you to check out the AI Engineer track, which is the tool from the AI

[27:13] program I showed you, and soon this functionality I showed in this video will be available to students there. The link for you to check out the AI program will be in both the description and the pinned comment. I thank you immensely for staying with me until now . I thank Test Pride for being a partner and believing in our project.