Habr AI explains how coding agents use memory, tools, and repository context

Habr AI published a translation of an article about how modern coding assistants work and why their quality is determined not only by the model itself. The text is without excessive technical depth, but it lays out the basics well: tools, memory, repository context, and what's usually hidden behind the "Generate" button.

Not Just the Model

One of the main theses of the article is that a coding agent is not just an LLM with access to chat. Between the model and the task stands a harness — a working environment that gives the agent rules, tools, and an execution cycle. It's this harness that decides whether the model will see the project structure, whether it can run tests, read a file, compare a diff, and return to an error after a failed attempt. Without it, even a strong model quickly becomes a generator of plausible but poorly verified answers.

Coding infrastructure differs from ordinary agent infrastructure in that it's tailored to a very specific workflow. It doesn't need abstract "actions," but rather tight integration with developer tools. Such an agent should not just reason about a fix, but actually walk through the typical path of an engineer: open the code, find the related module, check constraints, make a change, and immediately see the result.

A basic working toolkit typically looks like this:

• reading and searching files
• running tests and linters
• reviewing diff and git status
• editing code with the project structure in mind

The tighter this cycle, the less manual work is left for the user. That's why two assistants built on the same model can feel like products of different classes. If one can only chat, and the second lives next to the terminal and repository, the difference in results will be noticeable on the first non-trivial task. The model remains the same, but the environment makes it either a useful partner or just a chatty text generator.

Memory and Repository

The second important topic is memory. For a coding agent, it's not enough to simply remember the user's last messages. It needs a working trail: which files have already been studied, what hypotheses were tested, why a test failed, which code segments have already been changed, and what can't be broken along the way. Such memory noticeably reduces repetition and helps avoid going in circles when a task is solved over several steps, not in one answer.

Repository context is discussed separately. A good assistant should understand not just the current file, but also the connections between modules, project conventions, existing abstractions, and neighboring code that the fix depends on. When an agent sees only an inserted fragment, it writes something locally plausible, but often misses the overall architecture. When it sees the repository as a system, it starts better choosing where to make changes, reusing existing patterns, and rarely invents unnecessary entities.

Here it also becomes clearer why compaction is needed. As work progresses, history grows, and the context window is not infinite. That's why good systems periodically compress accumulated steps into a short but useful state: what has already been done, what didn't work, what constraints matter now. If done carefully, the agent doesn't lose the thread of the task. If done poorly, it quickly forgets critical details and starts explaining the obvious all over again.

Why Console is Stronger

This leads to an observation familiar to many developers: the same model in a console tool often seems smarter than in a regular web chat. The reason is not magic and not necessarily a different version of the model. Simply in the terminal, the agent is embedded in a working environment: it sees files, executes commands, gets feedback from tests, and can quickly adjust the next step. In chat, the user themselves hauls pieces of code back and forth and manually assembles the context the agent needs to work properly.

That's exactly why this article is useful not only to those building their own assistants, but also to those who simply use them. It helps understand why a "raw" model and a product based on it are different levels of a system. On the surface, it seems like only the interface changes. In practice, what changes is access to tools, the way memory is managed, the rules for selecting context, and the very discipline of task execution. For a developer, this is already a tangible difference in quality.

What This Means

For the AI development market, this is an important shift in understanding product value. Competition is no longer just between models, but between the environments in which these models work. That's why the coding assistants that win will be those better integrated into the real developer process: able to use tools, keep work history in memory, and understand the repository deeper than just one open file.