Blind Burn: Qué Pasa Cuando la IA Construye Más Rápido de Lo Que Puedes Rastrear
El otro día intenté hacer una lista de todo lo que está ejecutándose en mis servidores. No porque algo se hubiera roto. Solo para saberlo.
No pude.
Hay crontabs en las máquinas VPS. Flujos programados en n8n. Jobs de pg_cron en Supabase que se disparan cada seis horas. Funciones programadas en Convex que configuré en febrero y no he vuelto a pensar en ellas. GitHub Actions que se activan con eventos que apenas recuerdo haber definido. Llamadas a APIs que salen cada hora hacia servicios de los que ni siquiera estoy seguro de necesitar todavía. Todo construido con Claude Code. Todo funcionando perfectamente.
Y yo, el tipo que construyó el avión, incapaz de decirte qué hay en la bodega de carga.
Hace dos semanas, Addy Osmani (el ingeniero de Google detrás de Chrome DevTools, Lighthouse y Core Web Vitals) le puso nombre a algo parecido a esto. Lo llamó deuda de comprensión: la brecha creciente entre lo que contiene tu código base y lo que cualquier humano realmente entiende. Su artículo se viralizó. Ese habla sobre código. Este habla sobre lo que está ejecutándose. Porque la deuda de código se queda en tu repo esperando. La versión de infraestructura no espera. Te cobra por hora. Yo lo llamo quema ciega.
TLDR: La IA te permite construir y automatizar 100x más rápido. Tu comprensión de lo que realmente se está ejecutando no puede seguir el ritmo. Este artículo nombra el problema (quema ciega), muestra lo que cuesta, y te da 4 reglas para dejar de volar a ciegas.
La IA Construye Rápido. Tu Mapa No Se Actualiza.
Claude Code es absurdamente bueno construyendo cosas. Le describes un flujo de trabajo, construye el flujo de trabajo. Le pides un cron job, obtienes un cron job. Dices "automatiza la sincronización del feed de distribuidores" y veinte minutos después hay un pipeline programado que obtiene, transforma y envía datos de productos a tres canales de distribución.
Funciona. Sigues adelante. Esa es la trampa.
Cada "constrúyeme un flujo de trabajo" añade una tarea programada que olvidarás en tres semanas. Cada "añade un cron para la actualización de inventario" es otra línea en un crontab que no volverás a leer. Convertí Claude Code en mi arquitecto de n8n hace unos meses. Cada flujo que construyó (buenos, sólidos) añadió triggers programados a un laberinto que ya no estaba mapeando.
Y me sentí productivo todo el tiempo. Esa es la parte que te atrapa. No estás holgazaneando. Estás entregando. Estás construyendo cosas reales que funcionan en producción. Solo que también estás creando un cementerio de timers, triggers y entradas de cron que nadie volverá a revisar jamás.
Admítelo, haces lo mismo.
Para ser claro: la herramienta no es el problema. Claude Code hace exactamente lo que le pides, y lo hace bien. El problema soy yo no manteniendo un mapa. Y no mantuve uno porque cuando estás construyendo a velocidad 100x, la cartografía se siente como pérdida de tiempo.
No lo es.
Lo Que Realmente Cuesta la Quema Ciega
El concepto de Osmani es preciso. Los equipos envían código generado por IA más rápido de lo que cualquiera puede leerlo. Las pruebas pasan, los PRs se ven limpios, y la brecha entre "desplegado" y "entendido" crece en silencio.
Pero la deuda de código es perezosa. Se queda en tu repo siendo fea e inerte, esperando a que alguien la toque. La versión de infraestructura tiene un medidor corriendo.
Cada cron job huérfano es una micro-factura. Cada timer de API olvidado es ancho de banda en tu tarjeta. Cada función programada disparándose hacia un servicio que deprecaste el mes pasado es cómputo facturado mientras duermes. Eso es quema ciega. No se anuncia. Se acumula, como una suscripción que olvidaste cancelar, excepto que son cuarenta de ellas.
Las señales están empezando a aparecer. @cmd_alt_ecs en X, hace unas semanas: más de 60 cron jobs, $50 al día yendo a agentes que ya no hacen nada útil. @Tahseen_Rahman: 15 crons autónomos ejecutándose durante dos meses, el cuello de botella se volvió auto-reparador a las 3 AM. @aleks_blanche, quizás el comentario más certero: "sin un plano de control, no tienes agentes. Tienes deuda de automatización."
Osmani habla sobre equipos empresariales con docenas de ingenieros. Mi escala es indie: una persona, unas pocas cajas VPS. Pero el mecanismo es idéntico. La velocidad de producción supera la velocidad de comprensión. ¿La diferencia? En una empresa, alguien eventualmente lo detecta. Cuando trabajas solo, nadie audita tu desastre por ti.
El Monitoreo Responde la Pregunta Equivocada
Así que configuras Cronitor. O Better Stack. O Healthchecks.io. Bien por ti. Ahora sabes si un job se ejecutó.
Todavía no sabes si debería existir.
Es como tener un recibo de cada compra que hiciste el año pasado pero no tener idea de si todavía usas algo de eso. El monitoreo rastrea la ejecución. Lo que necesitas es visibilidad del propósito. Si el job todavía tiene sentido. Si duplica algo más. Si la API que llama siquiera devuelve datos útiles o solo 200 OKs a un endpoint que nadie mantiene.
Esa pregunta ("¿debería existir este job?") requiere contexto que solo tú tienes. O tenías, hace seis meses, antes de enviar catorce automatizaciones más y dejar de pensar en ello.
Ningún SaaS te responderá eso.
Lo Que Construí Para Volver a Ver Mi Propio Stack de Ecommerce
Así que construí un panel de control. No un SaaS. No un proyecto secundario para ProductHunt. Una herramienta de supervivencia, para un pipeline de WooCommerce que se salió de control porque Claude Code es demasiado bueno en su trabajo.
Lo primero que me da: una vista de calendario semanal de cada job programado en todos los sistemas. No una lista en terminal. Una grilla visual mostrando qué se dispara cuándo, codificado por colores según el tipo (indexación de productos, sincronización de feeds de distribuidores, monitoreo de precios, reconciliación de órdenes, actualizaciones de inventario, llamadas a APIs de socios). Un vistazo y veo los problemas. El bloque de las 4 PM donde seis jobs de sindicación pelean por la misma cuota de API. El cluster del jueves por la mañana que ya no tiene sentido porque maté la fuente de datos upstream hace dos meses. El hueco del martes donde nada se ejecuta entre las 8 y las 14, que o está bien o es un trigger roto que nunca noté.
Lo segundo: un rastreador de costos de API. Cada llamada externa, cada proveedor, cada dólar. El mes pasado: $14.46 total en 598 llamadas de API en tres proveedores. No es un número aterrador. Pero el valor no está en el total. El valor está en ver que un proveedor se come el 68% del presupuesto para una tarea que podría manejar localmente. Y detectarlo antes de que se desvíe, no después.
Ahora piensa en el tipo de los $50 al día. Escala diferente, misma ceguera. Sus jobs no empezaron caros. Se acumularon. Sin un dashboard, $2 se convierte en $10 se convierte en $50 y nunca ves la curva porque no hay curva que mirar. Solo un estado de cuenta de tarjeta de crédito al final del mes y una sensación vaga de que algo anda mal.
Tuve esa sensación durante semanas antes de construir el panel. Mi esposa lo habría llamado intuición. Yo lo llamo mirar mi factura de Hetzner con un ojo cerrado, como revisar tu peso después de Navidad. 😬
Nadie vende comprensión de TU sistema. Tienes que construirla tú mismo.
El Framework de Torre de Control: Cuatro Reglas Para Dejar de Volar a Ciegas
Después de limpiar mi propio desastre, destilé el enfoque en cuatro principios.
Regla 1: Inventariar todo en un lugar. Crontabs en VPS. Flujos programados de n8n. pg_cron de Supabase. Funciones programadas de Convex. GitHub Actions. Timers a nivel de aplicación. Todo, una lista. Un job que no está en tu inventario no existe para ti. Pero existe para tu factura. Y tu factura tiene mejor memoria que tú.
Regla 2: Visualizar por tiempo, no por herramienta. Una lista de cron jobs por máquina es inútil para detectar problemas. Necesitas un calendario semanal mostrando CUÁNDO se disparan las cosas, no una tabla de DÓNDE viven. El tiempo es el eje que revela colisiones, huecos y zombis. Las herramientas no colisionan entre sí. Los horarios sí.
Regla 3: Rastrear costo por job, aunque sea aproximado. ¿Cuántas llamadas de API dispara este job? ¿Cuánto cómputo consume? Si no puedes estimar lo que cuesta un job, no puedes decidir si vale la pena ejecutarlo. El número no necesita ser preciso. Necesita existir. Cero visibilidad es como $2/día se convierte en $50.
Regla 4: Auditar trimestralmente. Tres preguntas por job. ¿Todavía se ejecuta? ¿Todavía sirve un propósito? ¿Puede alguien (o sea, tú) explicar por qué se creó? Un "no" y el job es un zombi. Mátalo. Los crons muertos no envían facturas.
La misma disciplina de especificación primero que aplico al código con contratos de prompt (define el contrato antes de dejar que la IA ejecute) funciona para infraestructura. Especifica qué debería ejecutarse. Rastrea qué se ejecuta. Compara los dos.
Tu infraestructura merece el mismo rigor que tu código base.
Probablemente más. Es la parte que te cobra dinero.
El Próximo Cuello de Botella No Es Construir, Es Entender Lo Que Ya Construiste
El próximo año, todos tendrán Claude Code. Todos sabrán cómo automatizar. Y empezaremos a escuchar sobre los primeros burnouts de IA. No humanos. De infraestructura. Las quemas ciegas.
La próxima ventaja competitiva no será construir más rápido. Será entender lo que ya construiste.
La IA te dio los superpoderes de construcción. Los de comprensión dependen de ti.
Fuentes
Addy Osmani, Comprehension Debt: The Hidden Cost of AI-Generated Code (Medium, March 2026)
(*) La portada es generada por IA. Los servidores en la imagen se entienden mejor a sí mismos de lo que yo entiendo los míos.