Habr AI: en lugar de pipelines de agentes complejos, se aconseja a los desarrolladores usar markdown, git y memoria de sesiones

En Habr ha aparecido una columna con una idea sencilla pero contundente: la mayoría de los equipos complica en exceso su trabajo con agentes de IA. Construyen pipelines enormes con LangChain, RAG y bases de datos vectoriales, cuando en el desarrollo real importa menos la orquestación que la memoria de las decisiones tomadas. El autor compara el actual auge de los stacks de agentes con la era LAMP de mediados de la década de 2000: la industria vuelve a obsesionarse con la infraestructura y se pregunta muy pocas veces cómo ayuda esa infraestructura a resolver los problemas concretos del producto.

El texto analiza un enfoque empresarial típico: un orquestador reparte tareas entre varios agentes, que consultan el RAG para obtener contexto, llaman a herramientas, escriben código y abren pull requests. En opinión del autor, este esquema sirve bastante bien para automatizar tareas rutinarias como la revisión de código, las pruebas y el linting, pero aguanta mal el trabajo a largo plazo. El problema está menos en el modelo que en el diseño de la memoria: cada nuevo ticket suele empezar para el agente casi desde cero, sin un historial sólido de decisiones, sin comprensión del dominio y sin las restricciones acumuladas del proyecto.

Por eso la búsqueda semántica en el código parece útil, pero no sustituye el conocimiento real de por qué el equipo eligió en su día un camino determinado.

Como alternativa, el autor propone un sistema casi ascético basado en archivos markdown y git. En lugar de un pipeline universal, construye una memoria de trabajo a partir de sesiones, roles, competencias, contextos y reglas. La sesión guarda tres niveles de contexto, breve, medio y profundo, de modo que el siguiente trabajo continúe a partir de decisiones registradas y no desde un chat vacío. El rol describe no a un programador abstracto, sino una especialización concreta con conocimiento del dominio: qué API usar, qué errores son típicos, qué limitaciones tienen el hardware, el protocolo o el proyecto. Según el autor, esto reduce las alucinaciones del modelo mejor que otra capa más de envoltorio alrededor de las llamadas al LLM.

Se da un énfasis especial a las reglas que nacen de los errores. Si un agente borró una vez un archivo sin confirmación, se perdió en una depuración interminable o perdió cambios sin confirmar al cambiar de rama, eso no se convierte en un nuevo servicio middleware, sino en una regla explícita para las siguientes sesiones. El autor llama a este enfoque aprendizaje por reflexión: el error se convierte en contrato y el sistema se vuelve con el tiempo más robusto.

El artículo incluye también cifras prácticas: según el autor, durante cuatro meses el esquema se usó en más de 400 sesiones en 11 proyectos, entre ellos firmware, criptografía y PKI, y el gasto en IA de uno de los proyectos fue de unos 30 dólares. La lógica es que los tokens baratos y una estructura de archivos simple a veces aportan más que una plataforma cara de varios niveles.

Una parte importante del artículo trata no solo de las herramientas, sino del nivel de interacción con la IA. El autor describe una escalera de madurez: desde el autocompletado y el llamado vibe coding hasta la colaboración arquitectónica, donde el ingeniero define roles, contratos y límites, y el código es consecuencia de un proceso bien organizado. De ahí surge una tesis más amplia: las empresas compran con frecuencia una ilusión de autonomía.

Herramientas como Devin, Copilot Workspace o las plataformas corporativas de agentes prometen trabajar sin humanos, pero en la práctica siguen chocando con la falta de memoria y contexto del proyecto. En este sentido, la IA se plantea no como sustituta del ingeniero, sino como un exoesqueleto que potencia al especialista y vuelve especialmente valioso a quien sabe convertir su propia experiencia en un sistema formalizado. Para respaldar la idea, el autor llega a citar viejos conceptos de simbiosis entre humano y ordenador, Design by Contract y contexto de trabajo unificado, y concluye que aquí la metodología importa más que el stack de moda.

Para el mercado, es otra señal de que la próxima etapa del desarrollo con IA podría pasar de la carrera de los orquestadores a la carrera por la calidad del contexto. Los pipelines autónomos seguirán siendo útiles para la rutina masiva, pero en las tareas de ingeniería complejas ganarán los equipos que sepan conservar el historial de decisiones, formalizar la experiencia del dominio y construir una memoria duradera alrededor del modelo, en lugar de limitarse a añadir nuevas capas de infraestructura.