Habr AI: Skip Complex Agent Pipelines, Developers Are Told, and Use Markdown, Git and Session Memory

A column on Habr makes a simple but blunt argument: most teams overcomplicate their work with AI agents. They build unwieldy pipelines with LangChain, RAG and vector databases, when real development depends less on orchestration than on a memory of past decisions. The author compares the current boom in agent stacks to the LAMP era of the mid-2000s: the industry has again fallen for infrastructure and too rarely asks how that infrastructure helps solve a product's actual problems.

The text examines a typical enterprise approach: an orchestrator hands tasks to several agents, which pull context from RAG, call tools, write code and open pull requests. In the author's view, this setup works reasonably well for automating routine work such as code review, tests and linting, but handles long-horizon work poorly. The problem lies less in the model than in how memory is built: for the agent, each new ticket often starts almost from scratch, with no durable history of decisions, no grasp of the domain and no record of the project's accumulated constraints.

Semantic search over code looks useful, but it does not replace actual knowledge of why the team once chose a particular path.

As an alternative, the author proposes a nearly ascetic system built on markdown files and git. Instead of a universal pipeline, he assembles working memory from sessions, roles, competencies, contexts and rules. A session stores short, medium and deep levels of context, so the next round of work continues from recorded decisions rather than an empty chat. A role describes not an abstract programmer but a specific specialization with domain knowledge: which APIs to use, which errors are typical, what limits the hardware, protocol or project imposes. According to the author, this reduces model hallucinations better than yet another layer of wrapping around LLM calls.

Rules that grow out of mistakes get special emphasis. If an agent once deleted a file without confirmation, fell into endless debugging or lost uncommitted changes while switching branches, the fix is not a new middleware service but an explicit rule for later sessions. The author calls this learning through reflection: a mistake becomes a contract, and the system grows more robust over time.

The article also gives practical figures: over four months, the author says, the scheme was used in more than 400 sessions across 11 projects, including firmware, cryptography and PKI, and AI costs for one of the projects came to about 30 dollars. The logic is that cheap tokens and a simple file structure sometimes deliver more than an expensive multilayer platform.

An important part of the article concerns not only tools but the level at which people work with AI. The author describes a maturity ladder, from autocomplete and so-called vibe coding to architectural partnership, where the engineer sets roles, contracts and boundaries, and code follows from a well-organized process. From this comes a broader thesis: companies often buy an illusion of autonomy.

Tools such as Devin, Copilot Workspace or corporate agent platforms promise work without a human, yet in practice still run into a shortage of project memory and context. In this sense, AI is framed not as a replacement for the engineer but as an exoskeleton that amplifies a specialist and makes especially valuable the person who can turn personal experience into a formalized system. To support the idea, the author even cites older concepts of human-computer symbiosis, Design by Contract and a unified working context, arguing that methodology matters more here than a fashionable stack.

For the market, this is another signal that the next stage of AI development may shift from a race of orchestrators to a race for context quality. Autonomous pipelines will remain useful for mass routine work, but in complex engineering tasks the winners will be teams that can store decision history, formalize domain expertise and build long-term memory around the model, rather than simply adding new layers of infrastructure.