Cómo convertir un crash de producción en un pull request sin dejar que la telemetría escriba código por reflejo

Paso 1 — Normaliza el incidente antes de llamar al agente. Extrae fingerprint, versión, entorno, stack trace, frecuencia, primer y último evento y enlaces a release o commit. Redacta secretos, tokens, emails y payloads que no sean necesarios. Crea un incidentid y guarda la consulta original para auditoría. No envíes todos los logs por defecto. El objetivo es construir un paquete mínimo que permita empezar la investigación sin transformar observabilidad en un canal masivo de datos hacia el agente. Añade un nivel de severidad que determinará permisos y revisión del workflow.

Paso 2 — Localiza código y formula una hipótesis reproducible. El agente busca símbolos y cambios relacionados, pero no escribe todavía. Pide que identifique condiciones necesarias para el fallo y proponga una reproducción. Si existe un test que puede fallar de la misma forma, créalo en una rama aislada y ejecútalo. Cuando la reproducción no sea posible, registra la incertidumbre y limita el siguiente paso a una propuesta de investigación o instrumentación. Un stack trace orienta; no demuestra causalidad por sí solo. Esta regla evita parches plausibles que esconden el síntoma sin resolver la causa.

Paso 3 — Genera el fix como diff y ejecuta validadores. Una vez que existe evidencia suficiente, permite escritura en una rama temporal. El agente propone un cambio pequeño, ejecuta tests afectados, análisis estático y la reproducción. Registra qué validator pasó o falló. Si el diff cruza límites inesperados, sube el riesgo y exige revisión adicional. No dejes que el sistema modifique directamente la rama principal por haber identificado un crash. El objetivo del agente es acelerar el camino a una corrección revisable, no sustituir el control de cambios que protege producción.

Paso 4 — Construye el pull request desde evidencia. El PR debe enlazar incidentid, síntoma, reproducción, cambio propuesto, tests y riesgos conocidos. Genera un título y resumen claros, pero evita afirmar “resuelto” antes del deploy. Asigna revisores según ownership y severidad. Si la corrección cambia permisos, datos o infraestructura, aplica políticas específicas. La integración con observabilidad aporta valor porque evita que el contexto se pierda entre ticket y código; conserva la cadena que permite a un revisor entender de dónde nació el cambio sin leer una conversación completa del agente.

Paso 5 — Verifica después del despliegue. Una vez fusionado y desplegado, observa el fingerprint original durante una ventana definida. Compara tasa del error, versión y nuevos síntomas. Si desaparece, marca el incidente como mitigado o cerrado según política; si persiste, reabre y vincula el nuevo intento. También monitoriza regresiones cercanas. Un PR aceptado no es un outcome. El loop termina cuando la señal operacional confirma el cambio o cuando una persona decide que la evidencia disponible es suficiente. Esta diferencia evita dashboards donde muchos “fixes” se cuentan como éxito sin comprobar producción.

Paso 6 — Aprende del historial sin automatizar ciegamente. Agrupa incidentes por causa, componente y tipo de fix. Si el mismo patrón reaparece, mejora librerías, linters o tests en lugar de pedir al agente el mismo parche cada vez. En Goatify, el patrón puede generalizarse: cualquier alerta debe poder originar una propuesta reversible y luego comprobar su efecto. El producto gana memoria operacional: señal, decisión, cambio y resultado. Esa estructura permite aumentar autonomía progresivamente solo en clases de incidentes donde existe evidencia de que el workflow produce correcciones confiables y fáciles de revertir. También facilita revisar excepciones y aprender por componente sin mezclar problemas de naturaleza distinta.