Cuando confié demasiado en la IA y me falló: 3 lecciones que pagué con horas de sueño

El día que Hermes me dejó tirado y yo tan tranquilo

Era un martes cualquiera. Me desperté, cogí el móvil para revisar Telegram y vi algo raro: llevaba 7 horas sin recibir notificaciones de La Frontera IA. Ni un solo mensaje del bot. Ni alertas de publicación. Ni el resumen matutino.

Lo primero que pensé fue «bah, estará en mantenimiento». Pero no. El gateway de Hermes se había caído a las 3:17 de la madrugada y llevaba medio día sin procesar nada. Los crons seguían ejecutándose. Los artículos se estaban generando y guardando en disco. Pero nadie se enteraba de nada porque el gateway que conecta todo —Telegram, los webhooks, las notificaciones— simplemente había muerto en silencio.

Me costó 45 minutos diagnosticarlo. Tuve que meterme por SSH al Raspberry Pi 5 que tengo en casa corriendo todo el tinglado, revisar los logs del sistema, ver que Hermes Agent estaba corriendo pero el daemon de mensajería se había quedado zombie. Un systemctl restart hermes-gateway y todo volvió a la vida.

¿La lección? No puedes confiar en que «la IA se encarga». Necesitas monitorización externa. Ahora tengo un healthcheck cada 5 minutos desde UptimeRobot apuntando al endpoint de estado del gateway. Si no responde en 60 segundos, me llega un push al móvil. 7 horas a ciegas no me vuelven a pasar.

El bug del href="" que me rompió la homepage entera

Esta duele contarla. Estaba montando el sistema de publicación automática y le pedí al modelo que generara el JavaScript del index.html. Le di el JSON de artículos, le expliqué la estructura de tarjetas, el hero, las secciones. El código compilaba, se veía bien en el navegador, y yo —confiado— lo desplegué a producción.

Dos días después, Google Search Console me escupe 312 errores 404. ¿El motivo? El template JS había generado todas las URLs como href="". Vacías. Las tarjetas de la homepage eran botones muertos sin link. El hero no tenía imagen porque src="" también estaba vacío. Todo se veía bien visualmente, pero ningún enlace funcionaba.

El problema era una simple interpolación de variables en el template literal de JavaScript. El modelo había escrito ${a.slug} pero como el objeto no se cargaba bien en ese scope, devolvía cadenas vacías. Lo acepté sin revisar porque «si la IA lo generó, estará bien». Error de novato con todas las letras.

Arreglarlo me llevó 3 horas entre debuggear, reescribir el template, regenerar el index.html estático con Python y volver a desplegar. Desde entonces, tengo un check post-deploy automático:

grep -c 'href=""' /var/www/lafronteraia/index.html  # debe ser 0
grep -c 'src="" class="lfi-hero-bg"' /var/www/lafronteraia/index.html  # debe ser 0

Si cualquiera de los dos da más de 0, el deploy se aborta automáticamente. La IA escribe el código, pero el que firma soy yo.

Cuando le pedí a la IA que «arreglara el JSON» y dejó 8 artículos huérfanos

Esta es de las que te hacen replantearte todo. Tenía que hacer una migración masiva del archivo articles-data.json: pasar todos los artículos viejos al nuevo formato con campos bilingües (image/imagen, title/titulo, excerpt/description). Unos 88 artículos en total.

En vez de escribir un script de migración yo mismo —que me habría llevado 20 minutos—, le pasé el JSON entero al modelo y le dije: «normalízame esto, añade los campos que faltan». El modelo me devolvió el archivo perfectamente formateado. Lo sobrescribí, desplegué, y de repente: 8 artículos habían desaparecido de la web.

¿Qué pasó? El modelo, en su afán de «normalizar», había puesto "slug": null en 8 entradas cuyos títulos no encajaban con su heurística de generación de slugs. Sin slug, el archivo HTML existía en disco pero no había forma de enlazarlo. Esos artículos —con contenido, imagen, todo— simplemente eran invisibles.

Tardé 2 horas en darme cuenta. Otras 2 en recuperar los slugs correctos cruzando títulos con los archivos .html que había en /data/articles/. Y otros 30 minutos en escribir un script que validara la integridad del JSON antes de cada deploy.

Ahora, antes de cualquier modificación del JSON de artículos, se ejecuta automáticamente:

python3 -c "
import json
d = json.load(open('/var/www/lafronteraia/data/articles-data.json'))
null_slugs = [a.get('title','')[:60] for a in d if not a.get('slug') or a.get('slug')=='None']
if null_slugs:
    print(f'ABORTADO: {len(null_slugs)} slugs nulos')
    exit(1)
print(f'OK: {len(d)} artículos, 0 slugs nulos')
"

No vuelvo a dejar que una IA edite un archivo de datos de producción sin validación.

Lo que aprendí (y lo que me costó)

Sumando: 7 horas de gateway caído + 3 horas debugueando el JS + 4 horas recuperando slugs = 14 horas perdidas. Todo por delegar sin verificar. La IA no es el problema — el problema es tratarla como si fuera un ingeniero senior que nunca se equivoca.

Las tres reglas que ahora sigo a rajatabla:

1. Monitorización externa siempre. Si tu sistema depende de un proceso que no tiene healthcheck, ese proceso no existe. UptimeRobot, healthchecks.io, o un simple cron que haga ping. Lo que sea, pero que no dependa de lo mismo que monitoriza.
2. Validación automatizada post-IA. Cada vez que un modelo genera código o datos, hay un script que valida el output antes del deploy. Sin excepciones. Si falla, el deploy se aborta y me llega una alerta.
3. La IA sugiere, yo decido. Suena obvio, pero es fácil olvidarlo cuando llevas 3 horas trabajando y el modelo te escupe una solución que «parece correcta». Si no entiendo exactamente qué hace cada línea, no se despliega.

El SSD NVMe Kingston de 1TB que uso para el almacenamiento ha sido un héroe silencioso en todo esto — los logs de 88 artículos más todas las imágenes no caben en una SD, y la velocidad de lectura ha salvado más de un diagnóstico a las 2 de la mañana.

No digo que no uses IA. La uso a diario para todo. Digo que no te creas que es infalible. Porque el día que se rompa algo —y se romperá—, el que va a estar a las 3 AM mirando logs eres tú, no el modelo.