Saltar al contenido
ReviewRamble

El boletín semanal

La IA, analizada, en tu bandeja de entrada.

  • Nuevas reseñas de herramientas, modelos, servidores MCP y repos, con el veredicto por delante
  • Precios y valoraciones revisados cuando algo cambia
  • Nuevos análisis en cuanto se publican

Modelos, agentes, servidores MCP y las herramientas que de verdad merecen tu tiempo.

Un correo a la semana. Date de baja con el enlace de cualquier boletín. Cómo usamos tu correo

Análisis Programación

Probar apps de IA y dejar que la IA pruebe las tuyas: las capas, las herramientas y lo que cuestan

Por Sheela ·

Las pruebas ahora van en dos direcciones. Si lanzas una función de IA, necesitas pruebas para algo que da una respuesta ligeramente distinta cada vez. Si lanzas software corriente, las herramientas de IA se ofrecen ahora a escribir y mantener tus pruebas. Los dos mercados están saturados, los dos tienen precios que esconden la factura real y los dos tienen un modo de fallo que parece una build en verde. Así conviene pensar en las capas, qué herramienta de las 16 que hemos analizado encaja con cada trabajo y una configuración inicial que un responsable de equipo puede defender.

El mapa: dos trabajos, siete capas

La mayor parte de la confusión viene de comparar herramientas que hacen trabajos distintos. Una biblioteca de métricas RAG y un agente de navegador se llaman las dos "pruebas con IA", y ninguna sustituye a la otra. Ordena primero el trabajo.

Probar una aplicación o un agente de IA tiene cuatro capas:

  • Evals: entradas fijas, salidas puntuadas. ¿La respuesta se mantiene fiel a las fuentes? ¿La llamada a herramienta va a la función correcta? Es tu prueba unitaria.
  • Conversaciones simuladas: un segundo modelo hace de usuario durante varios turnos, porque los agentes fallan en el turno cuatro, no en el uno.
  • Regresión de red team: ataques generados (inyección de prompts, fugas de datos, salidas dañinas) que se vuelven a ejecutar en cada cambio, para que un agujero cerrado siga cerrado.
  • Puntuación en producción: los mismos evaluadores se ejecutan sobre trazas reales, y las malas respuestas de usuarios reales se convierten en nuevos casos de prueba.

La IA que prueba software corriente tiene tres:

  • Grabar y reproducir para backends: capturar llamadas reales a la API y las respuestas de la base de datos que hay detrás, y reproducirlas como pruebas.
  • Grabar y reproducir para front ends: capturar sesiones reales y comparar cómo se ven las pantallas antes y después de un cambio.
  • Agentes de navegador: una IA que planifica, escribe, ejecuta y repara pruebas de extremo a extremo, en tu repositorio o en la nube de un proveedor.

Probar tu aplicación de IA

Evals: la capa que hay que construir primero

promptfoo (4,5) es el camino más corto de no tener pruebas de LLM a tenerlas en CI: un archivo YAML de prompts, proveedores y aserciones, y un comando que muestra una matriz comparativa. Necesita Node.js 22.22 o posterior. Un punto a sopesar: el 9 de marzo de 2026 OpenAI anunció que adquiriría promptfoo, y la empresa dice ahora que forma parte de OpenAI. Sigue con licencia MIT y admite otros proveedores, pero algunos equipos no querrán que su evaluador pertenezca a un proveedor al que están evaluando.

DeepEval (4,2) encaja con equipos de Python que quieren evals dentro de su batería de pruebas existente. Las pruebas parecen de pytest, se ejecutan con deepeval test run y hacen fallar la build cuando la fidelidad o la finalización de tareas cae por debajo de un umbral. Su catálogo de métricas es de los más amplios del código abierto y llega a la planificación de agentes y a la voz.

Giskard (4,0) reúne comprobaciones deterministas, comprobaciones juzgadas por LLM, generación de conjuntos de prueba RAG y un escaneo de red team en una sola biblioteca Apache-2.0. La versión 3 es una reescritura que necesita Python 3.12 o posterior y elimina el escaneo de modelos tabulares en el que confiaban los usuarios de v2.

Dos que quizá ya tengas. Ragas (3,4) dio a la evaluación RAG su vocabulario (fidelidad, precisión de contexto) y sigue sumando unos 1,05 millones de descargas al mes en PyPI, pero nadie ha hecho un commit desde el 24 de febrero de 2026. Mantenlo si funciona; no empieces proyectos nuevos con él. Inspect (4,4), del UK AI Security Institute, es el arnés que usan los institutos públicos de seguridad de IA, con más de 200 evals ya hechas. Es la herramienta adecuada para benchmarks de modelos y más framework del que necesita un equipo de producto que comprueba prompts en CI.

Conversaciones simuladas

Las evals de un solo prompt no detectan al agente que responde bien a la primera pregunta y tres turnos después olvida una restricción. LangWatch Scenario (3,9) lo prueba hablando con tu agente: un modelo hace de usuario, otro juzga cada turno, y todo se ejecuta como una prueba normal de pytest o vitest. Puedes fijar el mensaje inicial, inyectar un resultado de herramienta simulado, comprobar que se llamó a una herramienta concreta y dejar que el simulador continúe. También cubre agentes de voz, con inyección de ruido y latencias p50 y p95. Es un proyecto pequeño, unas 1.000 estrellas y 165 issues abiertas, y funciona mejor junto a una biblioteca de evals que en su lugar.

Regresión de red team en CI

Un escaneo de red team ejecutado una vez antes del lanzamiento es una auditoría. Repetido en cada pull request, se convierte en una prueba de regresión. promptfoo genera ataques de inyección de prompts, jailbreaks y exfiltración de datos; por defecto esa generación se ejecuta en su servicio alojado, y el nivel gratuito Community limita el red teaming a 10.000 sondas al mes. El escaneo de Giskard escribe una batería adversaria a partir de una descripción en lenguaje llano de lo que tu agente debe y no debe hacer, mapeada al OWASP LLM Top 10. El RedTeamAgent de Scenario cambia el usuario simulado educado por un atacante que escala a lo largo de varios turnos, más parecido a cómo funcionan los jailbreaks reales que un único prompt hostil.

Puntuación en producción

Las pruebas previas al lanzamiento solo cubren las entradas en las que pensaste. Braintrust (4,3) gira en torno a la pregunta de si el último cambio mejoró las cosas: experimentos, conjuntos de datos y puntuación en línea comparten un mismo modelo de datos, así que una mala respuesta en producción se convierte en un caso de prueba en unos clics, y el mismo evaluador se ejecuta en CI y sobre el tráfico real. Langfuse (4,6) es la vía de código abierto, con trazas, conjuntos de datos, experimentos y puntuación con LLM como juez en una edición autoalojada gratuita, a cambio de mantener tú mismo Postgres, ClickHouse, Redis y almacenamiento de objetos.

Dejar que la IA pruebe tu software

Grabar y reproducir

Keploy (4,0) es para el backend sin pruebas. Ejecutas tu servicio con keploy record, recorres los flujos y captura las llamadas a la API junto con el tráfico de PostgreSQL, MySQL, MongoDB, Redis, Kafka o RabbitMQ que provocaron. keploy test reproduce las peticiones y sirve las dependencias grabadas como mocks, así que CI no necesita base de datos de prueba. En Linux lo hace con eBPF, lo que significa ningún cambio de código pero sí root y kernel 5.10 o posterior; las versiones nativas de macOS y Windows solo reproducen de forma fiable HTTP, MySQL y MongoDB.

Meticulous (3,7) hace lo mismo para front ends. Un script de grabación en builds de staging o de vista previa captura sesiones y las respuestas del backend que recibieron; en cada pull request las reproduce contra el código antiguo y el nuevo y agrupa las pantallas que se ven distintas. Revisas una lista de cambios visuales en lugar de escribir código de prueba. Comprueba cómo se ve la pantalla, no si el pedido llegó a tu base de datos.

Agentes de navegador

Es el rincón más concurrido, y las cuatro opciones se diferencian sobre todo en quién es dueño de las pruebas y quién las ejecuta.

Playwright Test Agents (4,1) vienen gratis con Playwright. Un planificador explora tu aplicación y escribe un plan de pruebas en Markdown, un generador convierte el plan en pruebas de Playwright en tu repositorio y un reparador arregla las pruebas que fallan, una a una. Se ejecutan dentro del agente de programación que ya usas (VS Code, Claude Code, Codex u opencode) y llaman a Playwright MCP (4,7) para manejar el navegador. El resultado es código Playwright normal, sin ningún proveedor de por medio.

Momentic (4,0) te deja escribir una prueba como una frase, la guarda como YAML en tu repositorio y la ejecuta en navegadores alojados, emuladores de Android o simuladores de iOS. Cuando un botón se mueve, el auto-heal lo vuelve a encontrar y propone una edición para que la revises.

TestSprite (3,7) se coloca detrás de tu agente de programación: lee el código o un documento de requisitos, escribe pruebas de frontend y backend, las ejecuta en su nube y devuelve un paquete de fallo con capturas de pantalla, la estructura de la página y una corrección sugerida.

QA Wolf (4,1) vende el trabajo en vez de la herramienta. Sus agentes escriben y ejecutan pruebas de Playwright y Appium, deciden si un fallo es una prueba desfasada o un bug real y registran los bugs con vídeo en Linear o Jira; en el plan gestionado, ingenieros de QA humanos revisan cada fallo en menos de 24 horas. El código se puede exportar.

Un aviso sobre las pruebas unitarias generadas por IA. Qodo (3,8), la empresa antes llamada CodiumAI y conocida al principio por generar pruebas, dejó obsoleto este otoño su comando de generación de pruebas sin sustituto y ahora vende revisión de pull requests. Los agentes de programación escriben pruebas unitarias encantados si se les pide; el riesgo es que una prueba escrita a partir del código compruebe lo que el código hace, no lo que debería hacer. Que una persona escriba o apruebe la aserción.

Qué herramienta para qué trabajo

TrabajoEmpieza conNuestra notaLo que cuesta
Pruebas de regresión de prompts y RAG en CIpromptfoo o DeepEval4,5 / 4,2Gratis; pagas tokens del juez y del modelo
Comprobaciones, preguntas RAG y escaneo de red team en una biblioteca de PythonGiskard4,0Gratis; tokens del juez, gpt-4o-mini por defecto
Comportamiento de agentes en varios turnosLangWatch Scenario3,9Gratis; dos llamadas a LLM por turno y por prueba
Benchmarks de modelos y evals de seguridadInspect4,4Gratis; tokens y cómputo de sandbox
Puntuar tráfico de producción, alojadoBraintrust4,3Nivel gratuito; Pro 249 $ al mes
Trazas y evals que alojas túLangfuse4,6Gratis autoalojado; nube desde 29 $ al mes
Backend sin pruebasKeploy4,0CLI gratuita; Pro 19 $ por usuario al mes
Regresiones visuales en un front end con mucho movimientoMeticulous3,7No publicado
Pruebas de extremo a extremo propias, ya en PlaywrightPlaywright Test Agents4,1Gratis; tokens del agente de programación
Pruebas de extremo a extremo en lenguaje llano, web y móvilMomentic4,050 $ de uso gratis; Scale 500 $ al mes
Un agente de programación que comprueba su propio trabajo en un navegadorTestSprite3,7Desde 19 $ al mes en créditos
Delegar las pruebas de extremo a extremo en otrosQA Wolf4,11 $ por ejecución web, 2 $ por ejecución móvil

Lo que cuesta de verdad

Casi todas las herramientas de evals de código abierto son gratis de instalar y se pagan en tokens al ejecutarlas. DeepEval, Ragas y Giskard puntúan la mayoría de las métricas con un juez LLM, así que la factura es más o menos casos de prueba por métricas por ejecuciones. Unos cientos de casos en cada pull request suman, y Scenario lo duplica, porque un simulador y un juez hablan en cada turno. Ejecuta la batería completa cada noche y un pequeño conjunto de humo en cada pull request.

Las plataformas alojadas miden de otra forma, y el contador decide a quién le convienen. Braintrust cobra por datos y puntuaciones, no por puestos: Pro a 249 $ al mes cubre 5 GB y 50.000 puntuaciones, y después 1,50 $ por cada 1.000 puntuaciones, así que juzgar cada petición de producción es la línea que más crece. El propio ejemplo de Langfuse sitúa Pro con 5 millones de unidades en 551 $ al mes. La nube de LangWatch cuesta 29 € por puesto en Growth, y Confident AI, la de DeepEval, salta de Free a 200 $ al mes.

En pruebas de navegador, la unidad es la ejecución o el paso. El propio ejemplo de QA Wolf, 50 pruebas web cada día laborable, sale por unos 1.083 $ al mes, y ejecutar las mismas pruebas en cada pull request lo multiplica. Momentic cobra 0,0125 $ por paso normal y 0,025 $ por un paso que la IA tuvo que resolver; sus 50 $ gratuitos equivalen a unos 4.000 pasos, y cuando se agota el saldo las pruebas se pausan en vez de gastar de más. Starter de TestSprite cuesta 19 $ por 400 créditos, pero la página de precios nunca dice qué compra un crédito. Pro de Keploy incluye 400 ejecuciones de prueba y después 0,22 $ cada una. Meticulous no publica ningún precio; las estimaciones en sitios de reseñas van de unos 2.000 $ al año a 600 $ al mes.

Dónde te engañan estas herramientas

  • Jueces inestables. Un juez es un modelo, y falla como tal. Entre las issues más comentadas de DeepEval están los jueces que devuelven JSON inválido, lo que hace fallar la prueba por un motivo ajeno a tu aplicación. Las puntuaciones también cambian cuando cambia el modelo juez, así que fija la versión del juez y trata su actualización como la de una dependencia: vuelve a ejecutar la línea base antes de comparar.
  • No determinismo. Tu aplicación varía, el usuario simulado varía y el juez varía. El cache_key de Scenario hace que el usuario simulado se repita, pero un prompt modificado invalida la caché. Mide tasas de acierto sobre varias ejecuciones y alerta ante una caída, en lugar de hacer fallar la build por una sola muestra en rojo.
  • Autorreparación que esconde bugs. El trabajo de un reparador es poner en verde una prueba roja, y a veces el resultado correcto es rojo. La documentación de Playwright dice que el reparador puede decidir que una función está rota y saltarse la prueba, algo que un equipo con prisa puede tomar por un aprobado. Momentic propone correcciones para revisar en lugar de aplicarlas en silencio, y los agentes de QA Wolf intentan separar las pruebas desfasadas de los bugs reales. Compres lo que compres, lee cada diff reparado y cuenta las pruebas saltadas como fallos.
  • Las grabaciones solo conocen el pasado. Keploy y Meticulous cubren solo lo que alguien hizo mientras se grababa, y las respuestas grabadas se quedan obsoletas cuando cambia el esquema. Una batería de reproducción en verde no dice nada del flujo que nadie recorrió.
  • Tus datos salen del edificio. TestSprite ejecuta las pruebas en su nube, así que las páginas y capturas de tu aplicación pasan por su infraestructura. El grabador de Meticulous captura pulsaciones de teclas y respuestas de red; las contraseñas se ocultan por defecto, el resto de datos personales necesita reglas que escribes tú. La telemetría viene activada por defecto en promptfoo, DeepEval, Ragas y Giskard, y cada llamada al juez envía tus prompts de prueba al proveedor que configures.

Una configuración inicial

Para un equipo con una función de IA y una aplicación web corriente, esto cubre la mayor parte del riesgo por poco más que el coste en tokens:

  1. Escribe de 30 a 50 casos de eval a partir de preguntas reales de usuarios en promptfoo o DeepEval, con aserciones deterministas siempre que la respuesta lo permita y un juez LLM solo cuando no. Ejecútalos en cada pull request que toque un prompt o un modelo.
  2. Añade un escaneo de red team (promptfoo o Giskard) a la build nocturna y convierte cada ataque que pase en un caso de prueba permanente.
  3. Si la función es un agente, añade de tres a cinco pruebas de Scenario para las conversaciones que ya han ido mal antes, con el usuario simulado en caché.
  4. Envía las trazas de producción a Langfuse o Braintrust y pasa cada semana un puñado de malas respuestas al conjunto de evals.
  5. Para el resto de la aplicación, cubre los cinco flujos que nunca deben romperse (registro, pago, la exportación de la que depende un cliente grande) con Playwright Test Agents si ya usas Playwright, o con el nivel gratuito de Momentic si no. Que alguien revise cada plan y cada prueba reparada.
  6. Configura las opciones de exclusión de telemetría (PROMPTFOO_DISABLE_TELEMETRY, DEEPEVAL_TELEMETRY_OPT_OUT=1, DO_NOT_TRACK=1) antes de la primera ejecución, no después.

La pega: cada capa de aquí abarata producir una batería de pruebas, y ninguna decide qué significa correcto. Un conjunto de evals que solo hace preguntas fáciles aprueba, un reparador que reescribe aserciones aprueba y una reproducción del tráfico del mes pasado aprueba. La parte cara de probar siempre ha sido decidir qué comprobar, y ese trabajo sigue siendo de tu equipo.

Nuestra opinión: trata la IA en las pruebas como a una nueva incorporación rápida. Deja que escriba los casos, los ejecute y proponga correcciones, y deja en manos de una persona la lista de lo que debe ser cierto y la aprobación de cualquier prueba que cambie. Paga un servicio alojado solo cuando la factura sea menor que el tiempo que alguien de tu equipo dedica a mantener viva la versión gratuita.

El boletín de ReviewRamble

La IA, analizada. Una vez a la semana, en tu bandeja de entrada.

Los veredictos que importan en IA, robótica y tecnología, con qué usar y qué evitar. Sin bombo ni resúmenes de todo.

Modelos, agentes, servidores MCP y las herramientas que de verdad merecen tu tiempo.

Un correo a la semana. Date de baja con el enlace de cualquier boletín. Cómo usamos tu correo