De prompts a agentes: cómo armé mi propio equipo de IA para QA
Tabla de contenidos
En mi guía anterior compartí los prompts que uso como QA en cada momento del día: cuando analizo un ticket, cuando planifico tests, cuando investigo un fallo, cuando reporto resultados.
Funcionó. Funcionó muy bien. Hasta que dejó de alcanzar.
No porque los prompts fueran malos. Sino porque mi flujo de trabajo creció y el modelo de «yo escribo, la IA responde» empezó a tener un techo que no podía ignorar.
Este artículo es la historia de cómo pasé de pedirle cosas a la IA a que trabaje conmigo. Con roles definidos, contexto compartido, y tareas que se ejecutan sin que yo copie y pegue nada.
No necesitas ser dev para entender esto. No necesitas saber programar agentes. Solo necesitas entender los conceptos y decidir cuándo aplicarlos.
El techo del prompt
Si usas IA con prompts, tarde o temprano vas a sentir estas fricciones:
Ninguno de estos problemas se resuelve con un mejor prompt. Se resuelven cambiando el modelo de interacción.
Ahí es donde entran los agentes.
Agente vs. prompt: la diferencia que nadie te explicó bien
Con un prompt:
- Abres la IA
- Escribes: «Eres QA Senior. Analiza esta historia de usuario…»
- Copias la historia del ticket y la pegas
- Lees el resultado
- Copias el resultado
- Escribes otro prompt: «Ahora genera test cases priorizados…»
- Pegas el análisis anterior
- Lees los test cases
- Quieres generar los tests automatizados pero la IA no tiene acceso a tu código
- Copias los test cases, abres tu editor, y los escribes tú
Funciona. Pero cada paso depende de ti.
Con un agente:
- Le dices: «Analiza la historia #47 y genera el plan de pruebas»
- El agente lee la historia directamente del ticket
- Analiza ambigüedades, identifica riesgos, genera preguntas
- Genera test cases priorizados por impacto
- Te devuelve todo estructurado, en el formato que ya le definiste una vez
La diferencia no es de inteligencia. Es de autonomía. Un prompt es una pregunta. Un agente es un colaborador con instrucciones permanentes, acceso a tus herramientas, y un rol definido.
Subagentes: cuando un agente necesita ayuda
Imagina que tienes un agente que analiza historias de usuario. Hace bien su trabajo. Pero un día le pides que además genere los tests, los ejecute, detecte cuáles fallan, y te dé un reporte.
¿Qué pasa? Se satura. Mezcla contextos. Es como pedirle a una sola persona que haga el trabajo de cinco.
La solución: subagentes. Agentes especializados que trabajan bajo la coordinación de un agente principal.
Piénsalo como un equipo de QA:
El Analista — desmenúza la historia de usuario
Recibe la historia de usuario y la desmenúza. Encuentra ambigüedades, identifica riesgos, genera las preguntas que le harías al PO. Solo hace eso. No escribe tests, no ejecuta nada.
El Planificador — genera el plan de pruebas
Toma el análisis del Analista y genera el plan de pruebas. Prioriza por riesgo, agrupa escenarios, define qué va primero. Solo planifica.
El Generador — escribe los tests automatizados
Toma el plan del Planificador y escribe los tests automatizados. Conoce tu framework, tus Page Objects, tus convenciones de código. Solo genera código.
El Sanador — diagnostica y repara tests rotos
Revisa los tests que fallan. Analiza si el fallo es del test o de la aplicación. Si es del test, lo repara. Si es de la aplicación, lo reporta. Solo diagnostica y repara.
El Cazador — busca flaky tests
Busca tests que pasan y fallan intermitentemente. Analiza patrones, identifica causas (timeouts, datos compartidos, race conditions), y sugiere correcciones. Solo caza flakiness.
Cada subagente trabaja en su propio contexto. No se contamina con el trabajo de los otros. Y el agente principal los coordina.
Es exactamente como funciona un equipo de QA real. Solo que algunos de esos roles ahora los puede ejecutar la IA — si le das las instrucciones correctas.
¿Por qué no un solo agente grande? Por la misma razón que no tienes un solo QA haciendo todo: la especialización mejora la calidad. Además, cada subagente tiene su propio espacio limpio de contexto — no se satura con logs de los otros.
Skills: tu caja de herramientas personalizada
Si los agentes son tus colaboradores y los subagentes son especialistas, los skills son las herramientas que invocas con un solo comando.
Un skill es un prompt complejo con instrucciones detalladas, empaquetado para que lo invoques rápido. En vez de escribir 20 líneas de contexto cada vez, defines el skill una vez y después solo lo llamas.
Los skills no hacen algo que no puedas hacer con un prompt. Eliminan la fricción de tener que formularlo cada vez. Y esa fricción es lo que hace que muchos QAs dejen de usar la IA después de la primera semana.
Mi setup real
No voy a nombrar herramientas específicas porque lo que importa es la filosofía. Mi flujo tiene estos roles definidos:
| Rol | Cuándo lo uso | Qué hace | Qué NO hace |
|---|---|---|---|
| El Analista | Ticket nuevo | Análisis de riesgos, ambigüedades, preguntas para PO | No genera tests ni código |
| El Planificador | Después del análisis | Plan de pruebas priorizado por riesgo | No ejecuta nada |
| El Generador | Plan aprobado | Estructura de tests automatizados con tu framework | No inventa selectores |
| El Sanador | Test que falla | Debug, diagnóstico, sugerencia de corrección | No aplica cambios sin aprobación |
| El Cazador | Sospecha de flakiness | Historial de ejecuciones, clasificación de causa | No arregla automáticamente |
Lo que conecta todo: El output del Analista es el input del Planificador. El output del Planificador es el input del Generador. Si el Generador produce un test que falla, el Sanador lo recibe.
Yo no copio y pego entre ellos. El flujo está conectado. Yo solo intervengo en los puntos de decisión.
Pasé de ser la persona que ejecuta cada paso a ser la persona que valida cada resultado.
Los límites honestos
- Agentes que generaron tests para funcionalidades que no existen en la aplicación - Diagnosticaron un test como flaky cuando en realidad el bug era real - Crearon Page Objects duplicados porque no “recordaban” los existentes - Me dieron un análisis de riesgo perfecto… de la historia equivocada
Cuándo es mejor un prompt simple
Si necesitas algo rápido, puntual, y de una sola vez — un prompt es mejor. Preguntar «¿Qué significa este error?» no requiere un subagente especializado.
Mi regla: Si la tarea la voy a hacer una sola vez, uso un prompt. Si la voy a hacer todos los días o todas las semanas, defino un skill o un agente.
El costo de setup
Configurar un flujo de agentes toma tiempo. No es plug and play. Es una inversión que se paga con el tiempo, pero la primera semana vas a sentir que estás gastando más tiempo configurando que trabajando.
Si solo usas IA de vez en cuando, probablemente no necesitas agentes. Si la usas todos los días para las mismas tareas, la inversión vale la pena.
Por dónde empezar
Paso 1: Identifica tu tarea más repetitiva. Ese es tu primer candidato para un skill.
Paso 2: Define un solo agente — el Analista. Úsalo dos semanas antes de agregar otro.
Paso 3: Agrega el Planificador. Ahora tienes un flujo de dos pasos sin copiar y pegar.
Paso 4: Experimenta con subagentes para tareas pesadas (Sanador, Cazador).
Paso 5: Itera. Vas a ajustar instrucciones. Vas a descubrir que menos responsabilidad = mejor resultado.
La progresión completa
Si seguiste esta serie, el camino fue:
| Paso | Contenido | Nivel |
|---|---|---|
| 1 | 5 cosas que la IA hace mejor que yo en QA | Entender qué puede y qué no |
| 2 | IA para QA: guía práctica | Los 6 momentos del día + prompts reales |
| 3 | Este artículo | Pasar de prompts a agentes y subagentes |
La progresión es: qué puede → cuándo usarla → cómo escalar.
Y en cada paso, lo que no cambió fue lo más importante: tu criterio como QA. La IA multiplica lo que ya sabes. Los agentes multiplican la multiplicación. Pero el punto de partida siempre eres tú.
Lo que quiero que te lleves
No necesitas agentes para empezar a usar IA como QA. Los prompts funcionan y funcionan bien. Pero si ya los estás usando todos los días y sientes la fricción — la repetición, el copiar y pegar, el tener que dar contexto cada vez — entonces los agentes son tu siguiente paso natural.
No es un salto tecnológico. Es un cambio de modelo: de «yo le pido, ella responde» a «yo defino roles, ella ejecuta, yo valido».
La mejor configuración de agentes no es la más sofisticada. Es la que se ajusta a cómo tú ya trabajas. No cambies tu flujo para adaptarte a la IA. Adapta la IA a tu flujo.