Cada búsqueda debería hacer más fácil la siguiente.

• Cada candidato que entrevistaste.
• Cada screening.
• Cada evaluación.
• Cada conversación.
• Cada motivo por el que alguien avanzó, o no.
• Cada persona que era excelente, solo que no para ese rol.
• Cada candidato que no estaba disponible hace ocho meses y hoy quizás sí.

Todo eso debería convertirse en un activo de la empresa. Si hace cinco años que contratás, deberías tener cinco años de ventaja acumulada.

Cinco años contratando, cinco años de ventaja

El recruiting tiene la misma forma que el interés compuesto. Una sola búsqueda produce un poco de conocimiento reutilizable: una docena de personas a las que volverías a llamar sin dudarlo, algunas notas sobre por qué el mercado rechazó tu banda salarial, una evaluación que te dice qué significaba realmente "senior" para ese equipo. Por sí sola, parece nada. Si la guardás y la sumás a la siguiente búsqueda, y a la que viene después, deja de parecer nada.

Hay dos cosas para notar en ese gráfico. La primera es la brecha: para la búsqueda diez, un equipo abre un rol con sesenta y pico de personas calificadas que ya conoce, que ya evaluó, con notas sobre cada una. El otro lo abre con tres nombres y un aviso. La segunda es la forma de la línea gris. Nunca sube. Diez búsquedas de trabajo y el punto de partida es el mismo que el primer día.

Eso es lo que pasa cuando cada posición nueva arranca publicando de nuevo, esperando postulantes y leyendo CVs desde cero. La ventaja que deberías haber construido simplemente desaparece.

El problema del Excel no es el Excel

Es fácil echarle la culpa a la planilla, y algo de culpa tiene. No hay un buscador digno de ese nombre, no hay historial por persona, no hay vínculo entre el CV, la entrevista y la decisión. Pero los equipos que se pasaron a un ATS de verdad y mantuvieron los mismos hábitos tienen el mismo problema con una interfaz más linda.

El problema de fondo es que tu proceso de contratación genera información todos los días, y estás dejando que la mayor parte de ese conocimiento se pierda. Se pierde en lugares concretos:

1. El rechazo sin motivo. "Archivado" no le dice nada al próximo recruiter. "Backend fuerte, quería 100% remoto, volver a ver si abrimos roles remotos" le dice todo.
2. La entrevista que vive en la cabeza de alguien. La mejor señal de todo el proceso es la conversación, y suele ser la parte que nunca se escribe.
3. El medalla de plata. La persona que quedó segunda para un rol es, por definición, un candidato precalificado para el próximo rol parecido. La mayoría de los sistemas la archivan al lado de gente que no pasó el primer filtro.
4. El "ahora no". Alguien que recién había empezado en un trabajo, se estaba mudando o tenía otra oferta. El timing era el único problema, y nadie anotó cuándo volver a intentar.
5. La búsqueda que arranca con un aviso. Si el primer paso de una posición nueva es publicarla en lugar de buscar en lo que ya tenés, la base no se está usando aunque exista.

Ninguna de estas es una falla del software. Son momentos en los que el proceso produjo algo valioso y nada lo capturó.

El loop

Un buen ATS no debería ser solo el lugar donde gestionás candidatos. Debería ser una base de talento que vale más con cada búsqueda. Eso solo pasa si el proceso es un loop, no una línea:

Qué están haciendo las herramientas al respecto

La industria se dio cuenta. Redescubrir el talento que ya tenés es hoy una feature estrella en todo el mercado, y vale la pena ver cómo lo encara cada producto:

• Ashby lanzó AI Talent Rediscovery, que evalúa a las personas que ya están en tu base contra los criterios de un rol nuevo, actualiza perfiles desactualizados y usa señales como el avance por etapas y los puntajes de los scorecards para rankearlas. Su CRM agrupa contactos en talent pools que pueden pasar directo a un pipeline activo.
• Greenhouse tiene Talent Rediscovery y filtrado de talento sobre candidatos y prospects anteriores, filtrable por scorecard, hito alcanzado y motivo de rechazo, junto con un CRM para prospects de sourcing.
• Manatal lee la descripción del puesto y puntúa a los candidatos que ya están en tu pool contra ella con matching semántico, así los postulantes anteriores aparecen para roles nuevos sin una búsqueda manual.
• Spott es un ATS y CRM AI-native para agencias de recruiting, construido alrededor de una base de recruiting pensada para seguir siendo útil con el tiempo, alimentada por memoria de conversaciones y procesamiento de transcripciones de entrevistas.
• Selenios, donde soy CTO, así que leé esta con eso en mente. Nuestra apuesta está en el lado de entrada del loop: screenings, entrevistas y evaluaciones se convierten en notas estructuradas asociadas al candidato, así la base se vuelve más densa con cada conversación y no solo con cada CV.

Fijate de qué depende cada una de estas features. El rediscovery rankea personas usando los scorecards, los motivos de rechazo, las notas y el historial de etapas que tu equipo registró. Un modelo de matching es tan bueno como lo que puede leer. Apuntá el mejor motor de rediscovery del mercado a una base llena de tarjetas archivadas sin motivos y sin notas, y va a redescubrir CVs. Es lo único que tiene.

Hábitos que hacen que la base rinda interés compuesto

La herramienta es necesaria, pero no alcanza. Estos son los hábitos que definen si tu ATS se convierte en una base de talento o en un archivero:

1. Buscá antes de publicar. El primer paso de cada rol nuevo es una consulta sobre la gente que ya conocés. Publicar viene después.
2. Cada rechazo lleva un motivo. Uno corto y estructurado. "Skills", "seniority", "salario", "ubicación", "timing", más una oración. Lleva diez segundos y es el dato más reutilizable que vas a producir.
3. Etiquetá a los medalla de plata. Cualquiera que llegó a las etapas finales es un lead para el próximo rol parecido. Hacé que se los pueda encontrar como tales.
4. Ponele fecha al "ahora no". Si el problema fue el timing, anotá cuándo podría cambiar y dejá que el sistema te lo recuerde.
5. Capturá la conversación. Las notas de entrevista y las evaluaciones van en el perfil del candidato, no en un doc, un hilo de chat o la memoria de alguien. Si valió una hora del tiempo de un entrevistador, vale la pena guardarlo.
6. Medilo. Seguí cuántas contrataciones y finalistas salen de gente que ya estaba en tu base. Si ese número no crece año a año, la base no está rindiendo interés compuesto.

Una base, o un historial

Un ATS usado como tablero te da un registro prolijo de lo que pasó. Un ATS usado como base de talento te da ventaja sobre lo que viene. La diferencia no es el software que compraste. Es si cada búsqueda deja algo que la siguiente pueda usar.

Si después de años contratando tu próxima búsqueda sigue arrancando de cero, no construiste una base de talento. Construiste un historial.

Qué es batch inference

En tiempo real, cada request espera su respuesta. En batch no hay conversación. Escribís un archivo con un objeto JSON por línea, miles de prompts, y lo subís a un bucket. Le decís al proveedor "procesá esto cuando puedas". Un rato después aparece otro archivo con todas las respuestas. Sin servidores tuyos esperando en sockets, sin lógica de reintentos, sin una cola que tengas que operar.

En Amazon Bedrock, que es donde lo corremos, el input es un archivo JSONL en S3 donde cada línea lleva un identificador y el mismo body que le mandarías a 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… }}

Después, una sola llamada a la API crea el 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 de ahí hacés polling del estado del job, y cuando termina leés los archivos de output, matcheás cada línea con su recordId, y seguís con tu pipeline como si las llamadas se hubieran hecho una por una.

Por qué cuesta la mitad

Porque le estás vendiendo al proveedor lo único que le sobra: capacidad ociosa. Las flotas de inferencia están dimensionadas para el pico de tráfico interactivo, y fuera del pico las GPUs quedan medio vacías. Cuando resignás latencia, ellos reciben trabajo que pueden meter en esos huecos, y el precio del token baja un 50%.

No es una promoción ni un descuento negociado. Es el precio de lista del modo batch en Amazon Bedrock, Anthropic, OpenAI y Gemini, los cuatro a la mitad de su tarifa on-demand. Mismo modelo, mismos pesos, mismo output. Lo único por lo que pagás menos es la promesa de una respuesta inmediata.

Un caso real: una migración con años de historia

Hace poco migramos a un cliente que venía de otro sistema de recruiting. Eso significa decenas de miles de CVs distintos, y con ellos las búsquedas, las notas de los recruiters, los movimientos entre etapas del pipeline y las evaluaciones de años de historia. Cada CV pasó por un modelo de lenguaje en Bedrock para extraer su estructura en el formato que espera nuestro producto.

La factura on-demand habría sido un número. La factura en batch fue exactamente la mitad, con el mismo modelo y los mismos resultados. No voy a poner cifras absolutas acá, y no importa: lo que importa es la proporción, y se mantiene a cualquier escala. Llevalo a miles de candidatos con toda su historia y la cuenta da igual. La mitad.

Hay un segundo ahorro que no tiene nada que ver con batch y que deberías hacer igual: antes de mandar nada, hasheamos cada archivo. En un sistema de recruiting el mismo CV aparece adjunto a muchas postulaciones. Un candidato que se postuló a cinco búsquedas tiene cinco copias del mismo PDF. Con un MD5 del archivo como clave, el mismo CV se parsea una sola vez y el resultado se replica a cada postulación que lo referencia. El token más barato es el que nunca mandás.

La ventaja de la que nadie habla: batch no compite con producción

El precio es el titular, pero no es la mejor razón. El tráfico on-demand sale de un pool compartido, y cuando ese pool se llena el proveedor te responde con un 503 y un mensaje de "insufficient capacity". Lo vivimos. Ahora imaginate que, encima de tu tráfico normal, disparás miles de llamadas desde un script de migración por el mismo canal, con el mismo modelo y la misma cuenta. Lo pagan tus usuarios, en latencia y en errores, en las pantallas que realmente usan.

Batch es otra cola con otra cuota. La migración corre de noche y la plataforma ni se entera. La propia guía de Bedrock para errores de capacidad en on-demand dice lo mismo: mové las cargas offline a batch. Este es el argumento que me convenció más que el descuento. Pagar la mitad está bueno. Que el trabajo masivo nunca toque la experiencia de la gente que usa tu producto es lo que realmente gana.

Qué te cobra a cambio

Nada es gratis, así que acá va la cuenta, con los detalles de Bedrock porque es donde lo corremos:

1. Latencia. Minutos u horas, con el compromiso de terminar dentro de las 24 horas. No elegís cuándo.
2. Menos features. En Bedrock batch no hay tool calling ni structured output. Pedís JSON en el prompt y lo parseás vos, con la misma validación que usarías para cualquier output de un modelo en el que no confiás.
3. Sin camino de OCR en varios modelos. Si parte de tu input son imágenes escaneadas, esas necesitan su propia ruta on-demand.
4. El orden del output no está garantizado. La línea 1 del input no es la línea 1 del output. El recordId es lo único que las une.
5. Un mínimo por job. Por defecto, 100 registros. Con menos, el job se rechaza.

Si tu caso de uso es interactivo, nada de esto sirve. Si nadie está esperando la respuesta, todo es aceptable.

El checklist que aprendimos a los golpes

Nada de esto está en la guía de getting started. Todo nos costó algo la primera vez.

• Deduplicá antes de mandar. Hasheá el archivo, no la postulación. Un parseo por CV, no uno por postulación.
• Respetá las cuotas. Al menos 100 registros por job, 1 GB por archivo de input, 5 GB por job. Nosotros shardeamos en 50.000 registros.
• Uní el último shard si queda corto. 50.050 registros partidos ingenuamente en shards de 50.000 te dejan un shard final de 50, y ese job se rechaza. El fix son tres líneas, y es el tipo de bug que solo encontrás con datos reales:

  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;
  }

  El shard combinado termina un poco por encima del tamaño objetivo, así que dejá el objetivo bien por debajo de los límites reales.
• Persistí el estado de cada job apenas lo aceptan. Un job se factura desde el segundo en que el proveedor lo acepta. Si tu script se cae después de crear el job pero antes de guardar su ARN, y lo relanzás, pagás dos veces el mismo trabajo. Escribí el ARN del job y el shard que cubre en almacenamiento durable antes de hacer cualquier otra cosa, y hacé que el launcher saltee los shards que ya tienen un job.
• Usá identificadores cortos y únicos. El output vuelve desordenado, así que cada línea necesita un recordId que mapee a tus propios datos sin ambigüedad. Un hash corto funciona mejor que una clave compuesta larga que después vas a tener que parsear.
• Validá con el mismo parser que usás on-demand. El import no debería poder distinguir por qué camino llegó un resultado. Si el output de batch necesita su propio parser, ahora tenés dos fuentes de verdad y una de las dos se va a desalinear.
• Borrá todos los archivos del bucket cuando termines. Inputs y outputs. Son CVs, o sea datos personales, y nada debería quedar en S3 después de verificar el import. Hacé que la limpieza sea parte del job, no una nota en un runbook.

Quién lo soporta

Los cuatro grandes proveedores lo ofrecen con 50% de descuento, con límites distintos. A esta semana:

Si ya usás el AI SDK, hay un camino más simple para batches chicos. El AI Gateway de Vercel soporta batch con experimental_startBatch, experimental_getBatchStatus y experimental_getBatchResults, sin S3 de por medio: los requests van inline, hasta 1.000 por batch y 4,5 MB, y el mismo código funciona contra modelos de OpenAI y 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));
  }
}

La misma forma que la versión de Bedrock, sin tener que hacerte cargo de un bucket, un rol y la limpieza. Es ideal para batches chicos y medianos. Para decenas de miles de CVs, el archivo en S3 sigue siendo la herramienta correcta.

La regla

Toda la decisión entra en una pregunta: ¿alguien está esperando esta respuesta? Si sí, on-demand. Si no, batch. Migraciones, re-scoring masivo, enriquecimiento de datos, evals, clasificar registros históricos: ninguno tiene a un humano del otro lado mirando un spinner, y todos están pagando el doble si corren on-demand.

Mismo modelo, mitad de precio, y tus usuarios ni se enteran. Y la verdad, la mitad de precio es lo de menos. Lo que importa es que el trabajo masivo nunca toque la experiencia de la gente que usa tu producto.

Una nota práctica antes del argumento: al momento de escribir esto, Vercel tiene una promoción de lanzamiento y Jev es gratis en AI Gateway hasta el 25 de septiembre. Después cuesta USD 0.042 por millón de tokens de input, y el output es gratis porque no hay output. De cualquier manera cuesta casi nada, y eso es parte de la historia.

Qué es Jev, en un párrafo

Le pasás a Jev un estado (un string, un objeto JSON, hasta 32k tokens) y un conjunto de preguntas. Cada pregunta es una de tres primitivas: un boolean ("¿se cumple esta afirmación?"), un choice ("¿cuál de estas opciones?") o un score ("¿dónde cae en esta escala ordenada?"). Responde cada pregunta con un valor tipado y una distribución de probabilidad, y nada más. Sin prosa, sin traza de razonamiento, sin JSON para parsear. TypeSafe lo entrena con un método que llaman Reinforcement Learning for Calibrated Decisions, así que las probabilidades se optimizan contra resultados y no contra la preferencia de un humano por una respuesta linda. Un 0.97 debería acertar más o menos el 97% de las veces.

Con el AI SDK se ve así:

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 }

Esa es toda la API. El paquete ai sumó experimental_evaluate en la 7.0.105 exactamente para esta clase de modelo, y el gateway lo expone como un "evaluation model" al lado de los modelos de lenguaje, de embeddings y de imágenes. Es una columna nueva en el catálogo, no una fila nueva.

Por qué esto es más importante que un clasificador barato

Fijate dónde están realmente las llamadas a LLMs en un codebase en producción. Una minoría genera texto que va a leer un humano. La mayoría toma una decisión sobre la que va a actuar el código: rutear este ticket, ¿este CV cumple la pregunta excluyente?, ¿este mensaje es urgente?, ¿cuál de estos cinco candidatos es el que el usuario quiso decir?, ¿este paso salió bien? Durante tres años la forma de obtener esa decisión fue pedirle a un modelo de chat que por favor responda en JSON, parsear el JSON, reintentar cuando no parsea, y tratar la respuesta como binaria porque el modelo no te da un número honesto de qué tan seguro está.

Cada una de esas llamadas paga por generación. Pagás los tokens de output, esperás a que se hagan stream, y heredás un modo de falla (output mal formado) que no tiene nada que ver con la decisión. Los modos de structured output hicieron el parseo más confiable pero no lo hicieron más rápido ni más barato, y los logprobs, donde existen, no están calibrados. Jev elimina el paso de generación por completo. La decisión es el output. No hay nada que parsear, nada que reintentar por problemas de formato, y el número que vuelve significa lo que dice.

La consecuencia es que las decisiones se vuelven lo suficientemente baratas como para tomar muchas. Hacé cinco preguntas sobre el mismo estado y corren en paralelo en un solo request. Hacé una pregunta especulativa que capaz no necesitás. Puntuá a cada candidato en cuatro dimensiones y dejá que el ranking sea una suma ponderada que podés cambiar sin otra inferencia. Es una forma distinta de escribir software alrededor de un modelo, y es por eso que la documentación de TypeSafe se lee más como una guía de programación que como una guía de prompting. El modelo es una primitiva. El código es dueño del workflow.

Lo que Jev no puede hacer es igual de importante, porque los límites son el diseño. No genera, así que no puede escribir un selector, un resumen, un mail ni una línea de código. No puede planificar. Lee texto, no imágenes. Si tu tarea necesita algo de eso, seguís necesitando un modelo de lenguaje. El modelo mental correcto no es "un LLM más chico" sino "el juicio rápido y calibrado que ponés antes, al lado o después del LLM".

Qué construí: un loop de QA donde Playwright maneja y Jev juzga

El testing end-to-end en el browser es un buen lugar para probar esto, porque es exactamente el tipo de carga donde las herramientas actuales gastan un turno de un modelo frontier en cada click. Las herramientas de QA basadas en agentes (Expect, browser-use y compañía) le dan un browser a un agente de código y lo dejan planificar, clickear, tipear y verificar. Funciona, es lento, y es caro de la forma que se acumula: un flow de 20 pasos son 20 o más turnos del agente.

La división con la que terminé es simple y defendería cada línea:

El ingreso de texto nunca pasa cerca del modelo. El código saca un snapshot de la página (URL, título, texto visible deduplicado, el árbol aria, y cada control clickeable visible etiquetado con un índice), y Jev solo elige entre cosas que el código ya encontró. Nunca inventa un selector. Es la misma forma que el bridge jev-browser-use que alguien publicó para Codex esta semana, adaptado a Playwright pelado para que corra en cualquier lado.

Encima de las tres primitivas armé lo que un equipo realmente necesita:

• Una CLI para agentes. Un flow es un array JSON de pasos. La CLI lo corre headless, lo filma e imprime un único resultado JSON con pass o fail por paso, la probabilidad detrás de cada juicio, el path al video y el path a un screenshot final. Exit code 0 o 1. Las credenciales se referencian como placeholders ${QA_EMAIL} y se sustituyen desde el entorno de la propia CLI, así que un agente que escribe un flow nunca las ve.
• Un dashboard. Un único archivo HTML servido localmente, en inglés, español o portugués. Cada run, cada test, cada decisión de Jev con su probabilidad, latencia y cantidad de tokens, con el video embebido.
• Un skill. Un SKILL.md que le enseña a Claude Code, Codex, Cursor o Grok Build cómo escribir un flow y cómo leer el resultado. "Testeá este branch en el browser" pasa a ser algo que un agente puede hacer sin un humano mirando.

Acá va un run real contra nuestro producto. El flow hace login de forma determinística, después le pasa un objetivo a Jev y después le pide que 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)

Cuatro decisiones, 3.2 segundos incluyendo la carga de las páginas, y la tercera es mi favorita: la página estaba en plena transición después del click, y en lugar de clickear otra cosa Jev eligió WAIT con una probabilidad baja, que es exactamente lo que tiene que decir un modelo cuando el estado es ambiguo. En el flow de login, cuando le pedí "the button that submits the login form", eligió "Iniciar sesión" con 0.97 en una página en español que nunca había visto. La intención estaba en inglés. No importó.

Los números

A Jev lo medí yo. Veinte llamadas secuenciales a través de AI Gateway desde Buenos Aires, cada una con una pregunta boolean y una choice sobre un estado de página realista de unos 400 tokens:

La comparación de abajo es la parte para leer con cuidado. Los otros modelos no los corrí: tomé los precios de lista de la página de pricing de cada proveedor y las latencias de Artificial Analysis, y calculé cuánto costaría el mismo juicio si se lo pidieras a un modelo de lenguaje como un objeto JSON chico: 750 tokens de input (el estado más la pregunta) y 25 de output. El time to first token es la cifra publicada para la configuración sin reasoning cuando existe; el tiempo total suma esos 25 tokens a la velocidad de output publicada. Tomá la columna de latencia como una estimación y la de costo como aritmética.

Se destacan tres cosas. Primero, los LLMs más baratos están a un múltiplo chico de Jev en precio, así que en el tier nano el costo solo no es el argumento; la latencia y la calibración sí. Segundo, los modelos que la gente realmente usa cuando quiere un juicio en el que pueda confiar (Haiku, Flash, Sonnet) cuestan entre 30 y 60 veces más y tienen entre dos y cinco veces la latencia, y aun así no te dan una probabilidad. Tercero, la cifra de titular de TypeSafe, "194x faster and 445x cheaper", es contra workflows de tipo reasoning, y una vez que mirás las latencias con reasoning en esa tabla (76 segundos para nano en high) deja de sonar a marketing. Para el loop de QA la comparación que importa es por flow: el run de settings de arriba tomó cinco decisiones por USD 0.0003. Corrélo después de cada commit en cada branch y la factura sigue siendo cero.

Lo que aprendí en una semana

• Escribí las afirmaciones como un QA engineer escribe resultados esperados. "Se muestra una lista de posiciones abiertas, o un estado vacío que invita a crear la primera" funciona. "La página está bien" no. Cuando una afirmación es sutil, dale criterios explícitos de verdadero y falso; el modelo los usa.
• Una probabilidad cerca de tu umbral es feedback sobre la afirmación, no sobre el umbral. Afilá la pregunta. No bajes la vara.
• Las deny lists no son opcionales en un loop de acciones. Jev va a elegir "Cerrar sesión" sin problema si es el único control que parece avanzar. El loop solo ofrece controles únicos y permitidos, y los nombres destructivos nunca se ofrecen.
• Texto, no píxeles. Jev nunca ve el screenshot. Las regresiones visuales siguen necesitando un modelo de visión o un diff de píxeles. El screenshot del reporte es para el humano.
• La calibración es por población, no por respuesta. La documentación lo dice y se nota: un 0.76 en "clickear el menú de usuario" fue el click correcto, y un 0.38 en WAIT fue la duda correcta. Leé la distribución, no solo el argmax.
• Se combina con las herramientas de agentes que ya usás. El lugar natural para esto no es reemplazar a Expect o a un agente de código, sino ser la capa mecánica a la que llaman para dejar de gastar un turno por click. Eso es justamente lo que hace el bridge de Codex, y lo que hacen la CLI y el skill de acá para todo lo demás.

Probalo

El proyecto es open source en github.com/jonymusky/jev-browser-qa. Es chico a propósito: tres primitivas, una CLI, un dashboard, un skill y un README que dice lo que Jev no va a hacer.

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

Y para tu agente: npx skills add https://github.com/jonymusky/jev-browser-qa --skill jev-qa. Lo vengo corriendo desde Claude Code y desde Grok Build, el agente de terminal de xAI, que lee Agent Skills y AGENTS.md sin ninguna configuración: el mismo prompt, "test this branch with jev-qa and report the verdict with the video path", funciona en los dos, y ninguno de los agentes ve nunca una credencial porque los flows llevan placeholders ${QA_EMAIL} que resuelve la CLI. En el repo hay un walkthrough corto de Grok Build, que incluye la forma headless grok -p para CI. Si querés probarlo sin instalar nada, publiqué un bot de Grok con el skill precargado: QA Engineer. Pasale la URL de tu app y el flow que querés verificar, y te devuelve el veredicto, el video y el screenshot.

En este post tuve cuidado de separar lo que medí de lo que inferí, porque las promesas alrededor de Jev son grandes y el modelo tiene cuatro días. Pero el diseño no es un truco. Un modelo que devuelve una decisión calibrada en lugar de un párrafo, en 400 milisegundos, por una fracción de centavo, cambia en qué partes de tu sistema es razonable poner un modelo. Hasta ahora la respuesta era "en las partes que se lo pueden permitir". Desde esta semana la respuesta se parece más a "en cualquier lugar donde, si no, escribirías un if y te sentirías mal por eso".

Contexto, para que los números signifiquen algo: corremos cinco apps de Next.js. Tres viven en un monorepo de pnpm: un producto de administración de 56 rutas detrás de auth, un sitio público para candidatos con formularios y entrevistas con IA, y un portal chico para empleados. Las otras dos están en repos separados: un dashboard interno de analytics y un sitio de marketing en tres idiomas con un blog en MDX. Las cinco hacen deploy en Vercel. Las cinco corren hoy con React Compiler y Cache Components.

Lo que rindió desde el primer día

El cache de build es real. El cache en filesystem de Turbopack para next build viene activado por defecto en 16.3. Medido esta semana con el último patch, en una laptop: la app de 56 rutas compila en 30 segundos en frío y en 0,8 segundos cuando no cambió nada. En 16.3.0 el mismo rebuild con cache tardaba 6,6 segundos, así que la línea de patches lo mejoró ocho veces sin que tocáramos nada. Las apps más chicas andan entre 4 y 7 segundos en frío y medio segundo con cache. El tiempo total es mayor (la recolección de page data y la generación estática no se cachean), pero el paso de compilación era la parte que nos tenía esperando.

La evicción de memoria cambió una decisión, no un número. Nunca medimos la memoria en dev, pero es la razón por la que nuestro sitio de marketing finalmente dejó next dev --webpack como default. Las sesiones largas de Turbopack crecían hasta que la laptop se quejaba; con la evicción activada por defecto, eso dejó de ser un motivo para mantener webpack. Webpack queda como script de fallback, y eso trae su propia lección más abajo.

catchError es el error boundary que realmente queríamos. Un error.tsx clásico se traga notFound() y redirect(), y su reset solo limpia el estado del cliente. El nuevo boundary de next/error no hace ninguna de las dos cosas: deja pasar esas dos, y su retry() vuelve a hacer fetch de los Server Components que tiene abajo. Lo usamos alrededor de páginas que hacen fetch en el server (con el fallback reportando a Sentry) y, en el blog, alrededor del cuerpo MDX, para que un post roto se degrade a un bloque de "volvé a intentar" en vez de una página en blanco.

TypeScript 7 en next build, con una trampa de pnpm. Cuatro de las cinco apps hacen type-check con el tsc nativo. La que no es el sitio de marketing, porque lintea con typescript-eslint, cuyo parser se rompía con la API de TypeScript 7 cuando lo probamos. Las apps que lintean con Biome nunca tuvieron ese problema. Y con el linker aislado de pnpm, el compilador nativo no incluye automáticamente node_modules/@types, así que cada app necesitó un array "types" explícito en su tsconfig. Diez minutos, pero diez minutos confusos.

Cache Components cambia la semántica HTTP, no solo la velocidad

Esta es la parte que pondría en negrita en cada guía de migración. Con Cache Components una página hace streaming sobre un shell prerenderizado, y el shell sale con un 200. Si después tu página llama a notFound() mientras renderiza la parte dinámica, el status ya está en el cable. El usuario ve tu UI de not-found. Google ve un 200.

Lo medimos en el sitio de marketing antes de arreglarlo: un slug de blog inexistente, un slug de landing de anuncios inexistente y un slug de página de comparación inexistente respondían todos 200. Tres familias de rutas enteras devolviendo "encontrado" para cualquier basura, justo en la propiedad donde los crawlers son el cliente. El arreglo sigue la guía del propio framework: establecer que la página existe antes del primer byte. Nuestro proxy ahora valida los slugs del blog contra un manifest generado en build (así no puede quedar desactualizado en producción, y lleva las fechas de publicación para que los posts programados sigan funcionando), valida los otros dos contra sus tablas estáticas, y reescribe lo que no matchea a un path que ninguna ruta atiende. El router entonces sirve la página de not-found con nuestra marca y un 404 de verdad.

El segundo cambio semántico es que los segment configs desaparecieron. export const revalidate = 3600, dynamic = "force-static", dynamic = "force-dynamic": ninguno está permitido una vez que activás el flag. No es un renombre. revalidate pasa a ser un scope 'use cache' con cacheLife('hours'), y todo lo que lea el reloj se tiene que mover adentro de ese scope. Nuestro blog filtra posts por fecha de publicación con new Date(); fuera de un scope de cache eso es data de request y un error de prerender directo, adentro el reloj se lee una vez por entrada de cache y los posts programados igual aparecen dentro de la hora. Una vez hecho eso, se prerenderizaron 204 páginas en build y un segundo hit a un post pasó de 129 ms a 29 ms.

Root params es lo que destraba i18n, y todavía no lo encaramos

El ejemplo de import.meta.glob del release post es un blog que lee archivos MDX con gray-matter. Es literalmente el nuestro, así que lo probamos en agosto. Compiló, y pasó las rutas del blog de dinámicas a completamente estáticas, lo que rompió el locale en tiempo de request de next-intl con 500s en runtime. Las lecturas sincrónicas de fs son estructurales hasta que el layout deje de derivar el locale de params.

Ese mismo layout es la razón por la que el sitio de marketing lleva export const instant = false en todo su árbol de locale: un layout que elige <html lang> y sus mensajes a partir de params no puede producir un shell estático instantáneo. Root params (lang() de next/root-params) más setRequestLocale es la solución, y es el próximo paso para esa app. Si tu app está internacionalizada con un segmento [locale], esa migración es el precio de Instant Navigations, y conviene presupuestarla de entrada en vez de descubrirla a través de instant = false.

Experimental quiere decir experimental

El React Compiler basado en Rust es la feature que más me entusiasmaba y la que más nos costó. Pasaron dos cosas.

Primero, en nuestra app más grande mata el build por OOM en el contenedor estándar de Vercel, unos 25 segundos después de arrancar una compilación en frío. La misma app buildea bien por el camino de Babel (el doble de lento, pero entra), y las apps más chicas buildean bien con el port de Rust. Lo reportamos, un maintainer se involucró ese mismo día, y para fines de agosto habían reducido a la mitad el pico de memoria del compilador, con un camino de crecimiento cuadrático como el probable disparador en nuestro código. Ese trabajo está en canary. Esta semana volvimos a correr el experimento con el último patch de 16.3, en un preview deployment, y nos dio el mismo SIGKILL. Así que nuestra config mantiene un guard por target: port de Rust en todos lados excepto en los builds en Vercel de esa app, donde el compilador corre por Babel.

Segundo, el port de Rust pierde la clase de scoping jsx-<hash> en elementos renderizados condicionalmente dentro de componentes con estado, así que las reglas scoped de <style jsx> dejan de matchear sin avisar. Nos dejó los labels del sidebar invisibles en producción. Mantuvimos un repositorio con un repro mínimo (vercel/next.js#96694) y esta semana lo volvimos a correr contra tres versiones: sigue roto en el último patch de 16.3, arreglado en el canary de 16.4. Eso convirtió un "capaz ya está arreglado" en un número de versión, y significa que nuestra regla de "nada de styled-jsx scoped" se queda exactamente hasta 16.4.

Dos cosas más chicas del mismo rubro. output: 'standalone' combinado con un adapter rompía los deploys en Vercel en 16.3.0 (faltaba un archivo de trace); el fix se mergeó a canary dos días después y, a esta semana, todavía no salió en ningún patch estable de 16.3. Fijate el tag, no el PR. Y el guard de config para nuestro fallback a webpack originalmente miraba process.argv buscando --webpack, lo que nunca matchea porque next.config se evalúa en el proceso interno del server de Next. Un reviewer lo detectó corriendo de verdad el fallback. Un guard que nunca ejercitás es un guard que no tenés.

El bug que no tenía nada que ver con Next.js

Toda la adopción de 16.3 del sitio de marketing se revisó, se aprobó y se mergeó el 4 de agosto. Se mergeó a la feature branch sobre la que estaba apilada, y esa branch nunca se volvió a mergear. Durante un mes el sitio corrió un binario de 16.3 con webpack en dev, sin compilador y con los segment configs viejos. No se rompió nada, que es exactamente por qué nadie se dio cuenta, y lo encontré recién esta semana haciendo grep en main buscando un flag que tendría que haber estado ahí. Volvimos a aplicar la intención a mano; un cherry-pick tenía diez archivos en conflicto contra un mes de trabajo de diseño. Los PRs apilados están bien. Los PRs apilados cuya base no es main necesitan un recordatorio en la base.

Lo que le diría a otro CTO

• Tomá los patches. 16.3.3 arregló dos advisories críticos de ejecución remota de código, uno de ellos en la optimización de imágenes con AVIF, que es el primer formato que sirve nuestro sitio de marketing. Nada en la línea 16.3.x nos exigió cambios de código. No hay motivo para quedarse en 16.3.0.
• Medí tus 404 después de activar Cache Components. Un curl por familia de rutas. Si ves 200 donde esperás 404, mové los chequeos de existencia al proxy.
• Tratá revalidate como una migración. Encontrá cada segment config, encontrá lo que lee el reloj, movelo adentro de un scope de cache.
• Dale a cada flag experimental una salida de emergencia por target y una forma de volver a testearlo. La nuestra es un commit en el preview de un pull request y un revert. Seis minutos, y ahora sabemos la respuesta para este patch.
• Guardá un repo de repro por cada bug que reportes. Volver a correrlo contra una versión nueva cuesta dos minutos y responde la pregunta que los comentarios upstream no pueden responder.
• Un fix en canary no es un fix en tu build. Fijate el release tag.
• Si estás internacionalizado, planificá la migración a root params antes de planificar Instant Navigations. Es el mismo proyecto.

16.3 es un buen release. Solo el cache de build y el error boundary ya justificaban el upgrade, y Cache Components es el modelo correcto para las apps que construimos. Pero el release post describe un destino, y el camino hasta ahí pasa por tu proxy, tu layout de i18n y el límite de memoria de tu contenedor de build. Saber eso antes de arrancar es la mayor parte del trabajo.