Habr: Cómo una Base de Conocimiento Desactualizada Rompe LLM-Agentes y Cómo Corregirlo

Habr publicó la segunda parte de una serie sobre desarrollo con LLM: el autor explica por qué una base de conocimiento desactualizada es más peligrosa que la falta completa de documentación. Si muestras a un agente un markdown bonito pero obsoleto, lo tomará por verdad y comenzará a cometer errores a nivel de arquitectura, estados y dependencias.

Por qué esto es importante

La idea principal es simple: un LLM confía en el contexto de la misma manera que un compilador confía en los datos de entrada. Cuando una base de conocimiento contiene versiones antiguas de servicios, enlaces rotos y planes que hace mucho que se alejan de la realidad, el agente se apoya en un mapa falso del proyecto. Como resultado, los errores aparecen no porque el modelo sea débil, sino porque le dieron una descripción inexacta del entorno. Para equipos con docenas de proyectos paralelos, esto rápidamente se convierte en un problema sistémico en lugar de un descuido aislado.

El autor subraya que la disciplina manual apenas funciona aquí. Cuantos más documentos, repositorios y sesiones con agentes, más rápido la base de conocimiento acumula entropía. Incluso un workbench bien estructurado queda desactualizado en el momento en que se crea, si nadie lo verifica automáticamente. Por lo tanto, la pregunta ya no es si escribir documentación o no, sino cómo incorporar en el proceso mecanismos que no dejen que se degrade silenciosamente y envenene el próximo ciclo de desarrollo.

Cómo detectar la obsolescencia

La respuesta básica son verificaciones automáticas simples que se pueden ejecutar manualmente o en CI. El autor describe un script que pasó por su workbench e inmediatamente encontró docenas de problemas: más de un tercio de los enlaces internos no llevaba a ningún lugar después de migraciones de documentos entre repositorios. Para un agente, esto es especialmente peligroso: intenta seguir un enlace, no encuentra el archivo y pierde contexto o comienza a llenarlo con alucinaciones. A escala, esto rápidamente se convierte en una fuente constante de defectos.

• Verificación de enlaces internos entre archivos markdown
• Control de la actualidad de documentos clave por fecha de modificación
• Verificación de cobertura: cada proyecto debe tener un archivo de workspace
• Agregación de TODO de todos los documentos markdown en un único punto de visión general

El autor recomienda por separado introducir un umbral de actualidad, por ejemplo 60 días, y no reescribir cada documento de cero, sino hacer una breve revisión de los hechos: versiones, estados, dependencias, planes actuales. Unos minutos de tal revisión devuelven credibilidad al documento. La misma lógica funciona para TODOs: mientras las tareas estén dispersas en logs, planes y notas, el equipo no ve el cuadro completo. Una vez agregadas, la base de conocimiento vuelve a ser una herramienta de trabajo, no un archivo de notas aleatorias.

Reglas y trampas

Los scripts por sí solos no son suficientes si los documentos en sí no tienen un ciclo de vida claro. El autor sugiere marcarlos con estados active, reference, draft y archived, y poner materiales antiguos en archive/ en lugar de eliminarlos. Después de cada fase de trabajo, el agente debe actualizar documentos relacionados, registrar elementos incompletos y, cuando la ventana de contexto se llene, recopilar un prompt de continuación para la siguiente sesión. De esta manera, la base de conocimiento permanece sincronizada entre sesiones en lugar de extenderse por la memoria del modelo.

Como escribe el autor:

"Un plan desactualizado es el mismo contexto envenenado, solo que

pareciendo inocente."

La segunda parte del argumento trae a la luz el lado opuesto: LLM hace la automatización demasiado barata, por lo que el desarrollador fácilmente comienza a optimizar el proceso en lugar del producto. Otro ADR, otro script o un pipeline perfectamente planificado se ven como progreso, aunque production aún podría carecer de una feature funcionando. La orientación práctica aquí es estricta: primero producto, luego staging, monitoreo y CI/CD, después tipificación, pruebas y ciclos autónomos más complejos. Si el equipo construye una cadena completa "hipótesis — generación — deploy" antes de aprender a detectar un merge roto, invierte en meta-optimización con ROI cuestionable.

Qué significa esto

El material en Habr golpea directamente el principal dolor de cabeza del desarrollo asistido por IA: la calidad de la respuesta de un modelo depende cada vez más no solo del prompt, sino de la higiene del contexto alrededor del código. Para equipos y desarrolladores en solitario, la conclusión es práctica: la base de conocimiento debe vivir por las mismas reglas que el código — con verificaciones, estados y actualizaciones regulares. De lo contrario, LLM acelerará no el trabajo, sino la propagación de errores antiguos que parecerán plausibles y se reproducirán de sesión en sesión.