Os melhores casos de uso de Jev para programação com IA (mudanças radicais)

Ver no idioma original →

Autoria: Cole Medin · 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: The BEST Jev Use Cases for AI Coding (Absolute Game Changers) · Canal: Cole Medin · 17:31 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Segurança de IA

Resumo

Cole Medin apresenta quatro usos práticos de Jev em workflows de programação com IA: proteger agentes contra ações arriscadas, testar jogos, testar sites e classificar tarefas para direcionar workflows. Jev é descrito como um modelo de decisão que responde a perguntas de múltipla escolha com probabilidades, sendo mais rápido e barato que LLMs para esse tipo de tarefa. O vídeo mostra como combinar Jev com LLMs: estes podem preparar o contexto e agir com base nas decisões, enquanto Jev acelera etapas específicas. O autor também demonstra exemplos próprios e relata resultados positivos em testes de classificação e segurança.

Pontos-chave

• Jev recebe uma situação, chamada de state, e responde a várias perguntas de múltipla escolha em paralelo, atribuindo probabilidades às opções.
• O primeiro caso de uso é um hook pre-tool use para detectar ações arriscadas, como acessar arquivos .env, apagar pastas ou exfiltrar dados.
• Segundo o autor, Jev reduziu falsos positivos e bloqueou quase todas as chamadas arriscadas nos testes iniciais, com menor latência e custo que as alternativas mencionadas.
• Em testes de jogos, Jev pode tomar decisões rápidas durante a partida e ajudar a encontrar bugs que testes unitários ou um LLM sozinho talvez não encontrem.
• Na automação de navegador, Jev pode decidir onde clicar e qual ação realizar; um LLM ainda pode ser necessário para gerar texto livre.
• O quarto caso de uso é classificar tarefas, como determinar o tipo e a dificuldade de uma issue, para escolher o modelo, as skills e as etapas adequadas.
• Jev não substitui o LLM no workflow: o LLM pode montar o harness e executar ações com base nas decisões de Jev.
• O autor relata que concordou com as classificações de 12 execuções de um workflow e que outra classificação para revisão de pull requests acertou 15 de 16 casos.

Capítulos

Início	Capítulo	Resumo
00:00	O que é Jev e por que usar em programação com IA	O vídeo apresenta Jev como um modelo de decisão rápido e econômico e antecipa quatro casos de uso para workflows de programação com IA.
02:34	Proteção contra ações arriscadas de agentes	O autor explica como usar Jev em um hook pre-tool use para detectar e bloquear ações como leitura de segredos ou exclusão de dados.
07:43	Teste de jogos em tempo real	Jev toma decisões durante uma partida e pode revelar bugs, enquanto um LLM ajuda a construir o harness e agir sobre os resultados.
10:49	Testes de navegador	Jev automatiza ações em sites, como clicar em botões, e pode trabalhar junto com um LLM quando é necessário inserir texto livre.
13:22	Classificação de tarefas e roteamento de workflows	O autor mostra como Jev classifica issues e pull requests para selecionar o tipo de trabalho, o nível do modelo e as etapas seguintes.

Citações

Jev é incrível. — 00:00

Precisamos de proteções para impedir que nossos agentes executem ações destrutivas. — 03:06

Nunca vamos usar Jev sozinho. — 10:17

Você ainda precisa de um LLM para parte do workflow. — 12:21

Esses são meus quatro casos de uso favoritos para Jev em workflows de programação com IA. — 17:00

Conceitos e entidades

• Jev (modelo): Modelo de decisão apresentado no vídeo, que responde a perguntas de múltipla escolha sobre um state.
• System 1 models (conceito): Categoria de modelos descrita como especializada em tomar decisões em vez de gerar texto.
• hooks (conceito): Automações vinculadas a eventos do ciclo de vida de um agente de programação.
• pre-tool use (conceito): Evento de hook executado antes de o agente usar uma ferramenta, permitindo analisar ou bloquear a ação.
• OpenRouter (ferramenta): Serviço pelo qual o autor acessa Jev usando um endpoint de decisão.
• Claude Code (ferramenta): Agente de programação citado como um dos produtos que introduziram o conceito de hooks.
• Playwright MCP (ferramenta): Ferramenta mencionada para realizar testes de navegador com um LLM.
• Agent Browser CLI (ferramenta): CLI da Vercel mencionada como opção para testes de navegador com um LLM.
• Arkon (repo): Projeto open source do autor para criar harnesses e workflows maiores de programação com IA.
• DynaChat (ferramenta): Aplicativo em produção apresentado pelo autor, capaz de pesquisar seu conteúdo no YouTube e materiais da comunidade.
• Cole Medin (pessoa): Apresentador do vídeo e autor dos exemplos de workflows demonstrados.
• Dynamis (empresa): Comunidade mencionada pelo autor, com workshops e cursos que também podem ser consultados pelo DynaChat.

Tradução completa (pt-BR)

00:00 Jev é incrível. Foi lançado recentemente e popularizou um tipo de modelo de IA chamado decision models, especializado em tomar decisões em vez de gerar texto. Então, ele é bem diferente de LLMs como Claude e GPT. E abriu um leque totalmente novo de casos de uso que todo mundo está compartilhando na internet agora. As pessoas estão compartilhando muitos casos de uso divertidos e interessantes com Jev, mas algo que tenho ouvido bastante, especialmente de pessoas da minha comunidade Dynamis, é que os casos de uso são

00:30 interessantes, mas nem sempre são os mais práticos, certo? Não há muitas coisas que você vê e pensa: “Certo, preciso incorporar isso aos meus workflows de IA agora mesmo.” Por isso, quero fazer este vídeo, mostrando rapidamente, especificamente para programação com IA, quatro casos de uso incríveis de Jev para tornar seus workflows de programação com IA mais rápidos e mais eficientes no uso de tokens, o que é muito importante agora, especialmente com os limites de uso tão ruins. Se você acompanha as novidades em IA, há uma grande chance de já ter ouvido falar de Jev e talvez até tenha experimentado por conta própria. Jev não é o primeiro tipo de

01:01 decision model desse tipo, mas isso é assunto para outro vídeo. O importante é que Jev é muito poderoso. Ele funciona assim: você fornece algum tipo de situação, que eles chamam de estado, e também uma lista de perguntas de múltipla escolha. Em paralelo, ele responde a cada uma dessas perguntas com uma probabilidade, que basicamente é sua pontuação de confiança. A questão é que já dá para fazer isso com LLMs, especialmente com saída estruturada: você pode fazê-los tomar decisões que pode usar como referência no seu workflow. Mas o que torna Jev tão incrível é que ele é

01:32 de 20 a 200 vezes mais rápido que LLMs para tomar decisões e também de 40 a 1.000 vezes mais barato. Obviamente, a grande variação se deve ao fato de que você pode comparar Jev com LLMs diferentes, mas, seja qual for o LLM que você usar, Jev será mais preciso, mais rápido e mais barato para tomar qualquer tipo de decisão. Então, em linhas gerais, quando você pensa em Jev como o tomador de decisões, há infinitas possibilidades de uso. Por isso, quero ser bem específico com você aqui, só

02:02 mostrando rapidamente algumas ideias e inspirando você com diferentes maneiras de usá-lo de forma bem prática. Cada um desses casos de uso de Jev é valioso o suficiente para que eu pudesse fazer um vídeo inteiro explicando como criá-lo e incorporá-lo. Mas, por enquanto, quero ficar num nível mais geral. Quero manter isso breve e direto, dando ideias para você escolher algumas e talvez desenvolvê-las por conta própria. Além disso, nesta sexta-feira, vou conduzir um workshop na minha comunidade Dynamist para explorar esses casos de uso com muito mais profundidade. Então, confira se tiver interesse. E, sim, como eu disse, vem muito mais conteúdo por aí, aprofundando Jev, porque isso é

02:34 empolgante para mim. Na verdade, eu disse isso no meu primeiro vídeo sobre Jev. Este é o primeiro modelo de IA em muito tempo que realmente me empolga. E acho que você vai entender por quê quando chegarmos a esses quatro casos de uso. Então, vamos direto ao assunto. Meu caso de uso favorito de Jev nos meus workflows de programação com IA, neste momento, é segurança. Porque a questão é a seguinte — e você provavelmente já percebeu isso — os assistentes de programação com IA aceitam fazer coisas que não deveriam com facilidade demais, como ler suas variáveis de ambiente, excluir uma pasta inteira, mesmo que você tenha instruções nas suas regras globais ou skills para não fazer

03:06 isso, especialmente quando você começa a inflar bastante o contexto de uma conversa ou quando tem um prompt que acaba dando a ele uma brecha. Ele vai encontrar maneiras de fazer essas coisas. Por isso precisamos de proteções para impedir que nossos agents executem ações destrutivas. E Jev pode funcionar muito bem como essa proteção. A maneira mais popular e eficaz de implementar essas proteções para nossos agents de programação é usando hooks, introduzidos no Claude Code. Hoje, praticamente todo agent de programação tem o conceito de hooks, aos quais podemos associar automações

03:36 para serem executadas em diferentes eventos ao longo do ciclo de vida do nosso agent de programação. O evento mais popular é o pre-tool use. Quando o agent está prestes a executar uma ação, como ler um arquivo ou rodar um comando, podemos executar uma automação para analisá-la e bloquear o agent ou permitir que ele continue. E dá para ver aonde quero chegar: um dos casos de uso mais populares é ter um hook de pre-tool use que tenta analisar a ação do agent para determinar se ele vai ler um arquivo .env, certo? Nós

04:07 não queremos que nossos segredos sejam expostos no contexto do nosso agent de programação. Assim, ele pode retornar um código de erro para basicamente bloquear essa ação, obrigando o agent a fazer outra coisa. Por exemplo, ler o arquivo .env.example. O problema desse hook, antes de Jev, é que precisamos pedir a um LLM para analisar cada chamada ou usar algum tipo de processo determinístico com expressões regulares. De qualquer forma, vai ser caro ou pouco

04:37 preciso. Vamos logo descartar a ideia de usar um LLM, porque, se formos analisar cada ação que o agent quiser executar, isso vai custar centenas ou milhares de dólares ao longo do mês, só para bloquear essas chamadas sensíveis que podem acontecer de vez em quando. Então, antes de Jev, eu usava expressões regulares. Tenho um hook que faz correspondência de padrões para tentar descobrir se o agent está tentando fazer algo como ler minhas credenciais do Google, ler meu .env, excluir uma pasta ou qualquer outra coisa. Mas o problema é que há muitas maneiras diferentes de um agent executar essas ações destrutivas, porque ele pode ler o arquivo diretamente, escrever um script em Python para isso ou usar um comando bash, certo? Há milhões de possibilidades. Por isso, temos esta lista enorme, e ela nem sequer detecta tudo. Também há muitos falsos positivos. Então, substituí esse hook de pre-tool use pelo meu Jev Guard. Daqui a pouco vou mostrar algumas estatísticas. Isso é muito econômico e confiável. Os decision models, de novo, recebem um estado e uma lista de perguntas de múltipla escolha. Então, para qualquer coisa que possa dar errado com uma ação do agent, pergunto se aquilo está acontecendo, certo? Tipo: estamos expondo segredos? Ele responde verdadeiro ou falso, e damos algumas instruções para acrescentar contexto. Isso faz parte do estado. Depois, pergunto se ele está destruindo algum dado, como removendo uma pasta inteira, ou se está fazendo algum tipo de exfiltração, talvez enviando dados sensíveis para fora por meio de um ataque de prompt injection. E outra coisa bem legal é que podemos analisar se o agent está saindo do rumo. Assim, podemos usar esse hook de pre-tool use para muito mais do que apenas segurança: em geral, ele funciona como mais um tipo de LLM as a judge,

05:07 um agent consegue realizar essas ações destrutivas porque pode ler o arquivo diretamente, escrever um script em Python para fazer isso ou executar um comando bash, certo? Há um milhão de coisas diferentes. Então, temos aqui essa lista enorme, e ela nem sequer cobre tudo. Também há muitos falsos positivos. O que fiz foi pegar este hook de pré-uso de ferramentas e substituí-lo pelo meu Jev Guard. Daqui a pouco, vou mostrar algumas estatísticas. Isso é muito econômico e confiável. Então, para os modelos de sistema um, novamente, fornecemos o estado e uma lista de perguntas de múltipla escolha. E, para qualquer coisa

05:38 que possa dar errado com uma ação do agent, pergunto se é o caso, certo? Por exemplo: estamos expondo segredos? O modelo vai responder verdadeiro ou falso, e fornecemos algumas instruções para dar contexto adicional. Isso faz parte do estado. E então: está destruindo algum dado, como removendo uma pasta inteira? Há algum tipo de exfiltração, em que talvez estejamos enviando dados confidenciais para fora, como em um ataque de prompt injection? E outra coisa muito legal é que podemos analisar se o agent está se desviando da tarefa. Assim, podemos usar esse hook de pré-uso de ferramentas para muito mais do que apenas segurança: podemos, de modo geral, ter outro tipo de modelo como juiz,

06:10 garantindo que continuemos no caminho certo para alcançar o que estamos tentando fazer. Quanto ao estado, a situação que é a principal entrada para Jev, fornecemos o nome da ferramenta, o efeito dela, a entrada — como os argumentos da ferramenta — e também nosso diretório de trabalho atual. Isso dá a ele uma visão completa. Quando consulto Jev, uso o próprio Jev pelo Open Router, por meio do novo endpoint de decisão deles. Em seguida, passo esse estado junto com todas as perguntas que mostrei acima. Só estou usando esse hook há pouco tempo, já que Jev acabou de ser lançado, mas meus resultados iniciais são incríveis. Então,

06:41 minha versão anterior do hook usando expressões regulares, dá para ver que ela não bloqueava tantas chamadas arriscadas. Agora, obviamente, “arriscado” é subjetivo. Tenho ficado bem satisfeito com esse hook no geral, mas o principal problema que tive com ele são os falsos positivos: bloquear coisas que realmente não deveriam ser bloqueadas, como simplesmente escrever as palavras {dot} env em um documento markdown. Já ao usar um LLM, ele faz um ótimo trabalho. Quer dizer, não tem tantos falsos positivos e bloqueia a maioria das chamadas arriscadas. Mas, mesmo usando algo realmente rápido e barato como Haiku, ainda leva mais de um segundo. E sim, é só

07:12 cerca de um décimo de centavo por análise, mas isso realmente se acumula quando seu agent faz milhares de chamadas todos os dias. E então chegamos ao Jev. Jev bloqueia quase todas as chamadas arriscadas e mal tem falsos positivos. Cada análise leva um quarto de segundo, e o custo é uma fração de uma fração de centavo. Então, é econômico e rápido. Ele nos dá, essencialmente, a capacidade de raciocínio de um LLM para esse tipo de decisão, mas parece que é de graça. Quer dizer, sei que não é exatamente de graça, mas, enfim, não chega a

07:43 pesar no bolso de forma alguma. Certo, nosso próximo caso de uso é testar jogos. E isso realmente se aplica a qualquer tipo de aplicação que exija que um modelo tome decisões rápidas ou responda às coisas em tempo real. Estou usando videogames como exemplo porque é muito legal ver o Jev jogar, e também é algo que estou desenvolvendo de verdade. E, em qualquer coisa como um jogo, quando temos 60 quadros por segundo ou 30 quadros por segundo, um LLM é lento demais para responder às coisas. Quando ele termina de analisar a cena para tomar uma decisão, a cena já

08:14 passou, certo? E, por exemplo, o personagem já vai ter morrido no jogo. Mas o Jev consegue acompanhar. É incrível de assistir. E isso também é muito prático porque sempre queremos ter essa etapa de validação no nosso workflow de programação com IA. Então, em um videogame, sabe, depois de criarmos o próximo recurso, queremos que o modelo consiga jogar como um usuário realmente jogaria. E isso não era muito viável antes do Jev. Então, dê uma olhada. Tenho um exemplo ao vivo do Jev jogando um dos jogos para os quais estou criando uma prova de conceito agora. Parece que

08:45 sou eu que estou jogando. O personagem está atacando, desviando e se movimentando pelo mapa. Você pode ver as decisões que o Jev está tomando aqui, no lado esquerdo. As probabilidades de todas as diferentes ações que oferecemos como opções, porque, de novo, tudo depende do estado — ou seja, onde cada um está no jogo — e das decisões, como qual movimento vamos fazer em seguida. E estou com as mãos longe do teclado. Sério, parece que sou eu que estou jogando agora. É muito legal. E, enquanto toma as decisões e processa o estado do jogo, também podemos analisar como as coisas estão indo no geral e agir com base nisso, certo? Por exemplo, talvez a gente

09:15 descubra bugs de verdade enquanto joga, o tipo de coisa que um LLM nunca conseguiria descobrir sozinho apenas executando testes unitários. E tenho executado isso de verdade enquanto desenvolvo novos recursos no jogo, e ele realmente encontrou bugs que o LLM não conseguiu encontrar sozinho, porque o LLM não consegue jogar de verdade. E sim, ele consegue executar outros testes e harnesses que eu crio, mas isso é mais determinístico e não é realmente jogar como um usuário jogaria. Então, o importante é que ainda precisamos usar um LLM para criar o harness do Jev, certo? Ele precisa

09:47 descobrir como traduzir o estado do jogo para a entrada do Jev e quais opções de movimentos diferentes podemos oferecer. Então, preparamos tudo isso com antecedência usando o LLM, mas depois todos os nossos testes passam a usar o Jev. Assim, é super-rápido, confiável e econômico. Outra coisa que experimentei no passado com videogames foi permitir que o LLM desacelerasse o jogo. Assim, ele podia jogar quadro a quadro. Essa era, mais ou menos, a minha maneira de fazer o LLM jogar de fato como um usuário antes do Jev, mas, como você

10:17 pode imaginar, era incrivelmente lento e caro. Agora, espero que você também esteja percebendo o padrão que está surgindo à medida que passamos por esses casos de uso. Na prática, nunca vamos usar o Jev sozinho. É muito poderoso usá-lo em combinação com LLMs, porque o Jev é muito bom em tomar decisões, mas não consegue formular as decisões com antecedência a partir do estado nem realmente agir com base nelas. Por isso, a melhor maneira de usar o Jev geralmente é colocá-lo entre chamadas a um LLM. Por exemplo, nos testes de gameplay, usamos um LLM para criar o

10:49 harness e depois agir com base nos bugs que o Jev encontra ao jogar. Ou, no caso da segurança, o agent de programação executa diferentes ações, o Jev analisa uma ação e, se a bloquear, o agent, o LLM, precisa descobrir outra coisa para fazer. Certo? O Jev nunca é realmente o fim do nosso workflow. Ele apenas torna partes dos nossos workflows mais rápidas e eficientes. Outro ótimo exemplo disso nos leva ao nosso terceiro caso de uso: testes de navegador, usando um modelo para percorrer uma página da web e operá-la como um usuário faria, na

11:20 etapa de validação do nosso workflow de programação com IA. É muito parecido com testar jogos. Mas o fato é que, em geral, os LLMs têm se saído razoavelmente bem nisso porque, ao contrário do que acontece em um videogame, normalmente um agent não precisa responder em tempo real a eventos em um site. Assim, ele pode levar o tempo que precisar para analisar a página e escolher a próxima ação. Mas, como você já deve ter imaginado, usar um LLM ainda é lento e caro em comparação com o Jev. E o Jev é ainda mais confiável para esse tipo de automação de navegador. Então, você

11:51 provavelmente usa ferramentas como Playwright MCP ou Agent Browser CLI, da Vercel, para fazer testes de navegador com um LLM. E agora estão surgindo muitas ferramentas open source para fazer a mesma coisa, mas usando Jev em vez de um LLM. E funciona incrivelmente bem. Há muitos exemplos legais aqui mostrando diferentes sites pelos quais o Jev está navegando e clicando. O mais importante é ter em mente que nem sempre dá para usar o Jev para absolutamente tudo, porque ele não consegue gerar texto como um LLM. Então, se alguma coisa exigir

12:21 texto livre como entrada em um site, normalmente você ainda precisa de um LLM em parte do workflow. Mas, tanto quanto possível, você deve usar o Jev apenas para tomar decisões, como em que devo me concentrar ou em qual botão devo clicar. Então, agora, a maior parte do workflow de automação do navegador deve ser conduzida pelo Jev. Vou deixar o link para esse repo do GitHub na descrição. É o melhor projeto open source que vi para usar o Jev no navegador. Mas há muitos outros. E você também pode criar o seu próprio. Tenho criado minha própria automação de navegador com o Jev enquanto o testo. Como neste aplicativo aqui: este é o DynaChat, que está em produção agora. Você pode acessar chat.dynamis.ai e conversar com esse agent. Basicamente, ele consegue pesquisar todo o meu conteúdo do YouTube. E, se você estiver conectado com o mesmo e-mail que usa na comunidade Dynamis, ele também vai buscar conteúdo dos meus workshops e cursos. Então, é um aplicativo muito legal. E testei criar diferentes recursos e fazer o Jev percorrê-los exatamente como um usuário faria. Não vou entediar você com uma execução completa de teste agora, mas quero mostrar rapidinho, ao vivo, o Jev funcionando neste site. E todo texto que você o vir inserir foi gerado previamente

12:51 este app aqui é o DynaChat, que está em produção agora. Você pode acessar chat.dynamis.ai e conversar com esse agent. Basicamente, ele consegue pesquisar todo o meu conteúdo do YouTube. E, se você estiver conectado com o mesmo e-mail que usa na comunidade Dynamis, ele também vai buscar conteúdo dos meus workshops e cursos. Então, é um app muito legal. Testei criar diferentes recursos e fazer o Jev percorrê-los exatamente como um usuário faria. Não vou entediar vocês com uma execução completa do teste agora, mas quero mostrar bem rapidinho o Jev trabalhando ao vivo neste site. E, então, qualquer texto que você o vir inserir foi pré-gerado

13:22 de um LLM, mas todo o resto ele decide em tempo real. A caixa de chat em que clicar, o botão que apertar para entrar, por exemplo. E tudo o que ele faz aqui também pode ser analisado pelo LLM depois, para descobrir se há algum bug em que ele precise iterar. Certo, o último dos quatro casos de uso do Jev é a classificação de workflow. E isso está se tornando cada vez mais importante para mim com o passar do tempo. Quero que meus workflows sejam dinâmicos. Por exemplo, nem sempre quero usar o mesmo modelo de linguagem grande. Isso depende da dificuldade da tarefa.

13:53 Então, para economizar tokens, talvez eu queira algo no início do workflow que classifique qual nível de modelo preciso usar. Outro bom exemplo: às vezes, dependendo do tipo de trabalho que chega, preciso usar skills diferentes ou etapas diferentes. Um exemplo bem claro disso é quando você tem uma issue do GitHub em que quer trabalhar. Pode ser um bug que você precisa investigar e corrigir ou um recurso que precisa planejar e desenvolver. E não quero ter que tomar essa decisão por conta própria. Isso não vai escalar nos meus workflows de programação com IA. Preciso de algo que classifique

14:25 isso e direcione o workflow desde o início. E é para isso que serve o Jev. O workflow exato que estou descrevendo aqui, com as diferentes etapas de classificação, eu construí como um workflow do Arkon. Já falei bastante do Arkon no meu canal. É meu construtor de harness open source, que permite criar workflows maiores de programação com IA com muita facilidade para várias das coisas que abordei neste vídeo. E, claro, venho incorporando o Jev aos meus workflows do Arkon. O que você está vendo aqui é a visualização em grafo, na qual recebemos uma issue do GitHub e usamos o Jev para classificar duas

14:57 coisas. Qual nível de modelo precisamos para resolver isso? Porque talvez seja algo muito simples e possamos usar algo como Sonnet 5. E também decidir qual caminho seguir. É, como mencionei antes, um bug que precisamos investigar e corrigir ou um recurso que precisamos planejar e desenvolver? Este é o arquivo YAML que compõe todo o workflow do Arkon. E, para cada etapa em que quero chamar o Jev, tenho este script Python, no qual forneço os argumentos e ele formula a decisão, pergunta ao Jev e, em seguida, o restante do workflow age com base na

15:27 saída do Jev. Vou até mostrar rapidamente o script Python, porque podemos ver, bem no início, todas as perguntas que estamos enviando ao Jev. É muito poderoso poder fazer um monte de perguntas que o Jev responde em paralelo por um custo baixíssimo. Por exemplo: que tipo de trabalho esta issue do GitHub solicita? É um bug ou um recurso? Isso determina as skills que usamos no restante do workflow. Qual é o nível de modelo de que precisamos, certo? Ou seja, com base na dificuldade da tarefa, um modelo rápido, como, sei lá, GPT-6 Terra; algo padrão, como Sonnet 5 ou GPT-6 Soul; ou talvez um modelo potente, como

15:59 Opus 5.5 ou GPT-6 Astra. Deu para entender, certo? O Jev toma essa decisão e, nos meus testes, geralmente entende muito bem a dificuldade e o tipo das tarefas. Voltando a esta execução específica da classificação, ele concluiu que era um bug que precisava ser investigado. E, quanto à seleção do nível, vou acessar os logs rapidinho. Sei que é meio difícil de identificar, mas, quando a etapa seguinte foi executada, ela investigou usando o nível padrão, ou seja, aquele nível intermediário de modelo. Então, seja qual for o modelo que eu tiver selecionado para esse nível,

16:30 algo como Sonnet 5. E, claro, eu mesmo fui o avaliador em todos os testes do Jev que fiz aqui. Executei este workflow do Arkon 12 vezes e, em todas elas, concordei completamente com as decisões e classificações feitas de início. Há também um workflow separado do Arkon, mais voltado à revisão de pull requests. Nesse caso, usamos a classificação no início para descobrir que tipo de revisão é necessária. Por exemplo, é algo maior que exige uma revisão completa de arquitetura ou apenas uma tarefa simples que precisa ser validada rapidamente? Não foi perfeito, mas acertar 15 de 16 é muito bom. E, se

17:00 olharmos o custo, é uma fração de centavo, em comparação com o que normalmente custaria usar um LLM. E, de novo, 32 centavos por pull request vão mesmo se acumular, especialmente em um projeto como o Arkon, em que lidamos com dezenas ou centenas de pull requests e issues toda semana. Então é isso. Esses são meus quatro casos de uso favoritos do Jev em workflows de programação com IA. E, claro, me contem nos comentários se quiserem que eu faça um vídeo dedicado a qualquer um deles, porque certamente posso aprofundar muito mais e ajudar vocês a incorporá-los aos seus workflows também. E, se você gostou deste vídeo,

17:31 está com vontade de ver mais conteúdo sobre Jev e programação com IA, eu agradeceria muito se deixasse um like e se inscrevesse no canal. E, com isso, vejo vocês no próximo vídeo.

Transcrição original

[00:00] Jev is incredible. It was released recently and it popularized a type of AI model called system one models, which specialize in making decisions instead of generating text. And so, it’s actually way different from LLMs like Claude and GPT. And so, it’s opened up a whole new sprawl of use cases that everyone is sharing on the internet right now. And people are sharing a lot of really fun and cool use cases with Jev, but something I’m hearing a lot, especially from people in my Dynamis community, is that the use cases are

[00:30] cool, but they’re not always the most practical, right? There’s not a lot that you see and you’re like, “Okay, I need to go incorporate this in my AI workflows right now.” And so, that’s why I want to make this video, just quickly showing specifically for AI coding, four incredible Jev use cases to make your AI coding workflows faster and more token efficient, which is a big deal right now, especially with how bad the rate limits are. Now, if you follow the latest in AI, there is a very good chance that you’ve heard of Jev and probably even tried it out for yourself. Now, Jev is not the first kind of

[01:01] decision model like this, but that’s a whole other topic for another video. The point is, Jev is really powerful. The way it works is you give it some kind of situation, which they call state, and then you also supply with a list of multiple-choice questions, and in parallel, it’s going to answer each one of those questions with a probability, which is basically its confidence score. Now, the thing is, you can already do this with large language models, especially with structured output, you can have it make decisions that you can key off of for of your workflow. But, what makes Jev so awesome is that it is

[01:32] 20 to 200 times faster than LLMs at making decisions, and it’s also 40 to 1,000 times cheaper. Obviously, the big range here being you can use different LLMs to compare against Jev, but no matter the LLM that you use, Jev is going to be more accurate, faster, and cheaper for making any kinds of decisions. And so, at a high level, when you think of like Jev as the decision-maker, there’s an endless number of possibilities that you can use it for. And so, that’s why I want to get really specific with you here, just

[02:02] quickly showing you, giving you inspiration for different ways that we can use it very practically. Now, for each one of these Jev use cases, they’re valuable enough where I can make an entire video going into how to build and incorporate it. But for right now, I just want to stay more high-level. I want to keep this short and sweet, giving you inspiration here so you can even pick a couple of these and maybe build them out yourself. And then also, in my Dynamist community this Friday, I am running a workshop getting a lot deeper into these use cases. So, check that out if you’re interested. And yeah, like I said, a lot more content coming soon diving deeper into Jev, cuz this is

[02:34] exciting for me. I actually said this in my first video on Jev. This is the first AI model in a while that I’m genuinely excited for. And I think you’ll see why as we get into these four use cases here. So, with that, let’s just get right into it. My favorite use case for Jev right now in my AI coding workflows is for security. Cuz the thing is, and you probably seen this yourself, AI coding assistants are way too willing to do things that they shouldn’t, like read your environment variables, delete an entire folder, even if you have things in your global rules or skills to not do

[03:06] this, especially once you really start to bloat the context of a conversation, or if you have a prompt that kind of gives it a workaround, it’s going to figure out ways to do these things. And so, that’s why we need guardrails to prevent our agents from performing destructive actions. And Jev can really be that guardrail. So, the most popular and effective way to implement these guardrails for our coding agents is using hooks, which was introduced in Claude code, but now pretty much every single coding agent has the idea of hooks, where we can attach automations

[03:36] to run at different events that take place in the life cycle of our coding agent. And so, the most popular event is pre-tool use. So, when the agent is about to perform an action, like read a file or run a command, we can run an automation to basically analyze that and either block the agent from performing that action or allow it to continue. And so you can see where we’re going with this here because one of the most popular use cases is having a pre-tool use hook that tries to analyze the agent’s action to determine if it’s going to read a .env file, right? We

[04:07] don’t want our secrets exposed into the context of our coding agent. And so it has the opportunity to dish out an error code to essentially block that action so the agent has to do something different. Like for example, reading the .env.example instead. Now, the problem with this hook until Jev is that we either have to have an LLM analyze every single call or we have to have some kind of deterministic process with regular expressions. Either way, it’s going to be expensive or not

[04:37] very accurate. Now, let’s just scrap the idea of using an LLM right away cuz if we’re going to analyze every single action the agent wants to take, that’s going to cost you hundreds or thousands of dollars throughout the month just to block these sensitive calls that might happen once in a while. And so what I’ve done until Jev is I use regular expressions. And so I have a hook that runs that just does pattern matching to try to figure out the agent is trying to do something like reading my Google credentials, reading my .env, deleting a folder, whatever it is. But the problem is there are so many different ways that

[05:07] an agent is able to do these destructive actions cuz it can read the file directly, it can write a Python script to do so, or a bash command, like right? There are a million different things. And so we have this massive laundry list here and this doesn’t even catch everything. And there are also a lot of false positives. And so what I’ve done is I’ve taken this pre-tool use hook and I’ve replaced it with my Jev Guard. And I’ll show you some stats in a little bit. This is so cost-effective and reliable. So a system one models, again, we give it state and a list of multiple choice questions. And so for anything

[05:38] that can go wrong with an agent action, I’m asking if it is the case, right? Like are we exposing secrets? It’s going to say either true or false and we give some instructions for added context. This is part of the state. And then, is it destroying any data, like removing an entire folder, any kind of exfiltration, where we’re maybe sending sensitive data out like through a prompt injection attack. And then, another really cool one here is where can just analyze is the agent going off task. And so, we can use this pre-tool use hook for even more than just security, just generally having another sort of model as a judge,

[06:10] making sure that we’re staying on track for what we are trying to accomplish. And then, as far as the state goes, the situation that’s the main input to Jev, we’re giving it the tool name, the effect of it, the input, like the arguments to the tool, and also our current working directory. And so, that gives it the holistic picture. And so, when I ask Jev, I’m actually just using Jev right through Open Router with their new decision endpoint. And then, I’m giving it this state along with all the questions that I showed you above. So, I’ve only been using this hook for a little bit since Jev just came out, but my initial results are incredible. So,

[06:41] my previous version of the hook using regular expressions, you can see that it didn’t block that many of the risky calls. Now, obviously, risky is subjective. I’ve been pretty happy with this hook overall, but the main problem I’ve had with it is the false positives, blocking things that really shouldn’t be blocked, like just writing the word {dot} env out to a markdown document. And then, going to using an LLM, it does a really good job. I mean, not that many false positives, it blocks most risky calls. But even using something really fast and cheap like Haiku, it still takes over a second. And yeah, it’s only

[07:12] about a tenth of a penny per analysis, but that really adds up when your agent makes thousands of calls every single day. And then, we get to Jev. Jev blocks almost every single risky call, barely has any false positives. It is a quarter of a second for every single analysis, and it is a fraction of a fraction of a penny. So, it’s cost-effective, and it’s fast. It gives us essentially the reasoning capability of an LLM for this kind of decision, but it feels like it’s free. I mean, I know it’s not quite free, but yeah, it’s not like it breaks

[07:43] the bank in any way. All right, so our next use case is game a play testing. And this really applies to any type of application that requires a model to make snap decisions or respond to things in real time. I’m just using video games as an example cuz it’s really cool to watch Jeff play the game and it is something that I’m building myself for real. And so, with anything like a game, when you have 60 frames per second or 30 frames per second, a large language model is way too slow to respond to things. By the time it analyzes the scene to make a decision, the scene is

[08:14] already passed, right? And the character is going to be dead in the game, for example. But Jeff is able to keep up. It is incredible to watch. And this is also very practical because we always want to have that validation step in our AI coding workflow. So, for a video game, you know, after we build the next feature, we want the model to be able to play the game as a user actually would. And that wasn’t really realistic before until Jeff. So, take a look at this. I have a live example of Jeff playing one of the games that I’m building a proof of concept for right now. It looks like

[08:45] I’m playing. The character is attacking, dodging, moving around the map. You can see the decisions that Jeff is making on the left-hand side right here. Probabilities for all the different actions that we’re giving as the options cuz again, it’s all about the state, which is, you know, where everyone is in the game, and then the decisions, like what move are we going to do next? And I have hands off the keyboard. It seriously looks like I am playing this right now. It is so cool. And so, as it’s making the decisions and processing the state of the game, we can also analyze how things are going in general and act on that, right? Like maybe we do

[09:15] discover bugs for real as we’re playing the game, the kind of thing that an LLM could never really discover by itself just by, you know, running unit tests. And so, I’ve been running this for real as I’ve been building new features in the game, and it’s genuinely caught bugs that the large language model was not able to by itself cuz the LLM can’t really play the game. And yes, it can run like other tests and harnesses that I build, but that’s more deterministic and it’s not really playing the game as a user actually would. And so, the important thing is we still have to use a large language model to build the harness for Jev, right? Like it has to

[09:47] figure out how do we translate the state of the game into the input to Jev, what are the options that we give it for different moves it can perform. So, we build that up front with the LLM, but then all of our testing going forward uses Jev. So, it’s super fast, reliable, and cost-effective. One other thing that I have experimented with in the past for video games is making it so that the large language model can actually slow down the game. So, it can play it frame by frame. That was kind of my way to have it actually play the game as a user would before Jev, but as you can

[10:17] imagine, that was incredibly slow and expensive. Now, I hope you can also see the pattern emerging as we’re going through these use cases. We are never really going to use Jev by itself. It is super powerful to use it in combination with LLMs because Jev is really good at making decisions, but it can’t craft the decisions in the state up front or really act on them. And so, the best way to use Jev is generally to sandwich it in between calls to a large language model. Like for example, with gameplay testing, we have an LLM build the

[10:49] harness and then act on the bugs that Jev finds when it plays the game. Or with the security here, we have the coding agent performing different actions, Jev analyzes an action, and if it blocks it, then the agent, the LLM, has to figure out something else to do. Right? Jev is never really the end of our workflow. It’s always just making parts of our workflows faster and more efficient. Now, another really good example of this takes us to our third use case with browser testing using a model to go through a webpage and operate it as a user would in the

[11:20] validation step of our AI coding workflow. It’s very similar to gameplay testing. But the thing is, large language models have typically been decent at this because unlike with something like a video game, an agent doesn’t have to respond in real time to events with a website, usually. And so it’s able to take its time and analyze the page to pick the next action. But, you guessed it, it is still slow and expensive using an LLM compared to Jev. And Jev is even more reliable for this kind of browser automation. So, you

[11:51] probably use tools like the Playwright MCP or Vercel’s Agent Browser CLI to do browser testing with an LLM. And now we have a lot of open-source tools coming out the same kind of thing but using Jev instead of an LLM. And it works incredibly well. There’s a lot of cool examples here showing different websites that Jev is clicking around. The most important thing to keep in mind is you don’t always have the opportunity to use Jev for literally everything because Jev can’t generate text like an LLM can. So, if there’s anything that requires

[12:21] free-form text as an input to a site, typically you still need a large language model for part of the workflow. But as much as you possibly can, you want to use Jev just making decisions like what should I focus on or what button should I click. And so most of the workflow for your browser automation should be driven by Jev now. So, I’ll link to this GitHub repo in the description. This is the best open-source project I’ve seen for Jev browser use. But yeah, there are a lot of them. And you can also roll your own. I built my own browser automation with Jev as I’ve been testing it out. Like on

[12:51] this app right here, this is DynaChat, which is in production right now. You can go to chat.dynamis.ai and talk to this agent. It basically is able to search through all my YouTube content. And then if you’re logged in with the same email you use in the Dynamis community, it’ll also pull from my workshop and course content. So, it’s a really cool app. And I’ve tested building different features and having Jev go through them exactly as a user would. So, I won’t bore you with a full test run right now, but I do want to show you just really quickly live Jev working on this site. And so any text that you see it input is pre-generated

[13:22] from an LLM, but everything else it is deciding live. The chat box to click into, the button to press to sign in, for example. And then also everything that it’s doing here can be analyzed by the LLM after to figure out if there’s any bugs that it needs to iterate on. All right, the last of the four use cases here for Jev is workflow classification. And this is becoming more and more important for me over time. I want my workflows to be dynamic. For example, I don’t always want to use the same large language model. It depends on the difficulty of the task.

[13:53] And so for the sake of token efficiency, I might want something at the start of the workflow that classifies what tier of model I need to use. Another good example is sometimes based on the type of work that comes in, I need to be using different skills or different steps. And so a really clear example of this is when you have a GitHub issue that you want to work on. It might be a bug that you have to investigate and fix or a feature that you have to plan and build. And so I don’t want to have to make that decision for myself. That’s not going to scale with my AI coding workflows. I need something to classify

[14:25] that and direct the workflow at the beginning. And that is what Jev is for. And this exact workflow I’m describing to you here with the different classification steps, I have built that as an Arkon workflow. So I’ve covered Arkon a lot on my channel before. It’s my open-source harness builder that allows you to build these larger AI coding workflows very easily for a lot of the different things that I’ve been covering in this video. And of course, I’ve been incorporating Jev with my Arkon workflows. And so what you’re looking at right here is the graph visualization where we take in a GitHub issue and we use Jev to classify two

[14:57] things. What is the tier of model that we need to knock this out? Because maybe it’s something super simple and we can just use something like Sonnet 5. And then also deciding the route. Is this, again, like I said earlier, a bug we have to investigate and fix or is it a feature we have to plan and build out. And so this is the YAML file that makes up the entire Arkon workflow. And for each step where I want to call upon Jev, I just have this Python script where I give the arguments and it forms the decision, asks Jev, and then the rest of the workflow is going to act on the

[15:27] output of Jev. And I’ll even quickly show you the Python script because we can see all the questions we’re sending into Jev at the very top. It is so powerful how you can ask a ton of questions that Jev will answer in parallel for super cheap. So like what kind of work does this GitHub issue ask for? Is it, you know, a bug or a feature? That that determines the skills that we use for the rest of the workflow. What’s the tier of model that we need, right? Like based on the difficulty of the task, a fast model like, I don’t know, GPT-6 Terra, something standard like Sonnet 5 or GPT-6 Soul, maybe a strong model like

[15:59] Opus 5.5 or GPT-6 Astra. You get the idea, right? Like Jev is making that determination and in my testing it does a very good job just generally understanding the difficulties of tasks and the type of tasks. And so back over to this specific run for the classification here, it figured that it is a bug that needs to be investigated. And then for the tier selection here, I’ll go to the logs really quickly. I know it’s kind of hard to pick out, but when the next step ran, it did investigate standard as in it was using that middle tier of the model here. So whatever I have selected for that,

[16:30] something like Sonnet 5. And of course, I was the judge myself for all the Jev testing that I did here. So I ran this Arkon workflow 12 times and every single time I completely agreed with the decisions, with the classifications that it made up front. There’s also a separate Arkon workflow more for pull request reviewing. And so using classification up front to figure out what kind of review do we need. Like is this a bigger thing that needs a full architecture review or just a light chore that has to be validated quickly? And it wasn’t perfect, but still 15 out of 16 is pretty darn good. And if we

[17:00] look at the cost here, a fraction of a penny versus what it would typically cost an LLM. And again, 32 cents per pull request, that is really going to add up especially with a project like Arkon where we are dealing with dozens, hundreds of pull requests and issues every week. So there you have it. Those are my four favorite use cases for using Jev in AI coding workflows. And of course, let me know in the comments if you want me to make a dedicated video for any of these cuz I could certainly go a lot deeper and help you incorporate these into your workflows as well. And so, if you appreciated this video,

[17:31] you’re looking forward to more things on Jev and AI coding, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.