Los problemas de trabajar con agentes

Los agentes forman parte de mi trabajo diario, y precisamente por eso tengo una colección de sustos que no salen en las demos. Aquí van, ordenados de más grave a menos, con la regla que aplico ahora para cada uno.

Fue un martes de marzo de 2026. Le pedí a un agente, Claude Code trabajando en uno de mis servidores internos, que limpiara una carpeta de pruebas: borrar ficheros temporales de un proyecto que ya no usaba. Una tarea tonta. Me fui a por un café.

Cuando volví, había hecho exactamente lo que le pedí, pero no donde yo pensaba. La ruta que le di era relativa y él estaba situado un nivel más arriba, así que "limpió" también los ficheros temporales de otros dos proyectos, incluida una caché de datos que tardaba horas en regenerarse. Me di cuenta al día siguiente, cuando un proceso nocturno falló. Arreglarlo me costó unas cinco horas y un disgusto. Nada irreparable, porque había copia, pero esa tarde aprendí más que en un mes de vídeos.

Mi parte de culpa es la mayor: le había dado permiso para borrar sin preguntar porque "era una carpeta de pruebas".

Y aquí entra la promesa de los vídeos: "pon un agente a trabajar mientras duermes". Se puede. Pero conviene saber qué te puedes encontrar al despertar. Voy por partes: los problemas, lo que aprendí y lo que sí me aportan.

Un agente de inteligencia artificial es un programa que usa un modelo para hacer tareas por su cuenta, no solo para contestarte: abre archivos, ejecuta órdenes, busca en internet o envía correos, decidiendo él los pasos. El chat te dice cómo hacerlo; el agente lo hace.

Por eso el error no se queda en una respuesta: se queda en tus archivos.

Yo trabajo con agentes sobre todo con Claude Code y, desde hace poco, con OpenClaw, un agente de código abierto que se instala en tu propio equipo. No entro en detalle de cada herramienta; aquí lo que importa es lo que tienen en común.

Es el problema más serio, y el más tonto, porque te lo haces tú solo.

Los agentes piden permiso antes de las acciones delicadas. Al principio lees cada petición con atención. A la vigésima ya estás pulsando "sí, permitir siempre" para que te deje en paz. Y cada "siempre" se queda guardado.

Un día, revisando la configuración de uno de mis agentes, descubrí que tenía permiso permanente para ejecutar cualquier orden en la terminal, escribir en todas las carpetas de mi usuario y conectarse por SSH, que es el acceso remoto, a tres de mis servidores. Yo no recordaba haberle dado nada de eso. Se lo había dado, claro, de uno en uno, con prisa. Contando todo, tenía acceso a bastante más de lo que yo mismo uso en un día normal.

La regla que aplico ahora tiene cuatro partes:

• Trabajo en carpetas de pruebas, no en las de verdad, hasta que la tarea está clara.
• Uso cuentas con permisos limitados: el agente no entra con mi usuario principal.
• Nada irreversible sin confirmación: borrar, enviar o pagar siempre me lo pregunta, aunque me canse.
• Control de versiones en todo lo que toca, que es un historial donde cada cambio queda guardado y se puede deshacer.

Y una vez al mes reviso los permisos guardados y quito los que sobran.

El agente te dice "hecho" con una seguridad que ya quisiera yo para mis cosas. Y a veces no lo está.

Le pedí a un agente que actualizara las dependencias de un proyecto y comprobara que todo seguía funcionando. Me devolvió un resumen precioso: dependencias actualizadas, pruebas superadas. Al revisar, las pruebas no se habían llegado a ejecutar porque faltaba una configuración; el agente vio el error, lo interpretó como "no hay pruebas que fallen" y siguió adelante.

¿Por qué pasa? Porque el modelo que hay detrás está entrenado para dar respuestas que parezcan buenas, y un resumen optimista parece muy bueno. No miente a propósito; simplemente, no distingue bien entre "lo he hecho" y "creo que lo he hecho". Y cuanto más larga es la tarea, más fácil es que se le pierda un paso por el camino.

La regla: no me fío del resumen final. Compruebo el resultado yo, o le pido que me enseñe la prueba de que funciona: la salida real de las pruebas, el fichero cambiado, la página cargando. Si no puede enseñármelo, no está hecho.

Un agente consulta al modelo muchas más veces que un chat. Cada paso que piensa, cada fichero que lee y cada comprobación es una consulta más, y cada consulta cuenta.

Mi susto con la factura: en abril de 2026 dejé un agente conectado por API a un modelo de pago revisando documentación durante un fin de semana; se quedó atascado en un bucle, leyendo y releyendo los mismos ficheros, y el lunes me encontré un consumo de unos 90 euros en algo que debía costar menos de 10. La API, por cierto, es el acceso de pago por uso que utilizan los programas para hablar con el modelo, distinto de la suscripción del chat.

Aquí sale siempre la pregunta de si hay agentes de inteligencia artificial gratis. La carcasa puede serlo: hay agentes de código abierto, como OpenClaw, que no cuestan licencia. Pero el modelo que piensa por él no es gratis, salvo que lo pongas tú en local, con tu máquina, tu luz y tus horas. Y los modelos que caben en casa suelen quedarse cortos en tareas largas.

La regla: límite de gasto en la API desde el primer día, antes de lanzar nada. Y revisar el consumo cada lunes por la mañana, cinco minutos.

Dos problemas que se parecen: lo que falla sin avisar y lo que el agente decide sin preguntar porque le pareció buena idea.

El error silencioso: un agente que cada noche recopilaba datos de un servicio externo y los dejaba en una hoja para un cliente. El servicio cambió el formato de su respuesta, el agente siguió funcionando sin quejarse y durante días guardó filas vacías. Tardé once días en darme cuenta, y fue porque el cliente me preguntó por qué los gráficos se habían quedado planos.

La decisión por su cuenta: le pedí a un agente que corrigiera un fallo en un formulario de una web y, de paso, "mejoró" los textos de la página, cambió el orden de dos secciones y renombró un fichero que usaba otro proceso. Se lo agradezco a medias. Tardé dos días en relacionar el fichero renombrado con otro fallo.

Una automatización que falla en silencio es peor que no tenerla, porque te da una tranquilidad que no merece. Sin ella, al menos sabes que tienes que mirar.

La regla: registros de todo lo que hace, instrucciones explícitas sobre lo que no debe decidir solo ("no cambies nada que no te haya pedido") y una revisión periódica, aunque todo parezca ir bien. Sobre todo si todo parece ir bien.

No quiero hacer caricatura. Si los agentes forman parte de mi trabajo diario, es por algo.

Hoy delego con buenos resultados la revisión semanal de mis servidores: el agente comprueba espacio en disco, actualizaciones pendientes y errores en los registros, y me deja un resumen. También la preparación de borradores de documentación técnica para clientes a partir de su código y la migración de pequeñas webs y scripts entre servidores. Calculo que me ahorran entre seis y ocho horas a la semana.

Así que, para qué sirve un agente de inteligencia artificial de verdad: para lo repetitivo y para lo que tiene pasos claros. No para lo que tiene consecuencias difíciles de deshacer, como pagar, borrar o escribir a clientes sin supervisión. Y tampoco para encargos vagos: si tú no sabes explicar la tarea, él tampoco sabrá hacerla.

Recojo aquí las reglas de cada apartado, para quien quiera empezar sin llevarse mis sustos:

1. Empieza en una carpeta de pruebas.
2. Dale los permisos mínimos y revísalos cada cierto tiempo.
3. Ten copias o control de versiones de todo lo que toque.
4. Pon un límite de gasto en la API antes de lanzar nada.
5. Comprueba el resultado; no te fíes del resumen.
6. No le dejes solo pagos, borrados ni mensajes a clientes.

No es una lista brillante. Es la que me habría ahorrado unas cuantas tardes y algún euro.

Sigo equivocándome, que conste. La diferencia es que ahora los sustos son más pequeños y los veo antes. Si quieres ver cómo me va con el agente más nuevo que estoy probando, lo cuento en He empezado a jugar con OpenClaw.