El LLM no volverá mañana por su cuenta

6 min de lectura

Un modelo no tiene asuntos pendientes

El modelo había encontrado un problema.

Mencionó el riesgo en el séptimo párrafo. La persona leyó la respuesta por encima, aprovechó la recomendación y siguió adelante. Nadie creó una tarea, modificó una prueba ni programó una revisión.

A la mañana siguiente no pasó nada.

No había ningún proceso en marcha para comprobar el riesgo. La respuesta había terminado y el sistema no tenía ningún seguimiento que ejecutar. Buena parte de la fantasía actual de sustituir personas depende de pasar por alto ese pequeño detalle.

La pregunta contiene trabajo invisible

¿Por qué este cliente sigue reabriendo incidencias que parecían resueltas? ¿Por qué cada cambio que afecta a la facturación tarda tres veces más de lo estimado? ¿Por qué el software supera todas las pruebas mientras los desarrolladores con experiencia siguen desconfiando de la versión?

Alguien detectó una contradicción entre la versión oficial y la realidad vivida, y la delimitó lo suficiente para investigarla. La pregunta parece sencilla porque la experiencia condensó la complejidad antes de que el modelo llegara a verla.

Tomar una respuesta rápida como prueba de que quien pregunta sobra es como despedir al médico porque el laboratorio entregó pronto los resultados del análisis de sangre.

Hace poco necesitaba publicar archivos desde un flujo de trabajo de GitHub en un servidor web. El agente configuró NGINX y propuso SSH para la publicación. Habría funcionado, pero los comandos remotos, las rutas y los permisos parecían demasiada maquinaria para transferir archivos.

Entonces me acordé de WebDAV, de «aquellos tiempos».

Le pregunté al agente. La respuesta cambió de inmediato: la instalación de NGINX elegida ya disponía de esa capacidad. Podíamos utilizar un protocolo pensado para editar archivos en un servidor remoto en lugar de montar un ritual de despliegue alrededor de una shell remota.

Eso dependía de la instalación. El módulo HTTP DAV de NGINX no se compila por defecto, y WebDAV sigue necesitando autenticación, una conexión segura y permisos de escritura delimitados.

La cuestión no es que WebDAV siempre gane a SSH. Encajaba mejor con ese requisito. El agente sabía lo suficiente para explicarlo e implementarlo en cuanto lo mencioné, pero no lo había propuesto.

Un desarrollador más joven podría conocer el mismo protocolo por otro camino. Mi aportación fue un recuerdo de un ciclo tecnológico anterior, activado por la sospecha de que la primera respuesta estaba resolviendo el problema en el nivel equivocado.

Si hubiera aceptado la primera respuesta técnicamente correcta, el agente me habría ayudado a implementarla igual de bien.

Sí, los agentes pueden volver mañana

Los modelos pueden señalar problemas sin que se les pida expresamente. Una revisión de código puede descubrir un defecto fuera de las líneas modificadas. Un agente con acceso a los registros de clientes puede detectar un silencio inusual, recuperar un comentario antiguo y crear una tarea de seguimiento.

Con memoria, un programador de tareas y las herramientas adecuadas, puede volver mañana. Quizá haga el seguimiento con más fiabilidad que una persona sobrecargada.

Bien. Construyan eso cuando el problema lo justifique.

La continuidad procede de pruebas guardadas y software en funcionamiento. El análisis de Anthropic sobre agentes de larga duración describe agentes que dejan registros de su progreso para sesiones posteriores. El modelo ayuda a elegir qué se conserva; la siguiente sesión necesita esos registros para continuar.

Pero almacenar no basta para conservar el significado. Un resumen puede guardar la conclusión y borrar la duda que debería haberla cambiado. Una tarea puede figurar como «completada» mientras el responsable de operaciones con experiencia recuerda que el cliente solo aceptó la solución provisional de forma temporal.

Si no quedan ni las pruebas ni un registro útil, la siguiente ejecución no tiene nada fiable que recuperar. Confiar en que un historial de chat asuma la responsabilidad es optimismo con barra de desplazamiento.

Un agente puede seleccionar métricas, proponer umbrales y programar su próxima cita. Alguien sigue siendo responsable de sus accesos, su presupuesto, la vía de escalado y las consecuencias de una advertencia pasada por alto. Tener una nueva cita no demuestra que el problema adecuado haya llegado al calendario.

Sustituir personas también elimina sus preguntas

La dirección cuenta documentos escritos, incidencias cerradas, código producido y horas ahorradas. Si un modelo puede generar el resultado visible, el puesto parece prescindible.

El trabajo invisible nunca llega a la hoja de cálculo.

¿Quién recordaba que los datos del proveedor dejan de ser fiables al cierre del trimestre? ¿Quién detectó que tres quejas aparentemente inofensivas de clientes describían el mismo fallo? ¿Quién volvió a revisar la solución provisional seis meses después?

Esas personas mantenían la capacidad de la organización para darse cuenta de lo que ocurre.

Los humanos olvidan muchas cosas. Pasan por alto señales y justifican malas decisiones. Pero la preocupación profesional puede sobrevivir al cierre de una tarea. Alguien de operaciones vuelve a comprobar el sistema después de que el panel se ponga verde porque la recuperación parece demasiado limpia. Una desarrolladora se levanta del escritorio y sigue dándole vueltas a una dependencia problemática.

Las organizaciones dependen de esto constantemente mientras fingen que no.

La empresa unipersonal con IA concentra esa responsabilidad en una sola persona. Los agentes pueden ampliar lo que esa persona es capaz de hacer. No pueden garantizar que se formule cada pregunta que falta.

Por eso una sustitución puede parecer un éxito durante meses.

El seguimiento necesita un responsable

Usen la IA para investigar, cuestionar supuestos y hacer seguimiento. Hagan explícita la continuidad:

• Conserven las pruebas originales, las alternativas descartadas y las dudas pendientes.
• Conviertan las preocupaciones recurrentes en pruebas, monitores o revisiones programadas.
• Asignen un responsable que pueda reabrir la cuestión cuando cambien las pruebas.
• Pregunten al agente qué omite el planteamiento actual y comprueben después qué no vigila nunca el sistema.

Por eso la continuidad debe quedar en el código, las pruebas y los registros duraderos. Una preocupación expresada con fluidez no garantiza que vaya a ocurrir nada después de que termine la respuesta.

Los LLM abaratan las respuestas. Eso aumenta el valor de detectar la anomalía, elegir la pregunta y no permitir que una respuesta cómoda dé por cerrado un problema incómodo.

Si el agente vuelve mañana, el software habrá organizado su regreso.

¿Quién detecta el problema para el que nadie programó un recordatorio?