Abres LinkedIn y alguien explica, con cara de revelación, qué es un agentic loop. Scrolleas un poco y otro te enseña a escribir verifiable goals. En el hilo de abajo, alguien presenta el test harness como si fuera la última frontera de la ingeniería con IA.
Tres conceptos. Los tres vendidos como territorio nuevo, vocabulario de una era nueva.
Los tres son tuyos. Salieron del testing mucho antes de que existiera el vibe coding, y los usas todos los días aunque nadie te haya dado los nombres.
Y hay un detalle que los vuelve más tuyos todavía: cada vez que alguien explica estos tres conceptos, lo hace desde la silla del dev o del que vibe-codea. Cómo el agente le escribe el código, cómo le genera la feature, cómo le cierra el ticket. Desde la silla del QA no los explica casi nadie. Ese asiento está vacío, y es justo el que vengo a ocupar acá: bajar loop, goal y harness a tu trabajo, no al del que programa.
Este artículo es para devolvértelos. No como trivia para ganar discusiones en Twitter, sino porque entender de dónde vienen cambia tu lugar en toda esta conversación: dejas de ser quien corre detrás de la IA y pasas a ser quien ya conoce el modelo que la IA está usando.
Tres palabras prestadas
Antes de ir una por una, mira el mapa completo. A la izquierda, cómo te llega el concepto envuelto en lenguaje de agentes. A la derecha, su nombre de toda la vida. Y al medio, lo que ya haces con él.
| Como lo vende el mundo IA | Cómo se llama en testing | Lo que ya haces |
|---|---|---|
| Test harness para tu agente | Test harness | Tu framework de tests (fixtures, runner, reportes) |
| Verifiable goal | El problema del oráculo | Cada assert que escribes |
| Agentic loop | Arrange-act-assert | Tu ciclo de prueba y tu proceso diario |
Ninguna fila tiene magia. Las tres describen cosas que un QA hace antes del desayuno. Vamos a desarmarlas.
Si trabajas con herramientas de IA, quizá viste “loop” o “goal” como un comando o un botón —algunas los tienen con ese nombre exacto. No me refiero a eso. Hablo de la idea que existe desde mucho antes que cualquier comando. Que tu herramienta los tenga como función no es casualidad: tomó prestado el vocabulario del testing. Lo que vas a entender acá es el concepto, no el botón.
Harness: el arnés que ya armaste
En el mundo de los agentes, el harness es el andamiaje que rodea al modelo: lo conecta a sus herramientas, le da un entorno donde actuar y observa lo que hace. Se presenta como una pieza de ingeniería sofisticada, y lo es.
También tiene décadas encima. Un test harness es exactamente eso: el armazón que toma el código o la aplicación bajo prueba, lo pone en condiciones controladas, lo ejecuta y registra el resultado. Preparar el estado, disparar la acción, observar la salida. Esa estructura no nació con los LLM. Nació con el testing automatizado.
El que vibe-codea llega al harness de rebote, el día que necesita que su agente corra sin tenerlo encima. Tú llegaste mucho antes: la primera vez que te tocó montar una suite y hacerla sobrevivir más de una semana.
Y acá está lo que casi nadie te dijo: cuando un líder técnico te suelta “arma un framework de automatización desde cero”, te está pidiendo construir un harness. No te da la palabra, no te da el modelo, solo el encargo. Por eso tanta gente se paraliza frente a esa tarea: no le falta habilidad para escribir un test, le falta el mapa de qué es la cosa entera que está construyendo.
Escribir el primer test es fácil. Diseñar el andamiaje que va a sostener los próximos mil es lo que nadie te enseñó a nombrar.
Tu suite de Playwright es un harness. Tu proyecto de Selenium es un harness. Las fixtures que preparan datos, el runner que dispara los casos, los reportes que te dicen qué pasó: esas son las piezas del arnés. La IA no inventó el concepto. Lo tomó prestado de tu disciplina para describir lo que necesitaba para correr.
Y ahora que la IA entró a tu trabajo, el concepto da un salto. El arnés ya no envuelve solo tu código bajo prueba: también puedes envolver a tu propio agente de IA. Darle tus herramientas (tu tracker, tu espacio de documentación), tu método (cómo analizas un ticket, cómo cierras un ciclo), tus reglas. Yo armé el mío: un arnés alrededor de mi agente de QA que lo convierte en un compañero de trabajo real, no en un chat que responde suelto. Es el mismo concepto de siempre —el andamiaje que rodea al que ejecuta y lo hace rendir— aplicado ahora al modelo, no solo al test.
Goal: el problema del oráculo con ropa nueva
El segundo término de moda es el verifiable goal: cómo sabe un agente que terminó, y que terminó bien. Sin un objetivo que se pueda verificar, el agente da vueltas o se conforma con cualquier cosa.
Eso, en testing, tiene nombre y apellido desde hace muchísimo: el problema del oráculo. La pregunta más vieja y más central de toda la disciplina es quién decide qué resultado es correcto. No el que produce la respuesta. Alguien —o algo— independiente que tenga el criterio de la verdad.
Un dev se topa con esta pregunta ahora, cuando su agente tiene que decidir solo si su respuesta sirve. En QA es la pregunta de siempre: la respondes cada vez que diseñas un caso y defines, antes de ejecutar, cuál es el resultado correcto. Eso es un oráculo, y lo escribes a mano desde el primer día.
Y resulta que ese oráculo lo escribes en una línea, todos los días:
// Un goal verificable de manual: el oráculo cabe en una expresiónexpect(respuesta.status).toBe(200);expect(usuario.saldo).toBe(saldoEsperado);Cada assert es un goal verificable. Defines, por fuera del código que ejecutó, cuál es la condición de éxito. Llevas años escribiendo lo que el mundo de los agentes está redescubriendo con asombro.
Pero hay un detalle que tú entiendes mejor que nadie, y que tanto ruido alrededor de la IA suele pasar por alto: el que ejecuta no puede ser el que califica. Cuando una IA genera un test y después se autoevalúa diciendo “sí, está correcto”, es el mismo dev revisando su propio pull request. Va a aprobar su punto ciego. El oráculo tiene que venir de afuera de la cabeza que produjo la respuesta.
Si la IA escribe el test y la misma IA decide si el test es bueno, no tienes un oráculo: tienes un eco. El criterio de “correcto” tiene que ser independiente. Ese es tu terreno, y es exactamente por lo que sigues haciendo falta cuando la IA genera tests.
Si quieres ver este principio aplicado a un caso real, lo conté en Claude como investigador, no generador: la IA es buenísima encontrando ángulos cuando tú sostienes el criterio de verdad, y peligrosa cuando le cedes ese criterio.
Loop: arrange-act-assert lleva décadas dando vueltas
El tercero es el agentic loop: percibir, razonar, actuar, observar y repetir hasta cumplir el objetivo. Se dibuja como el corazón de los sistemas autónomos modernos.
Y ojo con la palabra, porque acá es donde más se confunde: este loop no es un comando que escribes en tu herramienta de IA. Algunas tienen uno con ese nombre que repite tareas cada cierto tiempo —eso es otra cosa, un reloj—. Yo hablo del ciclo: actuar, ver qué pasó, ajustar, repetir hasta cumplir. La idea, no el botón.
Mira tu test más simple:
test("login con credenciales válidas", async ({ page }) => { // Arrange — preparas el estado await page.goto("/login");
// Act — actúas await page.fill("#email", "qa@ejemplo.com"); await page.fill("#password", "claveValida"); await page.click("#entrar");
// Assert — observas y verificas contra el goal await expect(page).toHaveURL("/dashboard");});Preparar, actuar, verificar. Y si falla, ajustas y vuelves a correr. Eso es un loop con condición de parada. El patrón arrange-act-assert es más viejo que el término “vibe coding”, y describe la misma estructura que los agentes presentan como hallazgo. Para quien genera código con IA, ese ciclo es terreno nuevo; para ti es la forma del primer test que escribiste.
Y no se queda en el código. Tu proceso diario también es un loop: exploras la aplicación, algo te hace ruido, lo reproduces, lo reportas, esperas el fix y vuelves a verificar. Percibir, razonar, actuar, observar. La condición de parada es “el comportamiento ya coincide con lo esperado”. Corres ese ciclo sin nombrarlo desde el primer bug que reportaste.
Por qué esto te pone a ti en el centro
Hasta acá podría parecer un ejercicio de orgullo gremial: “lo nuestro es más viejo, ja”. No es eso. Entender que loop, goal y harness son conceptos de testing tiene una consecuencia práctica enorme para cómo trabajas con IA.
Cuando dirijas un agente —y lo vas a hacer cada vez más— vas a tener que decidir tres cosas: dónde vive el andamiaje, cuál es el criterio de éxito y dónde se detiene el ciclo. Esas tres decisiones son harness, goal y loop. Si crees que son tecnología ajena que recién estás aprendiendo, las vas a tomar con inseguridad. Si reconoces que son tu oficio, las tomas con autoridad.
La primera vez que me tocó armar una suite automatizada desde cero, nadie me dijo “estás construyendo un harness”. Me dijeron “automatiza esto”. Saqué el primer test rápido; lo que me costó semanas fue entender que el trabajo real era diseñar el armazón que iba a sostener los siguientes. El día que tuve el nombre del concepto, todo lo demás se ordenó solo. Por eso insisto con esto: el vocabulario no es decoración. Te da el mapa.
Cuándo este vocabulario te sirve de verdad
Sin humo significa también decirte cuándo esto es solo charla. Si tu trabajo de hoy es ejecutar un caso puntual y cerrarlo, no necesitas pensar en oráculos ni en loops: lo haces y listo.
El vocabulario empieza a pesar cuando subes de nivel: cuando armas un framework, cuando diriges agentes, cuando tienes que explicarle a tu equipo por qué la IA que se autoevalúa no es confiable, o por qué un test sin condición de parada clara es un test que nunca sabe si terminó. Ahí, tener los nombres correctos es la diferencia entre improvisar y diseñar.
Si todo esto te suena a “una cosa más que aprender”, respira: ya lo sabes. Lo hablé en No estás atrasado, estás saturado. No te falta conocimiento nuevo. Te falta reconocer que lo que la IA usa, tú lo inventaste.
Lo que quiero que te lleves
Loop, goal y harness no son la frontera de una tecnología que te dejó atrás. Son tres ideas que el testing viene puliendo desde mucho antes de que los agentes existieran, y que ahora vuelven con nombres en inglés y aire de novedad.
Reconocerlas hace dos cosas por ti. Te quita el miedo, porque dejas de sentir que llegas tarde a algo que en realidad empezó en tu casa. Y te da herramientas, porque cuando entiendes que dirigir IA es definir un harness, un goal y un loop, sabes exactamente qué decisiones te tocan.
La IA no te va a reemplazar con loop, goal y harness. Los inventaste tú. Te los devuelvo traducidos para que dirijas con ellos, no para que les tengas miedo.
Esta es la primera parada de una serie entera que hace una sola cosa distinta: explicar loop, goal y harness desde tu silla —la del QA— y no desde la del que programa. En la próxima agarramos el primero de los tres y lo desarmamos en serio: tu framework de tests es un harness, y por eso no sabes por dónde empezar cuando te dicen “armalo desde cero”. Vamos a ponerle piezas, nombres y un punto de partida concreto.