Habr AI: Instead of Complex Agent Pipelines, Developers Should Embrace Markdown, Git, and Session Memory

Habr published an article with a simple but sharp idea: most teams are overcomplicating AI agent work by building bulky pipelines with LangChain, RAG, and vector databases where, for real development, remembering past decisions matters more than orchestration.

The author compares today's AI-agent stack boom to the LAMP era of the mid-2000s: the industry has once again become fascinated by infrastructure and too rarely asks how that infrastructure actually helps solve concrete product problems.

The article examines a typical enterprise approach: an orchestrator distributes tasks to multiple agents, which fetch context from RAG, invoke tools, write code, and open pull requests.

In the author's view, such a scheme works reasonably well for automating routine tasks like code review, testing, and linting, but fails to maintain a long-term work horizon.

The problem is not so much the model itself, but how memory works: each new ticket for an agent often starts nearly from scratch, without a stable history of decisions, domain understanding, or accumulated project constraints.

So semantic search over code looks useful, but it doesn't replace real knowledge of why the team chose that particular path in the first place.

As an alternative, the author proposes an almost austere system based on markdown files and git.

Instead of a universal pipeline, the author builds working memory from sessions, roles, competencies, contexts, and rules.

A session stores brief, medium, and deep levels of context, so that subsequent work continues not from an empty chat, but from documented decisions.

A role describes not an abstract programmer, but a concrete specialization with domain knowledge: which APIs to use, what errors are typical, what constraints exist in hardware, protocol, or project.

This, the author argues, reduces model hallucinations better than yet another wrapper layer around LLM calls.

Special emphasis is placed on rules that have grown out of mistakes.

If an agent once deleted a file without confirmation, got stuck in endless debugging, or lost uncommitted changes when switching branches, this becomes not a new middleware service, but an explicit rule for subsequent sessions.

The author calls this approach learning through reflection: a mistake becomes a contract, and the system grows more robust over time.

The article also includes practical numbers: over four months, according to the author, the approach was used in more than 400 sessions across 11 projects, including firmware, cryptography, and PKI, while AI costs for one project totaled about $30.

The logic is that cheap tokens and simple file structures sometimes provide more value than expensive multi-layered platforms.

An important part of the article focuses not only on tools but also on the level of interaction with AI.

The author describes a maturity ladder: from autocomplete and so-called vibe-coding to architectural partnership, where the engineer defines roles, contracts, and boundaries, and code becomes the result of a properly organized process.

This leads to a broader thesis: companies often buy the illusion of autonomy when tools like Devin, Copilot Workspace, or corporate agent platforms promise work without a human, but in practice still hit a wall due to lack of project memory and context.

In this sense, AI should be viewed not as a replacement for engineers, but as an exoskeleton that amplifies specialists and makes particularly valuable those who can turn their experience into a formalized system.

To support this idea, the author even references old concepts of human-computer symbiosis, Design by Contract, and unified work context, showing that methodology itself matters more than a trendy stack.

For the market, this is another signal that the next stage of AI development may shift from a race among orchestrators to a race for context quality.

Autonomous pipelines will remain useful for routine tasks, but in complex engineering work, teams that can store decision history, formalize domain expertise, and build long-term memory around models will win, rather than simply adding new layers of infrastructure.