Habr Breakdown: AI Agents Burn Tokens Before Writing a Single Line of Code, and 5 Patterns Could Help

Token consumption by AI agents on a large codebase grows noticeably faster than the volume of code they write. A significant part of the budget goes before the first line of code: searching for files, reading, and working out the architecture. That is the thesis of the author of a new Habr breakdown, who proposes five general-purpose patterns for saving tokens. The RSS announcement publishes only the introduction. The patterns themselves are revealed in the full article, so below we cover what the announcement claims and add industry context.

Where the tokens burn

Agents moved beyond generating individual functions long ago. The author lists what they do in real projects: they explore the repository, search for the files they need, analyze the architecture, run tests, and check the result. The tasks themselves are ordinary. Add a page to the frontend, create an endpoint, change a database schema, sort out a message queue, fix a data pipeline, update CI/CD, connect a new service.

In every case, the agent starts with reconnaissance. It reads files, gets search output and directory listings, and looks at test logs. All of this lands in the context window and is sent to the model again at every subsequent step. The larger the repository, the longer the reconnaissance, and the cost of a task stops depending on the size of the final diff.

What the announcement claims

• Topic: saving AI agent tokens when working with a codebase.
• Format: five general-purpose patterns not tied to a specific stack.
• Coverage: frontend, backend, database schemas, queues, data pipelines, CI/CD, new services.
• Main thesis: token consumption grows faster than the volume of code written.
• Key observation: a significant share of tokens is spent before the first line is written.

The available excerpt contains no specific savings figures. The announcement alone does not allow any assessment of how effective the patterns are.

Which techniques usually work

Here are industry-wide practices that engineers use for the same problem. This is not a summary of the article, and it is unknown whether they match the author's five patterns.

• Search first, read second. Find the symbols and paths you need with targeted search, and open line ranges rather than whole files.
• A compact repository map. A short description of the structure and key modules, so the agent does not have to work it out again in every session.
• A project rules file. Build and test commands, conventions, and off-limits areas, written down once.
• Output filtering. The agent needs the failed tests and the error stack trace, not the full log of the run.
• Isolated reconnaissance. Heavy exploration is moved into a separate session or subagent, and only a short summary returns to the main context.
• Caching a stable prompt prefix, if the provider supports it.

What teams should do

Start by measuring. Without a breakdown of tokens by phase (reconnaissance, edits, verification), any optimization is blind. Log consumption per task and compare it with the size of the diff: if reconnaissance is consistently more expensive than writing the code, the problem lies in navigating the project, not in the model.

Then set a per-task budget and see where the agent uses it up. Usually it is repeated reads of the same files, broad searches, and untrimmed logs. These three sources are cheap to fix, with no change of model or tooling.

The full text on Habr is worth reading with a specific question in mind: which of the five patterns can you test on your repository in a single day, and how will you measure the result? If the author provides before-and-after measurements, they are more valuable than the recommendations themselves.