Habr: cómo una base de conocimiento obsoleta rompe el trabajo de los agentes LLM y cómo arreglarlo

Habr ha publicado la segunda parte de una serie sobre desarrollo con LLM. El autor explica por qué una base de conocimiento obsoleta es más peligrosa que carecer por completo de documentación. Si se le muestra al agente un markdown vistoso pero desactualizado, lo tomará por cierto y empezará a cometer errores en la arquitectura, los estados y las dependencias.

Por qué importa

La idea central es simple: un LLM confía en el contexto igual que un compilador confía en sus datos de entrada. Cuando la base de conocimiento contiene versiones antiguas de servicios, enlaces rotos y planes que hace tiempo se alejaron de la realidad, el agente se apoya en un mapa falso del proyecto. Los errores no surgen entonces de un modelo débil, sino de que se le ha dado una descripción incorrecta del entorno. Para equipos con decenas de proyectos en paralelo, esto se convierte rápido en un problema sistémico, no en un descuido puntual.

El autor subraya que la disciplina manual casi no funciona aquí. Cuantos más documentos, repositorios y sesiones con el agente haya, más rápido acumula entropía la base de conocimiento. Incluso un workbench bien estructurado se queda obsoleto desde el momento de su creación si nadie lo comprueba automáticamente. Por eso la cuestión ya no es si escribir documentación o no, sino cómo integrar en el proceso mecanismos que impidan que se degrade en silencio y envenene el siguiente ciclo de desarrollo.

Cómo detectar la obsolescencia

La respuesta básica son comprobaciones automáticas sencillas, que se pueden lanzar a mano o en CI. El autor describe un script que ejecutó primero sobre su propio workbench y que encontró de inmediato decenas de problemas: más de un tercio de los enlaces internos no llevaba a ninguna parte tras migrar documentos entre repositorios. Para un agente esto es especialmente peligroso: intenta seguir el enlace, no encuentra el archivo y, o bien pierde el contexto, o bien empieza a completarlo con alucinaciones. A escala, esto se convierte pronto en una fuente constante de defectos.

• Comprobación de enlaces internos entre archivos markdown
• Control de la vigencia de los documentos clave según su fecha de actualización
• Comprobación de cobertura: cada proyecto debe tener un archivo workspace
• Agregación de los TODO de todos los documentos markdown en un único punto de revisión

Por separado, el autor aconseja fijar un umbral de vigencia, por ejemplo 60 días, y no reescribir cada documento desde cero, sino hacer una revisión breve de los datos: versiones, estados, dependencias y planes actuales. Un par de minutos en esa pasada devuelve la confianza al documento. La misma lógica vale para los TODO: mientras las tareas estén dispersas entre logs, planes y notas, el equipo no ve el panorama completo. Una vez agregadas, la base de conocimiento vuelve a ser una herramienta de trabajo y no un archivo de notas aleatorias.

Reglas y trampas

Los scripts no bastan si los documentos no tienen un ciclo de vida claro. El autor propone etiquetarlos con los estados active, reference, draft y archived, y mover el material antiguo a archive/ en lugar de borrarlo. Tras cada fase de trabajo, el agente debe actualizar los documentos relacionados, registrar lo que queda pendiente y, si se desborda la ventana de contexto, preparar un continuation prompt para la siguiente sesión. Así la base de conocimiento se mantiene sincronizada entre sesiones y no se dispersa por la memoria del modelo.

Escribe el autor:

«Un plan obsoleto es el mismo contexto envenenado, solo que de aspecto

inofensivo».

En la segunda parte del argumento aparece también la otra cara: el LLM abarata demasiado la automatización, por lo que el desarrollador empieza fácilmente a optimizar el proceso en lugar del producto. Otro ADR, otro script o un pipeline perfectamente descrito parecen progreso, aunque en producción siga sin haber una funcionalidad que funcione. La pauta práctica es estricta: primero el producto, luego staging, monitorización y CI/CD, después tipado, pruebas y ciclos autónomos más complejos. Si un equipo construye la cadena completa «hipótesis, generación, despliegue» antes de aprender a detectar un merge roto, está invirtiendo en metaoptimización con un ROI dudoso.

Qué significa

El texto de Habr da en el principal punto débil del desarrollo asistido por IA: la calidad de la respuesta del modelo depende cada vez más no solo del prompt, sino de la higiene del contexto que rodea al código. Para equipos y desarrolladores en solitario, la conclusión es práctica: la base de conocimiento debe regirse por las mismas reglas que el código, con comprobaciones, estados y actualización regular. Si no, el LLM no acelerará el trabajo, sino la propagación de errores antiguos que parecerán verosímiles y se repetirán de sesión en sesión.