Cada processo seletivo deveria facilitar o próximo.

• Cada candidato que você entrevistou.
• Cada screening.
• Cada avaliação.
• Cada conversa.
• Cada motivo pelo qual alguém avançou, ou não.
• Cada pessoa que era excelente, só que não para aquela vaga.
• Cada candidato que não estava disponível oito meses atrás e talvez esteja hoje.

Tudo isso deveria virar um ativo da empresa. Se você contrata há cinco anos, deveria ter cinco anos de vantagem acumulada.

Cinco anos contratando, cinco anos de vantagem

Recrutamento tem o mesmo formato dos juros compostos. Um único processo gera uma pequena quantidade de conhecimento reutilizável: uma dúzia de pessoas que você chamaria de novo com prazer, algumas notas sobre por que o mercado recusou sua faixa salarial, uma avaliação que mostra o que "sênior" realmente significava para aquele time. Sozinho, parece nada. Guardado e somado ao próximo processo, e ao seguinte, deixa de parecer nada.

Vale notar duas coisas nesse gráfico. A primeira é a distância: no décimo processo, um time abre uma vaga com sessenta e poucas pessoas qualificadas que já conhece, já avaliou, com notas sobre cada uma. O outro abre com três nomes e um anúncio de vaga. A segunda é o formato da linha cinza. Ela nunca sobe. Dez processos de trabalho e o ponto de partida é o mesmo do primeiro dia.

É isso que acontece quando cada nova vaga começa publicando de novo, esperando candidaturas e lendo currículos do zero. A vantagem que você deveria ter construído simplesmente desaparece.

O problema do Excel não é o Excel

É fácil culpar a planilha, e ela merece parte da culpa. Não tem uma busca digna do nome, não tem histórico por pessoa, não tem ligação entre o currículo, a entrevista e a decisão. Mas os times que migraram para um ATS de verdade e mantiveram os mesmos hábitos têm o mesmo problema com uma interface mais bonita.

O problema real é que seu processo de contratação gera informação todos os dias, e você está deixando a maior parte desse conhecimento vazar. Ele vaza em lugares específicos:

1. A rejeição sem motivo. "Arquivado" não diz nada ao próximo recrutador. "Backend forte, queria 100% remoto, revisitar se abrirmos vagas remotas" diz tudo.
2. A entrevista que vive na cabeça de alguém. O melhor sinal de todo o processo é a conversa, e normalmente é a parte que nunca é registrada.
3. O medalha de prata. A pessoa que ficou em segundo lugar para uma vaga é, por definição, um candidato pré-qualificado para a próxima vaga parecida. A maioria dos sistemas arquiva essa pessoa junto com quem não passou na primeira triagem.
4. O "agora não". Alguém que tinha acabado de começar num emprego, estava se mudando ou tinha outra proposta. O timing era o único problema, e ninguém anotou quando tentar de novo.
5. O processo que começa com um anúncio de vaga. Se o primeiro passo de uma nova vaga é publicá-la em vez de buscar no que você já tem, a base não está sendo usada mesmo quando existe.

Nenhuma dessas é uma falha de software. São momentos em que o processo produziu algo valioso e nada capturou isso.

O ciclo

Um bom ATS não deveria ser só o lugar onde você gerencia candidatos. Deveria ser uma base de talentos que fica mais valiosa a cada processo. Isso só acontece se o processo for um ciclo, não uma linha:

O que as ferramentas estão fazendo a respeito

O mercado percebeu. Redescobrir talentos que você já tem virou uma feature de destaque em todo o setor, e vale a pena olhar como cada produto aborda isso:

• Ashby lançou o AI Talent Rediscovery, que avalia as pessoas que já estão na sua base contra os critérios de uma nova vaga, atualiza perfis desatualizados e usa sinais como avanço de etapas e notas de scorecard para ranqueá-las. O CRM agrupa contatos em talent pools que podem ir direto para um pipeline ativo.
• Greenhouse tem Talent Rediscovery e filtragem de talentos sobre candidatos e prospects anteriores, filtrável por scorecard, marco atingido e motivo de rejeição, junto com um CRM para prospects de sourcing.
• Manatal lê a descrição da vaga e pontua os candidatos que já estão no seu pool contra ela com matching semântico, então candidatos anteriores aparecem para novas vagas sem busca manual.
• Spott é um ATS e CRM AI-native para agências de recrutamento, construído em torno de uma base de recrutamento pensada para continuar útil com o tempo, alimentada por memória de conversas e processamento de transcrições de entrevistas.
• Selenios, onde sou CTO, então leia esta com isso em mente. Nossa aposta está no lado de entrada do ciclo: screenings, entrevistas e avaliações viram notas estruturadas vinculadas ao candidato, então a base fica mais densa a cada conversa e não só a cada currículo.

Repare do que cada uma dessas features depende. O rediscovery ranqueia pessoas usando os scorecards, os motivos de rejeição, as notas e o histórico de etapas que seu time registrou. Um modelo de matching é tão bom quanto aquilo que ele consegue ler. Aponte o melhor motor de rediscovery do mercado para uma base cheia de cards arquivados sem motivos e sem notas, e ele vai redescobrir currículos. É tudo o que ele tem.

Hábitos que fazem a base render juros compostos

A ferramenta é necessária, mas não suficiente. Estes são os hábitos que definem se o seu ATS vira uma base de talentos ou um arquivo morto:

1. Busque antes de publicar. O primeiro passo de cada nova vaga é uma consulta nas pessoas que você já conhece. Publicar vem depois.
2. Toda rejeição leva um motivo. Um motivo curto e estruturado. "Skills", "senioridade", "salário", "localização", "timing", mais uma frase. Leva dez segundos e é o dado mais reutilizável que você vai produzir.
3. Marque os medalhas de prata. Quem chegou às etapas finais é um lead para a próxima vaga parecida. Faça com que sejam encontráveis como tal.
4. Coloque uma data no "agora não". Se o problema foi timing, anote quando isso pode mudar e deixe o sistema te lembrar.
5. Registre a conversa. Notas de entrevista e avaliações pertencem ao perfil do candidato, não a um doc, uma thread de chat ou à memória de alguém. Se valeu uma hora do tempo de um entrevistador, vale a pena guardar.
6. Meça. Acompanhe quantas contratações e finalistas vêm de pessoas que já estavam na sua base. Se esse número não cresce ano após ano, a base não está rendendo juros compostos.

Uma base, ou um histórico

Um ATS usado como quadro te dá um registro organizado do que aconteceu. Um ATS usado como base de talentos te dá vantagem sobre o que vem a seguir. A diferença não é o software que você comprou. É se cada processo deixa algo para trás que o próximo possa usar.

Se, depois de anos contratando, seu próximo processo ainda começa do zero, você não construiu uma base de talentos. Construiu um histórico.

O que é batch inference

Em tempo real, cada request espera sua resposta. Em batch não existe conversa. Você escreve um arquivo com um objeto JSON por linha, milhares de prompts, e sobe para um bucket. Você diz ao provedor "processa isso quando der". Algum tempo depois aparece outro arquivo com todas as respostas. Nenhum servidor seu esperando em sockets, nenhuma lógica de retry, nenhuma fila para você operar.

No Amazon Bedrock, que é onde rodamos, o input é um arquivo JSONL no S3 em que cada linha carrega um identificador e o mesmo body que você mandaria para o InvokeModel:

{"recordId":"a1f3c9e2","modelInput":{ …the InvokeModel body for cv 1… }}
{"recordId":"9c02b7d4","modelInput":{ …the InvokeModel body for cv 2… }}
…
{"recordId":"0d41f8a7","modelInput":{ …the InvokeModel body for cv N… }}

Depois, uma única chamada de API cria o job:

import { BedrockClient, CreateModelInvocationJobCommand } from '@aws-sdk/client-bedrock';

const { jobArn } = await bedrock.send(new CreateModelInvocationJobCommand({
  jobName: `cv-parse-${runId}-${shard}`,
  modelId,
  roleArn,
  inputDataConfig: { s3InputDataConfig: { s3Uri: `s3://${bucket}/input/${runId}/${shard}.jsonl` } },
  outputDataConfig: { s3OutputDataConfig: { s3Uri: `s3://${bucket}/output/${runId}/` } },
}));

A partir daí você faz polling do status do job e, quando ele termina, lê os arquivos de output, casa cada linha com seu recordId e segue o seu pipeline como se as chamadas tivessem sido feitas uma a uma.

Por que custa a metade

Porque você está vendendo ao provedor a única coisa que sobra para ele: capacidade ociosa. As frotas de inferência são dimensionadas para o pico de tráfego interativo e, fora do pico, as GPUs ficam parcialmente vazias. Quando você abre mão de latência, eles recebem trabalho que podem encaixar nesses buracos, e o preço do token cai 50%.

Não é promoção nem desconto negociado. É o preço de tabela do modo batch no Amazon Bedrock, Anthropic, OpenAI e Gemini, os quatro pela metade da tarifa on-demand. Mesmo modelo, mesmos pesos, mesmo output. A única coisa pela qual você paga menos é a promessa de uma resposta imediata.

Um caso real: uma migração com anos de histórico

Recentemente migramos um cliente que vinha de outro sistema de recrutamento. Isso significa dezenas de milhares de CVs diferentes e, junto com eles, as vagas, as notas dos recrutadores, as movimentações entre etapas do pipeline e as avaliações de anos de histórico. Cada CV passou por um modelo de linguagem no Bedrock para extrair sua estrutura no formato que o nosso produto espera.

A conta on-demand teria sido um número. A conta em batch foi exatamente a metade, com o mesmo modelo e os mesmos resultados. Não vou colocar valores absolutos aqui, e não importa: o ponto é a proporção, e ela se mantém em qualquer escala. Leve isso para milhares de candidatos com todo o histórico e a conta continua a mesma. Metade.

Existe uma segunda economia que não tem nada a ver com batch e que você deveria fazer de qualquer jeito: antes de mandar qualquer coisa, fazemos hash de cada arquivo. Num sistema de recrutamento, o mesmo CV aparece anexado a muitas candidaturas. Um candidato que se candidatou a cinco vagas tem cinco cópias do mesmo PDF. Com um MD5 do arquivo como chave, o mesmo CV é parseado uma única vez e o resultado é replicado para cada candidatura que o referencia. O token mais barato é aquele que você nunca manda.

A vantagem de que ninguém fala: batch não compete com a produção

O preço é a manchete, mas não é o melhor motivo. O tráfego on-demand sai de um pool compartilhado e, quando esse pool enche, o provedor responde com um 503 e uma mensagem de "insufficient capacity". Já passamos por isso. Agora imagine que, além do seu tráfego normal, você dispara milhares de chamadas de um script de migração pelo mesmo canal, com o mesmo modelo e a mesma conta. Quem paga são seus usuários, em latência e em erros, nas telas que eles realmente usam.

Batch é outra fila, com outra cota. A migração roda de madrugada e a plataforma nem percebe. A própria orientação do Bedrock para erros de capacidade no on-demand diz a mesma coisa: mova as cargas offline para batch. Esse foi o argumento que me convenceu mais do que o desconto. Pagar metade é ótimo. Trabalho em massa que nunca encosta na experiência de quem usa seu produto é o ganho de verdade.

O que ele cobra em troca

Nada é de graça, então aqui vai a conta, com os detalhes do Bedrock porque é onde rodamos:

1. Latência. Minutos ou horas, com o compromisso de terminar em até 24 horas. Você não escolhe quando.
2. Menos features. No batch do Bedrock não há tool calling nem structured output. Você pede JSON no prompt e faz o parse você mesmo, com a mesma validação que usaria para qualquer output de modelo não confiável.
3. Sem caminho de OCR em vários modelos. Se parte do seu input são imagens escaneadas, elas precisam de uma rota on-demand própria.
4. A ordem do output não é garantida. A linha 1 do input não é a linha 1 do output. O recordId é a única coisa que liga uma à outra.
5. Um mínimo por job. Por padrão, 100 registros. Com menos que isso, o job é rejeitado.

Se o seu caso de uso é interativo, nada disso funciona. Se ninguém está esperando a resposta, tudo isso é aceitável.

O checklist que aprendemos do jeito difícil

Nada disso está no guia de getting started. Tudo nos custou algo na primeira vez.

• Deduplique antes de mandar. Faça hash do arquivo, não da candidatura. Um parse por CV, não um por candidatura.
• Respeite as cotas. No mínimo 100 registros por job, 1 GB por arquivo de input, 5 GB por job. Nós fazemos shards de 50.000 registros.
• Junte o último shard se ele ficar curto. 50.050 registros divididos ingenuamente em shards de 50.000 geram um shard final de 50, e esse job é rejeitado. O fix são três linhas, e é o tipo de bug que você só encontra com dados reais:

  function shard<T>(items: T[], size = 50_000, min = 100): T[][] {
    const shards: T[][] = [];
    for (let i = 0; i < items.length; i += size) shards.push(items.slice(i, i + size));
    const last = shards.at(-1);
    if (shards.length > 1 && last && last.length < min) shards.at(-2)!.push(...shards.pop()!);
    return shards;
  }

  O shard combinado fica um pouco acima do tamanho-alvo, então mantenha o alvo bem abaixo dos limites reais.
• Persista o estado de cada job assim que ele for aceito. Um job é cobrado a partir do segundo em que o provedor o aceita. Se o seu script cair depois de criar o job mas antes de salvar o ARN, e você relançar, paga duas vezes pelo mesmo trabalho. Grave o ARN do job e o shard que ele cobre em armazenamento durável antes de qualquer outra coisa, e faça o launcher pular os shards que já têm um job.
• Use identificadores curtos e únicos. O output volta fora de ordem, então cada linha precisa de um recordId que mapeie de volta para os seus dados sem ambiguidade. Um hash curto funciona melhor que uma chave composta longa que você vai ter que parsear depois.
• Valide com o mesmo parser que você usa no on-demand. O import não deveria conseguir distinguir por qual caminho um resultado veio. Se o output do batch precisa de um parser próprio, agora você tem duas fontes de verdade e uma delas vai divergir.
• Apague todos os arquivos do bucket quando terminar. Inputs e outputs. São CVs, ou seja, dados pessoais, e nada deveria ficar no S3 depois que o import for verificado. Faça a limpeza ser parte do job, não uma nota num runbook.

Quem suporta

Os quatro grandes provedores oferecem com 50% de desconto, com limites diferentes. Nesta semana:

Se você já usa o AI SDK, existe um caminho mais simples para batches pequenos. O AI Gateway da Vercel suporta batch via experimental_startBatch, experimental_getBatchStatus e experimental_getBatchResults, sem S3 envolvido: os requests vão inline, até 1.000 por batch e 4,5 MB, e o mesmo código funciona com modelos da OpenAI e da Anthropic.

import {
  experimental_startBatch as startBatch,
  experimental_getBatchStatus as getBatchStatus,
  experimental_getBatchResults as getBatchResults,
} from 'ai';

const batch = await startBatch({
  requests: cvs.map((cv) => ({
    id: cv.hash,
    type: 'text',
    model: modelId, // any OpenAI or Anthropic model on the gateway
    prompt: buildParsePrompt(cv.text),
  })),
});
await saveBatchReference(batch); // { version, id, provider }: persist it before anything else

// later, from a cron or a worker
const { status } = await getBatchStatus({ batch });
if (status === 'completed') {
  for await (const item of getBatchResults({ batch })) {
    if (item.status === 'succeeded') await importParsedCv(item.id, parseCv(item.text));
  }
}

Mesmo formato da versão com Bedrock, sem precisar cuidar de um bucket, de uma role e da limpeza. É ideal para batches pequenos e médios. Para dezenas de milhares de CVs, o arquivo no S3 continua sendo a ferramenta certa.

A regra

A decisão inteira cabe numa pergunta: tem alguém esperando por esta resposta? Se sim, on-demand. Se não, batch. Migrações, re-scoring em massa, enriquecimento de dados, evals, classificação de registros históricos: nenhum deles tem um humano do outro lado olhando um spinner, e todos estão pagando o dobro se rodam on-demand.

Mesmo modelo, metade do preço, e seus usuários nem percebem. E, sinceramente, a metade do preço é o de menos. O que importa é que o trabalho em massa nunca encoste na experiência de quem usa o seu produto.

Uma nota prática antes do argumento: no momento em que escrevo, a Vercel está com uma promoção de lançamento e o Jev é gratuito no AI Gateway até 25 de setembro. Depois disso custa USD 0.042 por milhão de tokens de input, e o output é gratuito porque não existe output. De qualquer forma custa quase nada, e isso faz parte da história.

O que é o Jev, em um parágrafo

Você passa ao Jev um estado (uma string, um objeto JSON, até 32k tokens) e um conjunto de perguntas. Cada pergunta é uma de três primitivas: um boolean ("esta afirmação é verdadeira?"), um choice ("qual destas opções?") ou um score ("onde fica nesta escala ordenada?"). Ele responde cada pergunta com um valor tipado e uma distribuição de probabilidade, e nada mais. Sem prosa, sem trace de raciocínio, sem JSON para parsear. A TypeSafe treina o modelo com um método que eles chamam de Reinforcement Learning for Calibrated Decisions, então as probabilidades são otimizadas contra resultados, e não contra a preferência de um humano por uma resposta bonita. Um 0.97 deveria acertar cerca de 97% das vezes.

Pelo AI SDK fica assim:

import { experimental_evaluate as evaluate } from 'ai';

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state: { url, title, visibleText },
  questions: {
    signedIn: {
      type: 'boolean',
      instructions: 'Is the user signed in, judging from the page?',
    },
    section: {
      type: 'choice',
      instructions: 'Which section is the page showing?',
      criteria: { dashboard: null, login: null, other: null },
    },
  },
});
// result.answers.signedIn.probability   -> 0.9
// result.answers.section.choice         -> 'dashboard'
// result.answers.section.probabilities  -> { dashboard: 1, login: 0, other: 0 }

Essa é a API inteira. O pacote ai adicionou experimental_evaluate na 7.0.105 exatamente para essa classe de modelo, e o gateway o expõe como um "evaluation model" ao lado dos modelos de linguagem, de embeddings e de imagem. É uma coluna nova no catálogo, não uma linha nova.

Por que isso é mais importante que um classificador barato

Olhe onde as chamadas a LLMs realmente estão em um codebase em produção. Uma minoria gera texto que um humano vai ler. A maioria toma uma decisão sobre a qual o código vai agir: rotear este ticket, este CV atende à pergunta eliminatória?, esta mensagem é urgente?, qual destes cinco candidatos é o que o usuário quis dizer?, este passo deu certo? Por três anos, o jeito de obter essa decisão foi pedir a um modelo de chat que, por favor, respondesse em JSON, parsear o JSON, tentar de novo quando não parseia, e tratar a resposta como binária porque o modelo não te dá um número honesto de quão seguro ele está.

Cada uma dessas chamadas paga por geração. Você paga pelos tokens de output, espera o stream deles, e herda um modo de falha (output malformado) que não tem nada a ver com a decisão. Os modos de structured output deixaram o parsing mais confiável, mas não mais rápido nem mais barato, e os logprobs, onde existem, não são calibrados. O Jev elimina a etapa de geração por completo. A decisão é o output. Não há nada para parsear, nada para tentar de novo por questões de formatação, e o número que volta significa o que diz.

A consequência é que decisões ficam baratas o suficiente para você tomar muitas. Faça cinco perguntas sobre o mesmo estado e elas rodam em paralelo em um único request. Faça uma pergunta especulativa que talvez você nem precise. Dê nota a cada candidato em quatro dimensões e deixe o ranking ser uma soma ponderada que você pode mudar sem outra inferência. É um jeito diferente de escrever software em volta de um modelo, e é por isso que a documentação da TypeSafe parece mais um guia de programação do que um guia de prompting. O modelo é uma primitiva. O código é dono do workflow.

O que o Jev não consegue fazer é igualmente importante, porque os limites são o design. Ele não gera, então não consegue escrever um seletor, um resumo, um e-mail ou uma linha de código. Não consegue planejar. Lê texto, não imagens. Se a sua tarefa precisa de alguma dessas coisas, você ainda precisa de um modelo de linguagem. O modelo mental certo não é "um LLM menor", e sim "o julgamento rápido e calibrado que você coloca antes, ao lado ou depois do LLM".

O que eu construí: um loop de QA em que o Playwright dirige e o Jev julga

Testes end-to-end no browser são um bom lugar para experimentar isso, porque é exatamente o tipo de carga em que as ferramentas atuais gastam um turno de um modelo de fronteira a cada clique. Ferramentas de QA baseadas em agentes (Expect, browser-use e similares) entregam um browser a um agente de código e deixam ele planejar, clicar, digitar e verificar. Funciona, é lento, e é caro do jeito que vai somando: um flow de 20 passos são 20 ou mais turnos do agente.

A divisão a que cheguei é simples, e eu defenderia cada linha dela:

A digitação de texto nunca passa perto do modelo. O código tira um snapshot da página (URL, título, texto visível deduplicado, a árvore aria e cada controle clicável visível marcado com um índice), e o Jev só escolhe entre coisas que o código já encontrou. Ele nunca inventa um seletor. É o mesmo formato do bridge jev-browser-use que alguém publicou para o Codex esta semana, adaptado para Playwright puro para rodar em qualquer lugar.

Em cima das três primitivas construí o que um time realmente precisa:

• Uma CLI para agentes. Um flow é um array JSON de passos. A CLI roda tudo headless, grava em vídeo e imprime um único resultado JSON com pass ou fail por passo, a probabilidade por trás de cada julgamento, o caminho do vídeo e o caminho de um screenshot final. Exit code 0 ou 1. As credenciais são referenciadas como placeholders ${QA_EMAIL} e substituídas a partir do ambiente da própria CLI, então um agente que escreve um flow nunca as vê.
• Um dashboard. Um único arquivo HTML servido localmente, em inglês, espanhol ou português. Cada run, cada teste, cada decisão do Jev com sua probabilidade, latência e contagem de tokens, com o vídeo embutido.
• Uma skill. Um SKILL.md que ensina Claude Code, Codex, Cursor ou Grok Build a escrever um flow e a ler o resultado. "Teste este branch no browser" vira algo que um agente consegue fazer sem um humano olhando.

Aqui está um run real contra o nosso produto. O flow faz login de forma determinística, depois passa um objetivo ao Jev e depois pede que ele verifique:

{ "goal": "Open the account or workspace settings screen. Do not change any setting.",
  "maxSteps": 8,
  "denyNames": ["cerrar sesi", "logout", "eliminar", "delete", "guardar", "save"] },
{ "expect": "A settings or configuration screen is displayed." }

[8/9] goal: Open the account or workspace settings screen. Do not change any setting.
    step 1: Click button "Menú de usuario: Olivia Owner" p=0.76
    step 2: Click link "Mi cuenta" (href=/settings) p=0.99
    step 3: WAIT p=0.38
    step 4: DONE p=1.00
    passed (3245 ms)
[9/9] expect: A settings or configuration screen is displayed.
    passed p=0.99 (443 ms)

Quatro decisões, 3.2 segundos incluindo o carregamento das páginas, e a terceira é a minha favorita: a página estava no meio de uma transição depois do clique, e em vez de clicar em outra coisa o Jev escolheu WAIT com uma probabilidade baixa, que é exatamente o que um modelo deveria dizer quando o estado é ambíguo. No flow de login, quando pedi "the button that submits the login form", ele escolheu "Iniciar sesión" com 0.97 em uma página em espanhol que nunca tinha visto. A intenção estava em inglês. Não fez diferença.

Os números

O Jev eu medi pessoalmente. Vinte chamadas sequenciais pelo AI Gateway a partir de Buenos Aires, cada uma com uma pergunta boolean e uma choice sobre um estado de página realista de uns 400 tokens:

A comparação abaixo é a parte para ler com atenção. Eu não rodei os outros modelos: peguei os preços de tabela na página de pricing de cada provedor e as latências do Artificial Analysis, e calculei quanto custaria o mesmo julgamento se você pedisse a um modelo de linguagem como um pequeno objeto JSON: 750 tokens de input (o estado mais a pergunta) e 25 de output. O time to first token é o número publicado para a configuração sem reasoning, quando ela existe; o tempo total soma esses 25 tokens na velocidade de output publicada. Trate a coluna de latência como estimativa e a de custo como aritmética.

Três coisas chamam a atenção. Primeiro, os LLMs mais baratos ficam a um múltiplo pequeno do Jev em preço, então no tier nano o custo sozinho não é o argumento; latência e calibração são. Segundo, os modelos que as pessoas realmente usam quando querem um julgamento confiável (Haiku, Flash, Sonnet) custam de 30 a 60 vezes mais e têm de duas a cinco vezes a latência, e ainda assim não te dão uma probabilidade. Terceiro, o número de manchete da própria TypeSafe, "194x faster and 445x cheaper", é contra workflows do tipo reasoning, e quando você olha as latências com reasoning naquela tabela (76 segundos para o nano em high) ele deixa de soar como marketing. Para o loop de QA, a comparação que importa é por flow: o run de settings acima tomou cinco decisões por USD 0.0003. Rode isso a cada commit em cada branch e a conta continua zerada.

O que aprendi em uma semana

• Escreva as afirmações do jeito que um QA engineer escreve resultados esperados. "Uma lista de vagas é exibida, ou um estado vazio convidando a criar a primeira" funciona. "A página está correta" não. Quando uma afirmação é sutil, dê critérios explícitos de verdadeiro e falso; o modelo usa.
• Uma probabilidade perto do seu threshold é feedback sobre a afirmação, não sobre o threshold. Refine a pergunta. Não abaixe a régua.
• Deny lists não são opcionais em um loop de ações. O Jev vai escolher "Cerrar sesión" numa boa se esse for o único controle que parece progresso. O loop só oferece controles únicos e permitidos, e nomes destrutivos nunca são oferecidos.
• Texto, não pixels. O Jev nunca vê o screenshot. Regressões visuais continuam precisando de um modelo de visão ou de um diff de pixels. O screenshot no relatório é para o humano.
• Calibração é por população, não por resposta. A documentação diz isso e dá para ver: um 0.76 em "clicar no menu do usuário" foi o clique certo, e um 0.38 em WAIT foi a hesitação certa. Leia a distribuição, não só o argmax.
• Combina com as ferramentas de agentes que você já usa. O lugar natural disso não é substituir o Expect ou um agente de código, e sim ser a camada mecânica que eles chamam para parar de gastar um turno por clique. É exatamente o que o bridge do Codex faz, e o que a CLI mais a skill daqui fazem para todo o resto.

Experimente

O projeto é open source em github.com/jonymusky/jev-browser-qa. Ele é pequeno de propósito: três primitivas, uma CLI, um dashboard, uma skill e um README que diz o que o Jev não vai fazer.

git clone https://github.com/jonymusky/jev-browser-qa && cd jev-browser-qa
pnpm install && pnpm exec playwright install chromium
cp .env.example .env          # AI_GATEWAY_API_KEY, BASE_URL, QA_EMAIL, QA_PASSWORD
pnpm jev:smoke                # one call, no browser
pnpm -s qa run flows/login.json
pnpm dashboard                # http://localhost:4310

E para o seu agente: npx skills add https://github.com/jonymusky/jev-browser-qa --skill jev-qa. Tenho rodado a partir do Claude Code e do Grok Build, o agente de terminal da xAI, que lê Agent Skills e AGENTS.md sem nenhuma configuração: o mesmo prompt, "test this branch with jev-qa and report the verdict with the video path", funciona nos dois, e nenhum dos agentes vê uma credencial, porque os flows levam placeholders ${QA_EMAIL} que a CLI resolve. Tem um walkthrough curto do Grok Build no repo, incluindo a forma headless grok -p para CI. Se quiser testar sem instalar nada, publiquei um bot do Grok com a skill pré-carregada: QA Engineer. Passe a URL do seu app e o flow que você quer verificar, e ele volta com o veredito, o vídeo e o screenshot.

Tomei cuidado neste post para separar o que medi do que inferi, porque as afirmações em torno do Jev são grandes e o modelo tem quatro dias de vida. Mas o design não é um truque. Um modelo que devolve uma decisão calibrada em vez de um parágrafo, em 400 milissegundos, por uma fração de centavo, muda em quais partes do seu sistema faz sentido colocar um modelo. Até agora a resposta era "nas partes que podem pagar por isso". A partir desta semana, a resposta está mais perto de "em qualquer lugar onde, de outro jeito, você escreveria um if e se sentiria mal com isso".

Contexto, para que os números signifiquem algo: rodamos cinco apps Next.js. Três ficam em um monorepo pnpm: um produto administrativo de 56 rotas atrás de auth, um site público para candidatos com formulários e entrevistas com IA, e um pequeno portal para funcionários. Os outros dois são repos separados: um dashboard interno de analytics e um site de marketing em três idiomas com um blog em MDX. Os cinco fazem deploy na Vercel. Os cinco agora rodam com React Compiler e Cache Components.

O que valeu a pena desde o primeiro dia

O cache de build é real. O cache em filesystem do Turbopack para next build vem ativado por padrão no 16.3. Medido nesta semana no último patch, em um laptop: o app de 56 rotas compila em 30 segundos a frio e em 0,8 segundo quando nada mudou. No 16.3.0 o mesmo rebuild com cache levava 6,6 segundos, então a linha de patches melhorou isso oito vezes sem a gente mexer em nada. Os apps menores ficam entre 4 e 7 segundos a frio e meio segundo com cache. O tempo total é maior (a coleta de page data e a geração estática não são cacheadas), mas a etapa de compilação era a parte que nos deixava esperando.

A evicção de memória mudou uma decisão, não um número. Nunca medimos a memória em dev, mas foi por isso que nosso site de marketing finalmente abandonou next dev --webpack como padrão. Sessões longas do Turbopack cresciam até o laptop reclamar; com a evicção ativada por padrão, isso deixou de ser motivo para manter o webpack. O webpack fica como script de fallback, o que traz sua própria lição mais abaixo.

catchError é o error boundary que a gente realmente queria. Um error.tsx clássico engole notFound() e redirect(), e o reset dele só limpa o estado do cliente. O novo boundary de next/error não faz nenhuma das duas coisas: deixa essas duas passarem, e o retry() dele refaz o fetch dos Server Components abaixo dele. Usamos em volta de páginas que fazem fetch no servidor (com o fallback reportando para o Sentry) e, no blog, em volta do corpo MDX, para que um post quebrado vire um bloco de "tente novamente" em vez de uma página em branco.

TypeScript 7 no next build, com uma pegadinha do pnpm. Quatro dos cinco apps fazem type-check com o tsc nativo. O que não faz é o site de marketing, porque ele usa lint com typescript-eslint, cujo parser quebrava com a API do TypeScript 7 quando testamos. Os apps que usam Biome para lint nunca tiveram esse problema. E com o linker isolado do pnpm, o compilador nativo não inclui automaticamente node_modules/@types, então cada app precisou de um array "types" explícito no tsconfig. Dez minutos, mas dez minutos confusos.

Cache Components muda a semântica HTTP, não só a velocidade

Esta é a parte que eu colocaria em negrito em todo guia de migração. Com Cache Components, uma página faz streaming sobre um shell pré-renderizado, e o shell sai com um 200. Se depois sua página chama notFound() enquanto renderiza a parte dinâmica, o status já foi enviado. O usuário vê sua UI de not-found. O Google vê um 200.

Medimos isso no site de marketing antes de corrigir: um slug de blog inexistente, um slug de landing de anúncio inexistente e um slug de página de comparação inexistente respondiam todos 200. Três famílias de rotas inteiras retornando "encontrado" para lixo, justamente na propriedade em que os crawlers são o cliente. A correção segue a orientação do próprio framework: estabelecer a existência antes do primeiro byte. Nosso proxy agora valida os slugs do blog contra um manifest gerado no build (assim ele não fica desatualizado em produção, e carrega as datas de publicação para que posts agendados continuem funcionando), valida os outros dois contra suas tabelas estáticas e reescreve o que não bate para um path que nenhuma rota atende. O router então serve a página de not-found com a nossa marca e um 404 de verdade.

A segunda mudança semântica é que os segment configs acabaram. export const revalidate = 3600, dynamic = "force-static", dynamic = "force-dynamic": nenhum é permitido depois que a flag está ativada. Não é uma renomeação. revalidate vira um escopo 'use cache' com cacheLife('hours'), e tudo que lê o relógio precisa ir para dentro desse escopo. Nosso blog filtra posts pela data de publicação com new Date(); fora de um escopo de cache isso é dado de request e um erro de prerender na hora, dentro dele o relógio é lido uma vez por entrada de cache e os posts agendados ainda aparecem dentro de uma hora. Feito isso, 204 páginas foram pré-renderizadas no build e um segundo acesso a um post caiu de 129 ms para 29 ms.

Root params é o que destrava o i18n, e ainda não fizemos isso

O exemplo de import.meta.glob do release post é um blog lendo arquivos MDX com gray-matter. É literalmente o nosso, então testamos em agosto. Compilou, e transformou as rotas do blog de dinâmicas em totalmente estáticas, o que quebrou o locale em tempo de request do next-intl com 500s em runtime. As leituras síncronas de fs são estruturais até o layout parar de derivar o locale de params.

Esse mesmo layout é o motivo de o site de marketing carregar export const instant = false em toda a árvore de locale: um layout que escolhe <html lang> e as mensagens a partir de params não consegue produzir um shell estático instantâneo. Root params (lang() de next/root-params) mais setRequestLocale é a solução, e é o próximo passo para esse app. Se o seu app é internacionalizado com um segmento [locale], essa migração é o preço das Instant Navigations, e vale a pena colocá-la no orçamento desde o início em vez de descobri-la por meio de instant = false.

Experimental significa experimental

O React Compiler baseado em Rust é a feature que mais me empolgava e a que mais nos custou. Aconteceram duas coisas.

Primeiro, no nosso maior app ele derruba o build por OOM no container padrão da Vercel, uns 25 segundos depois do início de uma compilação a frio. O mesmo app builda bem pelo caminho do Babel (duas vezes mais lento, mas cabe), e os apps menores buildam bem com o port em Rust. Reportamos, um maintainer se envolveu no mesmo dia, e no fim de agosto eles tinham cortado pela metade o pico de alocação do compilador, com um caminho de crescimento quadrático como provável gatilho no nosso código. Esse trabalho está no canary. Rodamos o experimento de novo nesta semana no último patch do 16.3, em um preview deployment, e tivemos o mesmo SIGKILL. Então nossa config mantém um guard por target: port em Rust em todo lugar, exceto nos builds na Vercel daquele app, onde o compilador roda via Babel.

Segundo, o port em Rust perde a classe de escopo jsx-<hash> em elementos renderizados condicionalmente dentro de componentes com estado, então as regras com escopo de <style jsx> param de casar sem aviso. Isso foi para produção com os labels da sidebar invisíveis. Mantivemos um repositório com um repro mínimo (vercel/next.js#96694) e nesta semana rodamos de novo contra três versões: ainda quebrado no último patch do 16.3, corrigido no canary do 16.4. Isso transformou um "talvez já esteja corrigido" em um número de versão, e significa que nossa regra de "nada de styled-jsx com escopo" fica exatamente até o 16.4.

Duas coisas menores da mesma categoria. output: 'standalone' combinado com um adapter quebrava os deploys na Vercel no 16.3.0 (faltava um arquivo de trace); o fix foi mergeado no canary dois dias depois e, até esta semana, ainda não saiu em nenhum patch estável do 16.3. Confira a tag, não o PR. E o guard de config do nosso fallback para webpack originalmente verificava process.argv procurando --webpack, o que nunca bate porque o next.config é avaliado no processo interno de servidor do Next. Um reviewer pegou isso rodando o fallback de verdade. Guard que você nunca exercita é guard que você não tem.

O bug que não tinha nada a ver com o Next.js

Toda a adoção do 16.3 no site de marketing foi revisada, aprovada e mergeada em 4 de agosto. Ela foi mergeada na feature branch sobre a qual estava empilhada, e essa branch nunca mais foi mergeada. Durante um mês o site rodou um binário do 16.3 com webpack em dev, sem compilador e com os segment configs antigos. Nada quebrou, e é exatamente por isso que ninguém percebeu; só descobri nesta semana fazendo grep em main atrás de uma flag que deveria estar lá. Reaplicamos a intenção na mão; um cherry-pick tinha dez arquivos em conflito contra um mês de trabalho de design. PRs empilhados são ok. PRs empilhados cuja base não é main precisam de um lembrete na base.

O que eu diria a outro CTO

• Aplique os patches. O 16.3.3 corrigiu dois advisories críticos de execução remota de código, um deles na otimização de imagens com AVIF, que é o primeiro formato que nosso site de marketing serve. Nada na linha 16.3.x exigiu mudanças de código da nossa parte. Não há motivo para ficar no 16.3.0.
• Meça seus 404 depois de ativar Cache Components. Um curl por família de rotas. Se você vir 200 onde espera 404, mova as verificações de existência para o proxy.
• Trate revalidate como uma migração. Encontre cada segment config, encontre o que lê o relógio, mova para dentro de um escopo de cache.
• Dê a cada flag experimental uma saída de emergência por target e um jeito de testá-la de novo. A nossa é um commit no preview de um pull request e um revert. Seis minutos, e agora sabemos a resposta para este patch.
• Mantenha um repo de repro para cada bug que você reportar. Rodá-lo de novo contra uma versão nova custa dois minutos e responde a pergunta que comentários upstream não conseguem responder.
• Um fix no canary não é um fix no seu build. Confira a release tag.
• Se você é internacionalizado, planeje a migração para root params antes de planejar Instant Navigations. É o mesmo projeto.

O 16.3 é um bom release. Só o cache de build e o error boundary já valeram o upgrade, e Cache Components é o modelo certo para os apps que construímos. Mas o release post descreve um destino, e o caminho até lá passa pelo seu proxy, pelo seu layout de i18n e pelo limite de memória do seu container de build. Saber disso antes de começar é a maior parte do trabalho.