Habr AI: em vez de pipelines de agentes complexos, desenvolvedores devem abraçar Markdown, Git e memória de sessão

Habr publicou um artigo com uma ideia simples mas contundente: a maioria das equipes está complicando demais o trabalho com agentes de IA, construindo pipelines pesados com LangChain, RAG e banco de dados vetorial onde, para o desenvolvimento real, lembrar-se de decisões passadas importa mais do que orquestração.

O autor compara o boom atual de pilhas de agentes com a era LAMP de meados dos anos 2000: a indústria novamente se apaixonou por infraestrutura e raramente questiona como essa infraestrutura realmente ajuda a resolver problemas concretos do produto.

O artigo examina uma abordagem empresarial típica: um orquestrador distribui tarefas para múltiplos agentes, que buscam contexto no RAG, invocam ferramentas, escrevem código e abrem pull requests.

Na visão do autor, tal esquema funciona razoavelmente bem para automatizar tarefas rotineiras como revisão de código, testes e linting, mas falha ao manter um horizonte de trabalho de longo prazo.

O problema não é tanto o modelo em si, mas como a memória funciona: cada novo ticket para um agente frequentemente começa quase do zero, sem um histórico estável de decisões, entendimento do domínio ou restrições acumuladas do projeto.

Assim, a busca semântica no código parece útil, mas não substitui o conhecimento real de por que a equipe escolheu aquele caminho específico em primeiro lugar.

Como alternativa, o autor propõe um sistema quase austero baseado em arquivos markdown e git.

Em vez de um pipeline universal, o autor constrói memória de trabalho a partir de sessões, papéis, competências, contextos e regras.

Uma sessão armazena níveis breves, médios e profundos de contexto, para que o trabalho subsequente continue não de um chat vazio, mas de decisões documentadas.

Um papel descreve não um programador abstrato, mas uma especialização concreta com conhecimento de domínio: quais APIs usar, quais erros são típicos, quais restrições existem em hardware, protocolo ou projeto.

Isso, argumenta o autor, reduz alucinações do modelo melhor do que mais uma camada de envolvimento em torno de chamadas de LLM.

Ênfase especial é colocada em regras que surgiram de erros.

Se um agente uma vez deletou um arquivo sem confirmação, ficou preso em debug infinito ou perdeu alterações não commitadas ao trocar de branch, isso se torna não um novo serviço middleware, mas uma regra explícita para sessões subsequentes.

O autor chama essa abordagem de aprendizado através da reflexão: um erro se torna um contrato, e o sistema se torna mais robusto com o tempo.

O artigo também inclui números práticos: durante quatro meses, segundo o autor, a abordagem foi usada em mais de 400 sessões em 11 projetos, incluindo firmware, criptografia e PKI, enquanto os custos de IA para um projeto totalizaram cerca de $30.

A lógica é que tokens baratos e estruturas de arquivo simples às vezes fornecem mais valor do que plataformas multi-camadas caras.

Uma parte importante do artigo se concentra não apenas em ferramentas, mas também no nível de interação com IA.

O autor descreve uma escada de maturidade: da autocompletar e o chamado vibe-coding até parceria arquitetônica, onde o engenheiro define papéis, contratos e limites, e o código se torna resultado de um processo adequadamente organizado.

Isso leva a uma tese mais ampla: as empresas frequentemente compram a ilusão de autonomia quando ferramentas como Devin, Copilot Workspace ou plataformas de agentes corporativos prometem trabalho sem um humano, mas na prática ainda esbarram na falta de memória do projeto e contexto.

Nesse sentido, IA deve ser vista não como substituta de engenheiros, mas como um exoesqueleto que amplifica especialistas e torna particularmente valiosos aqueles que conseguem transformar sua experiência em um sistema formalizado.

Para apoiar essa ideia, o autor até faz referência a conceitos antigos de simbiose humano-computador, Design by Contract e contexto de trabalho unificado, mostrando que a metodologia em si importa mais do que uma pilha da moda.

Para o mercado, este é outro sinal de que o próximo estágio do desenvolvimento de IA pode mudar de uma corrida entre orquestradores para uma corrida pela qualidade do contexto.

Pipelines autônomos permanecerão úteis para tarefas rotineiras, mas no trabalho de engenharia complexa, equipes que conseguem armazenar histórico de decisões, formalizar experiência de domínio e construir memória de longo prazo em torno de modelos vencerão, em vez de simplesmente adicionar novas camadas de infraestrutura.