Cómo usamos agentes de IA para arreglar bugs en producción.

Casi todas las agencias de nuestro mercado venden la IA como entregable: un chatbot, un asistente, una automatización. Muy pocas cuentan si la IA toca su propia forma de entregar. En Polargate sí, de una manera concreta y bastante aburrida. Esta página describe el sistema que usamos y sus números, incluidas las partes que no funcionan.

Qué pasa cuando entra un ticket

Polargate lleva el mantenimiento de sus clientes en un ServiceDesk multi-tenant, en producción desde el 17 de julio de 2026. Un cliente escribe un correo o abre un ticket en su portal. A partir de ahí:

• El correo entra por nuestro dominio de soporte, con comprobaciones de DKIM y DMARC y tokens firmados en la respuesta, de forma que la contestación del cliente se engancha a su ticket y a ningún otro.
• Un agente de triaje lo clasifica: qué tipo de cambio es, qué repositorio toca, cuánto riesgo tiene y cuántas horas debería consumir. Este paso corre sobre un modelo grande y cuesta unos 0,05 USD por ticket.
• Si el ticket es candidato a automatizarse, se lanza un trabajo de arreglo como ejecución de GitHub Actions dentro del repositorio de ese cliente. El worker es un único flujo canónico en nuestro repositorio, y cada repositorio de cliente lleva un stub de quince líneas que lo llama. El agente trabaja con la CLI de Claude Code y un tope duro de 80 turnos.
• El trabajo devuelve un diff por un callback y se para. Espera.
• Un ingeniero senior revisa ese diff en Mission Control, nuestra consola interna: aprobar, pedir que replanifique, ajustar la estimación de horas o de riesgo, redactar una respuesta para el cliente o cancelarlo todo.
• El cambio lo integra y lo despliega una persona, con las puertas de siempre: typecheck, tests, build y mirar la página real en escritorio y en un móvil de 375 píxeles.

Las horas consumidas se descuentan del contrato del cliente, que tiene dos bolsas, mantenimiento y urgencias, y el sobrante se convierte en mejoras proactivas en vez de evaporarse. El cliente ve su plan, su consumo y sus facturas en el portal. Nunca ve nuestra base de conocimiento interna: esa regla de acceso está en la base de datos, no en un documento de políticas.

Un ticket, dos ejecutores

Cada ticket se puede cerrar de dos formas: por el carril automático, que gasta crédito de API, o a mano por un ingeniero senior trabajando en Claude Code, que no gasta nada porque va dentro de una suscripción que ya existe. En la práctica, los cambios pequeños y bien acotados van por el carril automático, y todo lo que exige criterio sobre el negocio del cliente va a mano.

Auditorías en paralelo y un escéptico para cada hallazgo

El trabajo de construcción usa otro bucle. Escrito el cambio, abrimos en abanico agentes de auditoría por dimensión: corrección, arquitectura y reutilización, interfaz y guías de plataforma, accesibilidad, comportamiento responsive, rendimiento y seguridad, incluidas las políticas a nivel de fila. Después, cada hallazgo en bruto pasa a otro agente cuyo único trabajo es refutarlo.

Esa pasada de refutación no es adorno. Números de nuestras ejecuciones:

• Investigación de un fallo de push en Android: 14 agentes, 20 hallazgos en bruto, 8 verificados y ninguno sobrevivió al contacto con el código. La causa real estaba en otro sitio.
• Web de un club de golf, dos rondas antes de integrar: 37 en bruto y 4 confirmados, luego 26 y 3.
• Web de un hotel en agosto de 2026: 55 agentes en 6 áreas, 48 hallazgos, 48 confirmados y 0 refutados, todos corregidos.
• Plataforma interna de operaciones: una auditoría de 74 agentes dio 59 hallazgos confirmados, corregidos con un abanico de 11 agentes.
• Una app móvil offline-first necesitó 11 rondas de auditoría, con hallazgos de 42, 28, 9, 15, 11 y 4.

De esa tabla salen dos lecciones. La salida en bruto de los agentes tiene una tasa alta de falsos positivos, así que el paso de refutación es lo que la hace utilizable. La tasa de confirmación varía muchísimo, de 48 sobre 48 en un código a 4 sobre 37 en otro. Una ejecución que confirma casi todo suele significar que ese código no se había auditado nunca.

La regla de parada son dos pasadas limpias seguidas con cero bloqueantes. "Verificado" significa build, typecheck y tests en verde más la interfaz abierta en el navegador, porque las puertas verdes mienten: un tsconfig cuya raíz no incluía ningún fichero dio a un proyecto un typecheck aprobado durante meses, y dos despliegues salieron en verde pasando por un lint que nunca devolvía código de error.

La base de conocimiento que hay debajo

Un agente vale lo que vale su contexto. Polargate mantiene una base de conocimiento por entidad en Postgres: fragmentos de texto con embeddings e índice HNSW, con alcance por entidad y proyecto, una biblioteca global compartida que entra en todas las búsquedas y un muro entre lo del cliente, lo interno y lo personal. Nuestras propias herramientas llegan a ella por un servidor MCP con más de 100 herramientas: lectura y escritura de conocimiento, tickets, saldos de horas, facturas, contactos, releases y la cola de arreglos.

En la práctica, el agente de triaje ya conoce el stack del cliente, las decisiones tomadas y lo que se rompió la última vez. También significa que el modo de fallo habitual es de conocimiento, no de modelo: cuando una propuesta de arreglo vuelve mal, casi siempre es porque faltaba un dato en la base.

Cuánto cuesta un arreglo

• Triaje: unos 0,05 USD por ticket.
• El primer arreglo real de principio a fin por esta tubería, sobre el portal de un cliente en julio de 2026, costó 0,31 USD de modelo.
• Infraestructura del worker: cero. Minutos de GitHub Actions en repositorios que ya pagamos. Valoramos un servidor dedicado y lo descartamos: sobredimensionado para una o dos tareas por semana.
• Hay un tope de gasto diario en la base de datos. Cuando se alcanza, el carril se para.

El gasto de modelo por arreglo son céntimos. Es el titular y también el número menos interesante, porque el coste que importa es el tiempo de revisión senior, y ese no baja a cero. Alguien que entiende qué rompe el negocio del cliente sigue teniendo que leer el diff. Lo que quita el agente es la redacción: leer el código, reproducir el problema, escribir la primera versión, preparar la respuesta. Eso es lo que hace viable la calidad senior en una cuota mensual, donde el mismo trabajo sin agentes costaría más o acabaría en manos de perfiles júnior.

Lo que los agentes no pueden hacer

Estos límites están soldados en la base de datos, no escritos en un prompt:

• Nunca responden a un cliente por su cuenta. Todo mensaje que sale hacia el cliente lo revisa y lo envía una persona.
• Nunca despliegan. Ningún agente tiene credenciales de producción.
• Nunca superan el tope de gasto diario.
• Nunca ejecutan migraciones destructivas ni tocan autenticación, roles o secretos.

La frontera general: lo reversible lo decide el agente, lo irreversible se para y pregunta. Una persona revisa e integra todos los cambios. Esa regla es lo que permite apuntar este sistema al repositorio de producción de un cliente.

Si estás pensando en montar algo así

• Empieza por la mesa de tickets, no por el agente. Sin sistema de tickets ni contabilidad de horas, la automatización no tiene dónde engancharse.
• Construye el refutador antes de fiarte del auditor.
• Pon los topes en datos, no en prompts. Un prompt es una sugerencia, una restricción en base de datos no.
• Mide tus falsos verdes. Una puerta de verificación que no puede fallar es peor que no tener puerta.
• Presupuesta bien la revisión humana: ahora es la parte cara, y es por la que paga el cliente.

Polargate trabaja así en las cuotas mensuales de Care, y los proyectos nuevos empiezan con un Discovery Sprint de precio cerrado.