Errores arreglados por agentes, revisados por personas
Cada error que tiene nuestra plataforma en producción se convierte en una tarea en el proyecto correcto. Un agente de programación averigua la causa, el tamaño y la gravedad, lo arregla en una copia aparte del código y propone el cambio. Los arreglos pequeños y seguros entran solos cuando pasan todas las comprobaciones; lo delicado o grande espera a un revisor con nombre.
El 12 de octubre de 2026, cada uno a partir de un error visto en producción.
De código, en 3 archivos como mucho, con prueba y todas las comprobaciones superadas.
Si aparecen errores nuevos en ese tiempo, se pausa la fusión automática en el proyecto.
Desde el 12 de octubre de 2026. Antes, cada 5 minutos.
La mayoría de los errores nunca tiran una web. Van y vienen, y aun así afectan a quien usa el software. Hay que detectar cada uno, encontrar su causa, arreglarlo y comprobarlo, y esa cola crece más rápido de lo que un equipo pequeño la vacía.
Nuestra monitorización ya los detectaba. Lo lento era todo lo de después: leer el error, encontrar el código, escribir el arreglo y probarlo. Queríamos que esa parte la hicieran agentes, y que las decisiones con riesgo siguieran en manos de personas.
Lo construimos en Desk, la plataforma con la que funciona SEIRO, y lo probamos primero en el propio Desk.
Paso a paso.
- 01
Un error en producción se convierte en una tarea en el proyecto al que pertenece. Cuando entra el arreglo, la tarea se cierra y el error queda resuelto.
- 02
Un agente de programación en la nube lo evalúa primero, sin tocar el código: la causa probable, los archivos implicados, el tamaño, la gravedad y su grado de confianza. El resultado queda en la tarea.
- 03
Si la evaluación lo permite, el agente prepara el arreglo en su propia rama, una copia aparte del código, añade una prueba para el fallo y propone el cambio para revisión.
- 04
Un arreglo entra solo únicamente si es pequeño (como mucho 30 líneas de código en 3 archivos), no toca ninguna zona delicada, incluye una prueba y pasa todas las comprobaciones obligatorias. Los cambios en dinero, acceso, permisos, datos o despliegue siempre pasan por una persona.
- 05
Los cambios grandes, la baja confianza y los intentos fallidos van al revisor con nombre del proyecto, con una vista previa del arreglo funcionando cuando el proyecto la tiene. Un arreglo fallido tiene antes un segundo intento.
- 06
Si aparecen errores nuevos en las 6 horas siguientes a que entre un cambio de un agente, la fusión automática se pausa en ese proyecto hasta que una persona la reanuda.
- 07
Además, las webs que cuidamos se comprueban cada 60 segundos: si cada página responde, su certificado de seguridad, la caducidad del dominio y su velocidad. Cuando una web se cae, el email de aviso incluye un diagnóstico de IA de la causa probable.
Con qué está hecho Monitorización de errores · Tablero de tareas en Desk · Agentes en la nube de Cursor · Revisión de código y comprobaciones automáticas · Comprobaciones de disponibilidad cada 60 segundos · Diagnóstico de caídas con IA
Los primeros arreglos fueron pequeños y reales: páginas y procesos en segundo plano que fallaban en situaciones que nadie había probado. Cada uno salió de un error que nuestra plataforma había tenido en producción.
Evaluar antes de escribir código compensa. En uno de los primeros errores, la evaluación tardó unos 3 minutos y calificó el arreglo como grande, con confianza baja, así que esperó a una persona en lugar de adivinar.
Lo que es delicado depende del proyecto. Una lista fija se quedaba corta, así que cada proyecto tiene la suya, además de unas zonas que siempre revisa una persona.
Lo que decidimos.
Adoptado en nuestra plataforma desde el 12 de octubre de 2026. Los proyectos de clientes son lo siguiente, con las mismas reglas: arreglos solo durante el desarrollo, la garantía o un plan de mantenimiento, y cada proyecto con su propio revisor.
Los agentes que evalúan y arreglan errores sirven para cualquier software que funcione en producción y tenga pruebas. En tus sistemas, puede significar:
- Los errores de tu app convertidos en tareas con causa probable y tamaño antes de que nadie abra el código.
- Arreglos pequeños propuestos con una prueba que demuestra que el fallo ha desaparecido.
- Una persona con nombre aprueba todo lo que toca dinero, datos o el acceso.
- Tu web comprobada cada minuto, con un diagnóstico de IA en cada aviso de caída.
- Los cambios en zonas delicadas nunca entran solos. Siempre los revisa una persona.
- Cada ejecución tiene un límite de tiempo y de coste. Si lo alcanza, se para y pasa a una persona.
- Solo los errores que llegan a la monitorización se convierten en tareas. Los fallos que nadie ha provocado siguen necesitando pruebas y personas.
- De momento los arreglos funcionan en nuestra plataforma. Los proyectos de clientes son lo siguiente.
Llevarlo a proyectos de clientes y medir la precisión y el coste de la evaluación durante el primer mes, para ajustar qué puede entrar solo.
¿Puede un agente de IA arreglar solo fallos en producción?
Los pequeños, dentro de unos límites. Un arreglo entra sin una persona solo si es pequeño, tiene una prueba, pasa todas las comprobaciones y no toca nada delicado. Todo lo demás se propone para que lo apruebe un revisor con nombre.
¿Y si el arreglo de un agente empeora las cosas?
Si aparecen errores nuevos en las 6 horas siguientes a que entre el cambio de un agente, la fusión automática se para en ese proyecto hasta que una persona lo revisa y la reanuda.
¿En qué se diferencia de la web que volvió en 9 minutos?
Aquel agente trabaja en servidores: caídas, actualizaciones y ajustes. Estos agentes trabajan en el código de una app, arreglan los errores que hay detrás y proponen el cambio para revisión.