Cómo detecté un bug silencioso
que estaba quemando 1.500€ en ads
y lo resolví en menos de una hora con IA

El problema que no suena una alarma

Hace un mes, una de nuestras plataformas de SaaS generaba 150-200 conversiones confirmadas diarias. Luego bajó a 40.

Nadie lo veía como crítico. Las métricas de tráfico seguían bien. Los clics en los anuncios no bajaban. El servicio de pagos informaba que cobraba correctamente. Lo único que faltaba era que los clientes recibieran lo que habían pagado.

Esto es lo peligroso de los bugs silenciosos: no se rompen de forma ruidosa. No lanzan un error en Sentry. No disparan un webhook de fallo. Se filtran como agua. Un responsable de marketing propuso simplemente aumentar presupuesto en ads. Casi invertimos otros 800€ para ampliar reach a clientes que desaparecerían después de una semana sin acceso.

El root cause: alguien había actualizado la API de Stripe sin actualizar los parámetros que enviábamos. El webhook seguía recibiendo eventos. Stripe seguía cobrando. Pero las credenciales nunca se generaban. Los clientes recibían el cargo y luego, silencio.

Diagnóstico en 15 minutos con Claude Code

En lugar de hacer análisis manual, abrí Claude Code y describí el comportamiento: conversiones que caían, pero el servicio parecía funcionar. Le pedí que analizara los logs disponibles sin presuponer qué estaba roto.

Esto es lo que pasó en los primeros 15 minutos.

1. Claude Code accedió a los logs de webhooks de Stripe. No había errores. Los eventos se recibían.
2. Analizó las llamadas posteriores a la API de generación de credenciales. Faltaban.
3. Comparó la estructura de los datos enviados a Stripe (actuales) con la que el manejador de webhooks esperaba (obsoletos).
4. Encontró que payment_intent_id se había renombrado en la API de Stripe. El webhook lo buscaba con el nombre antiguo, no lo encontraba, y fallaba silenciosamente.

Solución en 45 minutos, en producción

Una vez identificado el problema, la solución era trivial: mapear el nuevo nombre de parámetro en el handler del webhook. Pero antes de tocar producción, necesitaba:

1. Entender la lógica completa del webhook (no solo la línea que fallaba)
2. Verificar que no hubiera otras referencias al parámetro antiguo
3. Crear una retroactividad: procesar los pagos que entraron en los últimos 30 días sin credenciales generadas
4. Hacer un despliegue sin downtime

Claude Code ejecutó todo esto en paralelo usando n8n como orquestador. El workflow automático:

• ✓ Hizo el cambio en el handler de webhooks
• ✓ Desplegó a staging y validó contra datos históricos
• ✓ Creó un job de retroactividad para 160 clientes pendientes
• ✓ Desplegó a producción con rollback automático si algo fallaba
• ✓ Ejecutó la retroactividad de forma incremental (100 clientes/minuto) para no sobrecargar la base de datos

En 45 minutos, 160 clientes que llevaban semanas sin acceso recibieron sus credenciales. Las métricas volvieron a 180+ conversiones netas al día en la próxima ejecución de la campaña. El bug estaba muerto.

El coste real y la lección

Sin intervención: habríamos gastado otros 800-1.000€ en ads para compensar conversiones que nunca llegarían. El mes siguiente sería peor.

Con intervención: 15 minutos de análisis + 45 minutos de desarrollo + despliegue automático. El tiempo que habría tomado manualmente: 2-3 días de un ingeniero senior analizando logs a mano.

Costo ahorrado: no solo los 1.500€ de ads sin retorno, sino el tiempo de ingeniería que típicamente cuesta 300-500€/hora en overhead operacional.

La pregunta que importa: ¿cuántos bugs similares están quemando dinero en tu operación ahora mismo? ¿Cuántas métricas bajan un 30% pero no disparan alarmas porque no son errores, solo degradación silenciosa?

Esto es lo que significa tener IA en producción. No es automata haciendo tareas. Es un detector que entiende el contexto lo suficientemente bien como para preguntar "¿por qué esto que debería ocurrir no está ocurriendo?" en lugar de "¿por qué esto se rompe?".