Poner en cuarentena un test válido es cómo se lanza un bug
Los tests que a veces fallan se ponen en cuarentena, y durante esa cuarentena se encuentran defectos genuinos. Un test que falla una de cada veinte corridas podría estar mal escrito, o podría estar exponiendo una condición de carrera que tarde o temprano afectará a un cliente.
Un test inestable suele fallar con independencia del código que cubre, en ciertos horarios, en commits específicos, en runners particulares y de una forma distinta cada vez. Un defecto intermitente genuino está atado a algo: un cambio, un patrón de carga o un orden.
Cada error tiene un costo. Si pones en cuarentena el test que está atrapando un defecto real, el defecto se lanza. Si persigues un test que de verdad es inestable, el ingeniero pierde una semana.
El agent investiga y enuncia una posición con base en su evidencia. No desactiva ni pone en cuarentena nada. El equipo que posee el test toma la decisión final.
Cómo se construye el agent en Agent Studio
La entrada principal del agent es el historial de corridas, guardado en PostgreSQL y recuperado como registros completos de fallo, no como tasas, porque las tasas ocultarían los patrones que responden la pregunta.
Los prompt skills listan las inestabilidades conocidas de la infraestructura: componentes comunes, un proceso que corre más lento y una integración que tiene un límite de tasa, para que esas causas ambientales no necesiten una investigación nueva cada trimestre.
El system prompt exige que cada posición enunciada incluya evidencia que podría contradecirla. La interpretación alternativa solo se sostiene bajo condiciones enunciadas. El agent debe decir si los datos descartan esa alternativa.
Si la evidencia es delgada, el agent no decide. Si el historial no basta, lo dice, y nombra qué resolvería la pregunta.
Un flujo Start Scheduled reúne los candidatos. El nodo Agent Chat recibe el registro de fallo, más los commits y los metadatos del runner de cada ocurrencia.
Un nodo GitHub entrega el código fuente del test y sus cambios más recientes, porque un fallo de test después de la edición más reciente sería, de otro modo, un problema por completo distinto.
Los resultados van a Linear como una sola entrada por cada test, con el argumento pertinente. Un nodo Human in the Loop deja al equipo dueño entre el hallazgo y cualquier cuarentena.
De qué está hecho este agent
- PostgreSQL (Data): el registro completo de fallos, no una tasa de inestabilidad.
- Prompt skills: las inestabilidades conocidas de tu infraestructura.
- System prompt: una posición enunciada con su evidencia en contra.
- System prompt: la evidencia delgada se reporta como delgada, con lo que la resolvería.
- Agent Chat (Util): registro de fallo más commits y metadatos del runner por ocurrencia.
- GitHub (Integration): el código fuente propio del test y sus cambios recientes.
- Cuando un ActionFlow basta: Si solo necesitas fallos agrupados por firma y separados en nuevos frente a recurrentes, construye el flujo de trabajo. Ese flujo de trabajo produce los candidatos en primer lugar.
Preguntas frecuentes
Empieza a crear flujos de IA
Crea una cuenta gratuita, abre una plantilla o un lienzo en blanco y ejecuta tu primer ActionFlow.
Boletín
Recibe actualizaciones del producto
Nodos nuevos, agents y notas de producto. Solo enviamos correo cuando merece la pena abrirlo.