Piloto Cliente: Empire Essence

Robot de QA que revisa el checkout antes de cada cambio

Resultado: Un comando y unos 65 segundos. El robot compra en una copia de prueba, en computador y celular, y te dice si algo se rompió.

evidencia: Reporte completo de la corrida: 20 de 20 casos, 60 pruebas unitarias, error inyectado atrapado, video y trace evidencia ↗

20/20 casos del checkout en verde evidencia ↗
65 s por corrida completa evidencia ↗
60 pruebas unitarias evidencia ↗
Harness de QA · reporte

Para el dueño

Resultado para el negocio

  • Cada cambio en la tienda puede romper el pago.
  • Piloto en mi tienda. 20 de 20 casos del checkout en verde y 60 pruebas unitarias. Atrapa el error inyectado en las dos pantallas. Corre sobre datos sintéticos: no hace compras ni pagos reales. Ganó el reto de la clase de harness de Ricardo Celis en Gradiente (8 de octubre de 2026).
  • Construyo con control de calidad desde el principio. Un sistema de IA sin pruebas es una apuesta.

En una línea

Un comando y unos 65 segundos. El robot compra en una copia de prueba de mi tienda, en computador y en celular, y me dice si algo se rompió. Con este proyecto gané el reto de harness de la clase de Ricardo Celis en Gradiente Escuela de Ingeniería, el 8 de octubre de 2026.

Contexto

Tengo una tienda en línea de perfumes. Cada vez que cambio algo, un precio, un texto, una sección, puedo romper el checkout sin darme cuenta. Y si el checkout falla, pierdo ventas y ni me entero.

En la clase de Ricardo Celis nos retaron a construir nuestro propio harness, mostrarlo funcionando y hacer un video. Escogí el problema que más me dolía en mi negocio.

El problema

  • Revisar el checkout a mano en cada cambio es lento y aburrido. Por eso uno termina no haciéndolo.
  • Lo que funciona en el computador puede fallar en el celular, y la mayoría de mis clientes compran desde el celular.
  • Un error pequeño, como una casilla de promociones marcada por defecto, puede ser un problema legal y de confianza.

El enfoque

Un harness es el arnés que rodea al trabajo automático: las reglas, los límites, las pruebas y la evidencia. La idea central fue esta: la IA no necesita más libertad, necesita reglas claras.

Por eso el robot tiene límites duros:

  • Nunca toca la tienda real. Trabaja sobre una copia de prueba con datos sintéticos.
  • No hace compras ni pagos reales.
  • No puede decir “terminé” sin evidencia: video, trace y resumen.
  • Se prueba a sí mismo. Le meto un error a propósito y lo tiene que atrapar. Si no lo atrapa, el robot no sirve.

Qué construí

  • Un solo comando que levanta la copia de prueba del checkout.
  • Recorrido completo en computador y en celular: llena el formulario con datos sintéticos, deja las promociones sin marcar y confirma el pedido.
  • Prueba negativa. Inyecta un defecto: las promociones vienen marcadas por defecto. El robot lo atrapa en las dos pantallas.
  • Evidencia al final. Un video del recorrido, el trace técnico para depurar y un resumen en español que cualquier persona entiende.

Lo construí con Claude Code y Codex. Yo definí qué debía revisar, qué no podía tocar y cuándo se consideraba terminado. Los agentes escribieron el código y las pruebas. Yo revisé y corrí todo antes de grabar.

Demo y estado

  • Estado: piloto en mi propia tienda.
  • Resultados de la demo: 20 de 20 casos del checkout en verde, 60 pruebas unitarias y la prueba negativa correcta. La demo completa, con video, tarda unos 65 segundos.
  • Límite honesto: corre sobre una copia con datos sintéticos. No certifica la tienda real, los pagos ni el CRM.
  • Lo que vino después: con la misma idea armé un segundo revisor que mira la tienda publicada en busca de errores de diseño, contenido y SEO, y prueba la compra hasta antes de pagar.

Lo que aprendí

  • Un robot que nunca falla no prueba nada. La prueba negativa es lo que le da valor. Si no atrapa un error que yo mismo puse, no le creo cuando dice que todo está bien.
  • La evidencia vende. El video y el resumen en español fueron lo que más gustó en la clase. Un dueño de negocio no lee un trace. Sí ve un video y lee un resumen.
  • Contarlo con honestidad también cuenta. En el video dije que el robot prueba una copia con datos falsos. Prefiero eso a que alguien crea que certifico pagos reales.

Qué se rompió y cómo lo encontré

  • Un robot que siempre decía “todo bien”. Antes de la prueba negativa no había forma de distinguir un robot que funciona de uno roto. Metí un error a propósito (casillas de marketing premarcadas) e hice que dos pruebas fallaran por esa causa, en escritorio y celular. Ahora cada corrida demuestra que el detector funciona.
  • “Listo” sin evidencia. Una corrida podía terminar sin video o con un trace viejo y verse terminada igual. La revisión de cobertura ahora rechaza omisiones, fallos, reintentos y evidencia ausente, alterada o de otro código.
  • Un puerto ocupado probaba lo que no era. Si el puerto 4173 está ocupado, el runner se niega a arrancar en vez de reutilizar un servidor desconocido. Mejor fallar que probar la aplicación de otro.

¿Tu tienda o tu web necesitan esto?

Si tienes una tienda en línea, un formulario de contacto o un sistema de reservas, un robot así te avisa antes de que se entere tu cliente.

Escríbeme por LinkedIn

Para el equipo que contrata

Notas técnicas

Arquitectura
Playwright con Node.js sobre un servidor fixture local (puerto 4173); un solo comando corre las pruebas unitarias, las diez reglas en escritorio y celular, la prueba negativa y la revisión de cobertura.
Datos
Solo datos sintéticos; sin compras, pagos ni clientes reales; cada corrida deja run.json, results.json, un veredicto, un resumen en español, video y trace.
Pruebas
60 pruebas unitarias, 20 casos del checkout (10 reglas × 2 pantallas), 2 pruebas negativas que deben fallar por el error inyectado; ciclo completo en unos 65 segundos.
Dónde corre la IA y sus guardas
Sin IA en tiempo de ejecución. Construido y gobernado con Claude Code y Codex bajo guardas que limitan herramientas, rutas y destinos; nada lee .env ni toca la tienda en vivo.
Costo mensual de operación
Costo de nube cero: corre en un portátil. El perfil de staging es una prueba de humo de solo lectura.
Repositorio y estado
Repositorio privado. Piloto en mi propia tienda. Ganador del reto en Gradiente, 8 de octubre de 2026. Página de evidencia con la corrida.

Con qué

PlaywrightNode.jsClaude CodeCodex

Siguiente caso

Demo funcional Agente de primera consulta laboral para Leal Abogados Ver el caso→

¿Qué tarea repite tu equipo todos los días?

Cuéntamela en un mensaje. Te respondo con una idea concreta de lo que se puede automatizar, o con un no honesto.

Respondo personalmente. Normalmente en uno o dos días hábiles. · Bogotá, Colombia

Hablemos Casos→