Código

Código es donde le pides a Status200 AI que trabaje en tus repositorios, como se lo pedirías a un agente de programación: corregir un bug, escribir tests, explicar el código, hacer un cambio. Se abre en el cuadro donde pides, con el repositorio y la rama elegidos en él y todas las tareas debajo; la página de una tarea es una conversación en la que puedes responder. Status200 también inicia tareas por su cuenta, a partir de excepciones, trazas e investigaciones. Un Runner clona el repositorio, escribe el cambio en una rama nueva, lo compila y lo prueba, y abre un pull request. Una persona revisa y fusiona cada uno: el Runner puede subir ramas y abrir pull requests, nada más.

Pedirle a la IA en un repositorio#

1. Abre Código#

   Abre Productos → Código. Se abre en ¿Qué debe hacer la IA?: el cuadro donde pides, con todas las tareas debajo, las más recientes primero. Si todavía no hay ningún repositorio, ofrece en su lugar Conectar GitHub (consulta Antes de empezar). Repositorios, en su menú lateral, muestra los repositorios en los que la IA puede trabajar, y agrupa bajo No conectado los que la GitHub App ya no alcanza. La página de cada repositorio tiene el mismo cuadro para ese repositorio.

2. Elige el repositorio y la rama#

   El cuadro empieza en el repositorio que elegiste la última vez. Elige otro en su fila inferior y, al lado, la rama de la que parte la tarea: la rama principal del repositorio, marcada como Predeterminado, hasta que elijas otra. La IA crea su rama a partir de la que elijas y abre su pull request hacia ella.

3. Di lo que quieres#

   Escribe el cambio, el bug o la pregunta con tus propias palabras. Mientras no se haya pedido nada, Código sugiere algunas en Prueba a pedir.

4. Añade contexto#

   Haz clic en Añadir contexto para darle a la IA lo que necesita: un archivo o una carpeta del repositorio, una nota, un enlace o un registro del proyecto. Status200 lee cada registro al enviar la petición, con tus permisos, y guarda lo que recibió la IA.

5. Inicia la tarea#

   Haz clic en Iniciar tarea o pulsa Intro. Se abre la página de la tarea, y el trabajo de la IA aparece ahí a medida que ocurre.

Una petición lleva como máximo 10 elementos de contexto. Los tokens, claves, contraseñas y direcciones de correo en lo que lee Status200 se ocultan antes de que la IA los vea, como en todos los sitios donde Status200 AI lee tus datos.

La conversación de una tarea#

La página de una tarea es una conversación: lo que se pidió y el contexto añadido, y luego el turno de la IA: los pasos que da a medida que los da (los archivos que leyó y editó, lo que buscó, los comandos que ejecutó), su respuesta, los archivos que cambió con su diff, y el pull request. La parte de arriba de la página dice dónde trabaja la tarea (su repositorio y la rama de la que partió), cuántas líneas cambió, con un botón a su pull request, y cómo va la tarea:

Para seguir, escribe en el cuadro de abajo, que sigue a la vista mientras la conversación se desplaza: responde a la IA, añade contexto o pide cambios. Cada respuesta es el siguiente turno de la misma tarea: trabaja en la misma rama y sube al mismo pull request mientras siga abierto. Una tarea hace un turno cada vez, así que el cuadro espera mientras la IA trabaja. El Registro de cada turno es la constancia literal de lo que hizo.

Quien puede leer un repositorio lee sus tareas. Pedirle algo a la IA, responder y detener una tarea requieren permiso para editar el repositorio, y también ver el diff de un cambio: los demás ven qué archivos cambiaron. Las tareas que Status200 inicia por su cuenta (abajo) también están en su repositorio, como conversaciones en las que puedes responder.

Cómo funciona una ejecución de corrección#

1. Haces clic en Iniciar tarea en Código, o en Corregir con IA en una excepción sin resolver, u otro botón o disparador inicia una tarea (consulta Dónde empiezan las tareas de corrección).
2. La tarea se pone en cola en su repositorio, y el Runner que elige el repositorio la toma: uno de tus Runners, o un Runner global cuando no elige ninguno (consulta Elige el Runner del repositorio).
3. El Runner obtiene el contexto de la tarea. Para una petición, son sus palabras, el contexto añadido y la conversación hasta ahora; para una excepción, su tipo, su mensaje y su stack trace.
4. Clona el repositorio en un espacio de trabajo propio y crea una rama. Una corrección de una excepción se llama oneuptime-fix-exception- seguido de los primeros caracteres del id de la ejecución. Una petición parte de la rama elegida cuando se hizo, y su pull request se abre hacia ella. Una respuesta trabaja, en cambio, en la rama del pull request abierto de la tarea.
5. Un agente de código, impulsado por el proveedor de LLM de tu proyecto, lee el código y escribe el cambio. El servidor de Status200 hace las llamadas al LLM, así que el Runner nunca tiene la clave de API de tu proveedor, y cada llamada se mide y aparece en los registros de IA. Una corrección de una excepción, de una traza lenta o de un incidente también lee datos de producción mientras trabaja: las excepciones, las trazas, los logs y las métricas de los servicios del repositorio (consulta Telemetría de producción en una corrección).
6. En un Runner propio, el agente de código compila y prueba su cambio como indica el AGENTS.md del repositorio antes de hacer ningún commit, y repara lo que falla (consulta Verificación antes del pull request).
7. El Runner hace el commit, sube la rama, abre el pull request (para una petición, solo si cambió código) y borra el espacio de trabajo.

La página desde la que se inició la tarea muestra su estado en directo. Cada tarea aparece en su repositorio, en Productos → Código: su página es su conversación, y el Registro de cada turno tiene una línea por cada archivo que el Runner leyó o escribió y por cada comando que ejecutó.

Cada ejecución está sujeta a presupuestos que impone el servidor: como máximo 40 llamadas al LLM y 100.000 tokens de salida. Las consultas de telemetría de producción de una ejecución se descuentan de esas mismas 40 llamadas. Una ejecución que llega a uno de ellos termina con un resumen del trabajo hecho hasta entonces en lugar de entrar en bucle. Las ejecuciones de corrección también cuentan para los límites diarios de IA del proyecto, cuando el proyecto los fija.

Dónde empiezan las tareas de corrección#

Estos botones solo aparecen donde pueden iniciar una tarea. Con la IA desactivada para el proyecto, no aparece ninguno y el menú lateral de una excepción no tiene Asistencia de IA. Mejorar los registros y Mejorar el trazado aparecen en cuanto hay un repositorio conectado, y Acelerar con IA solo en una traza que vale la pena corregir (consulte Explorador de trazas). El botón Corregir con IA de una función solo aparece en el código propio de la aplicación que ocupa al menos el 5 % del tiempo o la memoria del perfil, o cuya proporción creció 3 puntos o más desde la ventana con la que se compara (consulta Perfilado continuo).

Para abrir la página Asistencia de IA de una excepción, abre la excepción en Productos → Observabilidad → Excepciones y elige Asistencia de IA en su menú lateral. Una excepción resuelta o archivada tiene que marcarse primero como no resuelta.

Status200 AI también inicia tareas de corrección por su cuenta: a partir de una investigación que encuentra un cambio de código, de una que termina sin conclusión porque faltaba telemetría, y de los AI Insights sobre excepciones y trazas lentas. Cada una tiene su propio interruptor; consulta Correcciones de código automáticas.

Telemetría de producción en una corrección#

Status200 ya recoge lo que hace tu código en producción, así que una corrección no tiene por qué basarse solo en un stack trace. Mientras el agente de código trabaja, puede consultar la telemetría de producción de los servicios del repositorio:

La descripción del pull request dice qué consultó el agente y qué encontró. Las demás tareas, como las pruebas de regresión y las mejoras de los registros o del trazado, no consultan producción.

Lo que el agente puede leer lo decide el servidor de Status200, a partir de la propia tarea:

• Solo lectura. Las consultas se ejecutan en el servidor de Status200, nunca en el Runner, que no tiene ninguna credencial que lea telemetría. Nada de lo que hacen puede cambiar tu proyecto.
• Este proyecto, y solo los servicios de este repositorio. No los asignas tú: son los servicios para los que Status200 encuentra este repositorio, del mismo modo que encuentra el repositorio de una corrección - los stack traces de sus excepciones pasan por sus archivos, se llaman como él o es el único repositorio del proyecto. No se puede leer la telemetría de otro servicio.
• Sin incidentes privados, y los tokens, claves, contraseñas y direcciones de correo se ocultan antes de que el agente vea un resultado, como en todos los sitios donde Status200 AI lee tus datos.
• Acotado. Como máximo 12 consultas por ejecución, y cada una se descuenta de las 40 llamadas de la ejecución.

Cuando ningún servicio corresponde al repositorio, la tarea se ejecuta sin telemetría de producción, como antes.

Revisión de producción de pull requests#

Status200 sabe lo que hace tu código en producción, así que puede revisar una pull request con lo que nadie ve al leer el diff. Activa Revisar pull requests frente a producción, en Más ajustes de la página Ajustes de un repositorio en Código, y cada pull request que alguien con acceso de escritura abre o actualiza recibe un comentario que dice lo que producción muestra del código que cambia. El comentario se edita en su sitio con cada push, y la página Revisiones de producción del repositorio en Código guarda cada revisión, con Volver a revisar.

Cuando producción dice algo, Status200 AI lo lee junto al diff y añade Qué vigilar: unos pocos puntos breves, cada uno basado en los datos. Solo se ejecuta mientras la IA está activada en el proyecto, como mucho 10 veces al día por pull request y 100 por repositorio, y se mide como cualquier llamada de IA; los datos se leen siempre sin ella. Cuando producción no muestra nada del cambio, Status200 no publica nada.

• Solo agregados. El comentario contiene recuentos, duraciones y nombres de código: nunca el mensaje de una excepción, una línea de registro, el título de un incidente ni datos personales.
• Los repositorios públicos reciben un enlace. Cualquiera puede leer las pull requests de un repositorio público, así que allí el comentario solo enlaza a la revisión en Status200, que solo los miembros del proyecto pueden abrir. Comentario de revisión de producción, en Más ajustes de la página Ajustes del repositorio, puede publicar Solo un enlace a la revisión en todos, o La revisión, incluso en un repositorio público.
• Los colaboradores externos no pueden iniciar una. Una pull request se revisa sola solo cuando su autor, y quien haya hecho push en ella, pueden escribir en el repositorio. La de cualquier otra persona - un colaborador externo, un fork, un bot - se revisa cuando alguien con acceso de escritura comenta @oneuptime production review en ella, o pulsa Volver a revisar en Código.
• Solo lectura. Una revisión no clona nada ni ejecuta nada de la pull request. Su diff y su título son datos para Status200 AI, nunca instrucciones: la IA no tiene herramientas, y lo que escribe se coloca en el comentario como texto.

El interruptor está activado para los repositorios que la GitHub App conecte a partir de ahora. Un repositorio conectado antes de que existiera lo mantiene desactivado hasta que lo actives.

Verificación antes del pull request#

Un repositorio dice cómo se compila y se prueba en un AGENTS.md en su raíz, el archivo que leen los agentes de código. Antes de cambiar nada, el agente de código lee el AGENTS.md del repositorio (o su CLAUDE.md, cuando no tiene AGENTS.md) de la rama de la que parte la tarea, y trabaja como indica. Sin ninguno de los dos, lo averigua a partir del CONTRIBUTING.md del repositorio, el README, los scripts del paquete, el Makefile o los flujos de CI. No hay nada que configurar en Status200.

Nada de un pull request que viene de un fork se lee nunca como instrucciones del repositorio: una revisión rechaza ese pull request, y una reseña lee la rama base.

Comandos definidos en un repositorio#

Código ya no pide comandos de configuración, compilación y prueba, pero un repositorio que los tiene, definidos antes o mediante la API o Terraform, los conserva. Se muestran de solo lectura en la tarjeta Comandos de compilación y prueba, en Más ajustes de la página Ajustes del repositorio, y Eliminar comandos elimina los tres. Mientras alguno esté definido, cada ejecución de corrección en un Runner propio también comprueba su cambio con ellos antes de que se abra el pull request:

1. Cuando el agente de código termina, los comandos se ejecutan en orden en la raíz del repositorio, en el Runner, en el espacio de trabajo clonado. Cada uno tiene hasta 15 minutos y se ejecuta con CI=true, para que nada espere una respuesta; el primer fallo detiene la pasada.
2. Ante un fallo, el final de la salida del comando fallido vuelve al mismo agente de código como tarea de reparación, con instrucciones de corregir su propio cambio en lugar de debilitar u omitir pruebas, y los comandos se ejecutan de nuevo. Hace como máximo 2 intentos de reparación. Comparten el presupuesto de LLM de la ejecución, y sus cambios van en el mismo commit que la corrección.
3. El resultado, superado, fallido u omitido (sin comandos definidos, o un Runner global), se escribe en una sección Verification de la descripción del pull request y se registra en el pull request de la tarea.

Un cambio que sigue sin superar la verificación no se descarta: el pull request se abre de todos modos, con una sección "Verification failed" claramente marcada que nombra el comando fallido y termina con su salida. El trabajo se conserva y quien revisa decide. Un repositorio sin comandos definidos se informa como omitido, en lugar de dar a entender una compilación en verde.

Los comandos son ajustes del repositorio que escribe tu equipo y que se ejecutan en tu propio Runner: el mismo modelo de confianza que los pasos de Bash de un runbook. La IA nunca los escribe ni los cambia. Un Runner global, que Status200 ejecuta para todos los proyectos, nunca los ejecuta: en un Runner global, la corrección se escribe y se abre para revisión, la verificación se informa como omitida y la CI propia de tu repositorio comprueba el cambio. Ejecuta un Runner propio para que las correcciones se compilen y prueben antes de que se abra el pull request.

Después de fusionar una corrección#

Fusionar una corrección no corrige nada hasta que se ejecuta. En cuanto se fusiona un pull request de corrección, Status200 espera un despliegue registrado que lo contenga (consulta Despliegues y cambios) y vigila en ese despliegue aquello para lo que era la corrección. El pull request de la tarea en Code dice cómo fue, y también la página Asistencia de IA de la excepción, los registros de IA del incidente y el insight de IA del que salió la corrección:

Hasta que un despliegue la entrega, la corrección indica Fusionado, esperando un despliegue, y luego Desplegado, en observación en producción mientras se vigila. Una que ningún despliegue registrado contiene en 14 días, o de la que la producción no puede decir nada, indica No verificado en producción. Correcciones de código automáticas recoge las reglas. Una prueba de regresión, un mejor manejo de errores, una revisión y una solicitud en Code no se vigilan: la producción no puede mostrar lo que cambian.

Antes de empezar#

Una tarea necesita tres cosas. El cuadro de peticiones de Código y la página Asistencia de IA de la excepción comprueban las tres antes de ofrecer empezar, y dicen qué falta.

En una instancia autoalojada, el proveedor global es un bloque de config.env (Docker Compose) o de tus valores de Helm. Para un Ollama autoalojado:

GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.

Cualquier proveedor compatible sirve: consulta Proveedores de LLM para verlos todos y cada variable de entorno.

No asignas repositorios a servicios. Cuando una tarea empieza, Status200 encuentra el repositorio comparando las rutas de archivo del stack trace de la excepción con tus repositorios conectados. Si nada coincide, recurre a un repositorio que se llame como el servicio, y después al único repositorio del proyecto cuando solo hay uno. La página Asistencia de IA muestra qué repositorio encontró.

Elige el Runner del repositorio#

Cada repositorio elige el Runner en el que la IA trabaja en él: en su página Ajustes en Código, abre Más ajustes, haz clic en Editar en la tarjeta Runner y elige uno. Un repositorio que importa la GitHub App empieza en el Runner predeterminado del proyecto, cuando lo tiene. Un repositorio que no elige ninguno trabaja en Runner global, que Status200 ejecuta para todos los proyectos.

Solo el Runner que elige un repositorio recibe sus tareas y un token para él. En un proyecto que desactiva Usar Runners globales en Runbooks → Agentes de runbook, cada repositorio necesita uno de los Runners propios del proyecto. La página de un Runner lista los repositorios que lo eligen.

Ejecuta un Runner propio#

Para ejecutar un Runner en otro lugar, por ejemplo en una máquina cerca de tus repositorios:

1. Crea el Runner#

   Crea un Runner en Runbooks → Agentes de runbook y haz clic en Mostrar instrucciones de configuración en su fila. El comando incluye la clave secreta del Runner, que solo un Project Owner, Project Admin o Runbook Admin puede leer. Tiene este aspecto:

   Bash

   docker run --name status200-runner --restart unless-stopped \
     -e STATUS200_RUNNER_ID=<runner-id> \
     -e STATUS200_RUNNER_KEY=<runner-key> \
     -e STATUS200_URL=<your-status200-url> \
     -d status200/runner:release

2. Elígelo para el repositorio#

   En la página Ajustes del repositorio en Código, abre Más ajustes, haz clic en Editar en la tarjeta Runner y elige el Runner. El Runner recoge el cambio con su siguiente heartbeat, en aproximadamente un minuto; no hay nada que reiniciar.

3. Comprueba que se conecta#

   El Runner aparece como conectado en la página Runbooks → Agentes de runbook en uno o dos minutos. Si no, lee el log del contenedor (docker logs status200-runner) en busca de un error de credenciales o de red.

Cualquier forma de ejecutar el contenedor sirve (Docker Compose, Kubernetes, etc.), siempre que tenga estas variables y pueda llegar a tu instancia de Status200 por HTTPS:

Correcciones de código automáticas a partir de investigaciones#

Cuando una investigación de IA publica un análisis de causa raíz en un incidente o una alerta, y su clasificación cuidadosa recomienda un cambio en el código, la tarjeta de la investigación ofrece Abrir PR de corrección a partir de este análisis: una tarea de corrección cuyo contexto entero es el análisis publicado. El botón se oculta cuando el remedio es operativo, solo de infraestructura, externo, una denegación esperada, un error del usuario o no concluyente. Las correcciones aptas ocurren sin el clic mientras Corregir automáticamente los incidentes nuevos está activado en Incidentes → IA → Ajustes (y Corregir automáticamente las alertas nuevas en Alertas → IA → Ajustes). La corrección empieza desactivada, también en los proyectos nuevos. Sin reglas de IA se abre cada corrección apta; con reglas, solo una para lo que coincide con una regla, cuando la regla tiene Pull requests de corrección activado (una regla nueva lo tiene), en los repositorios de código que nombra.

Mientras la corrección está activada, una investigación que termina con una causa raíz segura y respaldada por pruebas que un cambio de código puede corregir pone en cola la misma tarea de corrección que crea el botón. La decisión es una clasificación acotada que comprueba el servidor, nunca un patrón buscado en el texto del análisis: solo un veredicto positivo de corrección de código abre un pull request. La falta de pruebas, un remedio fuera del código y una clasificación fallida terminan todos sin hacer nada.

Todo lo demás coincide con el botón:

• El pull request se abre listo para revisión, escrito a partir del análisis publicado, y necesita un repositorio conectado mediante la GitHub App, uno de los que nombran las reglas que coinciden cuando nombran alguno, y un Runner en línea para trabajar en él: el que elige el repositorio, o un Runner global.
• Cuenta para el límite diario de tareas de corrección de esa señal (Límite diario de tareas de corrección de IA para incidentes o Límite diario de tareas de corrección de IA para alertas, en Más ajustes de su página de ajustes de IA) y para el tope de pull requests abiertos del repositorio, cuando alguno está definido. Sin definir, ninguno limita nada.
• Cada disparador busca primero una tarea de corrección ya en cola o en ejecución para el mismo incidente o la misma alerta, así que un disparador automático y un clic normalmente se convierten en una tarea, no en dos pull requests. La comprobación es una lectura antes de la escritura, no un bloqueo, así que dos disparadores en el mismo instante aún pueden pasar los dos.
• La ejecución la escribe el sistema, no se atribuye a nadie, y nada se fusiona solo.

Cuando una corrección falla#

Privacidad#

El clon de tu repositorio vive en un espacio de trabajo dentro del contenedor del Runner y se borra cuando termina la ejecución, tanto si salió bien como si no. El Runner nunca tiene la clave de API de tu proveedor de LLM: el servidor de Status200 hace las llamadas al LLM por él, y también ejecuta las consultas de telemetría de producción. Status200 no conserva tu repositorio ni entrena con tu código. El registro de la tarea guarda los primeros 300 caracteres de la salida de cada paso, para que puedas comprobar lo que hizo el Runner, y eso puede incluir fragmentos de código. Ejecuta un Runner autoalojado con tu propio proveedor de LLM (Ollama local incluido) y tu código nunca sale de tu infraestructura.

En la hoja de ruta#

Previsto, y todavía no disponible:

• Compatibilidad con GitLab. Los repositorios se conectan solo mediante la GitHub App.

Próximos pasos#