Полгода я собирал идеальный CLAUDE.md. Вычитывал каждую строку. Добавлял секции: «используй yarn, не npm», «тесты запускай так», «структура проекта вот такая». 200 строк чистого, выстраданного контекста.

А потом учёные из ETH Zurich прогнали 5694 pull request'а через четыре модели - и выяснили, что мои 200 строк увеличивают расходы на 20% и снижают success rate на 3%.

Три процента. В минус.

Собственно, исследование

В феврале 2026-го Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev и Martin Vechev опубликовали статью «Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?» Авторы из ETH Zurich и LogicStar.ai. Я нашёл её на arXiv, прочитал целиком, полез в данные.

Они взяли 138 реальных Python-репозиториев. Собрали 5694 PR. Прогнали через четыре модели: Claude Sonnet 4.5, Codex GPT-5.2, GPT-5.1 Mini и Qwen3-30B (Qwen Code).

Тестировали в двух сценариях. Первый - SWE-Bench Lite, 300 задач с LLM-сгенерированными контекстными файлами. Это те файлы, которые делает /init в Claude Code или аналоги в Codex. Второй - их собственный AgentBench, 138 задач из нишевых репозиториев, которые модели точно не видели в обучающих данных. Там стояли человеческие AGENTS.md, написанные реальными мейнтейнерами.

Результаты:

LLM-сгенерированные файлы (те, что делает /init): success rate упал на 3% в среднем. Inference cost вырос на 20%+. То есть ты платишь больше за худший результат.

Человеческие файлы: success rate вырос на 4%. Но inference cost тоже вырос - на 19%. Четыре процента улучшения за двадцать процентов переплаты.

И вот что совсем обидно: агенты с контекстными файлами не находили нужные файлы быстрее. Вообще. Те самые красивые секции «Project Structure» и «Directory Overview», которые я заботливо описывал - агент их читал, тратил на это токены, а потом всё равно шёл грепать по репозиторию.

Подождите, но есть же другое исследование

Да, есть. Lulla et al., январь 2026-го - «On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents». Я скачал и его. Там результаты прямо противоположные: с AGENTS.md агент работает на 28.64% быстрее (медиана: 70.34 секунды вместо 98.57) и тратит на 16.58% меньше токенов (2440 вместо 2925).

Звучит убедительно. Но есть нюансы.

Lulla тестировали только Codex. Один агент. На 10 репозиториях. 124 PR. Задачи - до 100 строк кода, до 5 файлов. Из 89 репозиториев с AGENTS.md они отфильтровали до 26, потом до 10. Выборка не то чтобы репрезентативная.

И - внимание - они не мерили качество результата. «Manual sanity checks on 50 tasks» - это дословная цитата. Авторы сами пишут: это «does not constitute a full correctness evaluation».

Агент с AGENTS.md быстрее. Но никто не проверил, что именно он сделал. Может, он быстрее, потому что пропустил половину работы. Может, он увидел инструкцию «используем pytest» и уверенно побежал, не разбираясь в деталях. Мы не знаем.

ETH Zurich мерили success rate. И он упал.

Хотя тут я, может, придираюсь. 124 PR - не ноль. Возможно, для маленьких задач (до 100 строк) контекстный файл реально ускоряет, а на сложных - мешает. Было бы здорово, если бы кто-нибудь это проверил на одном датасете. Но пока - нет.

Почему «описание структуры» бесполезно

Самый контринтуитивный вывод: codebase overviews и directory listings не помогают агентам навигировать. Вообще.

Я лично потратил час на секцию «Архитектура проекта» в своём CLAUDE.md. Красиво нарисовал: вот тут модели, вот тут роуты, вот тут утилиты, а вот сюда не лезь. Сел, подумал над формулировками. Перечитал. Подправил.

Исследование говорит: агент это прочитал, потратил reasoning tokens, а потом пошёл и сам нашёл всё через grep и glob. Потому что он и так это умеет. Он умел это до моей секции. Он умеет это лучше меня - у него нет усталости и он не пропускает файлы.

Addy Osmani сформулировал фильтр в одну строку:

Can the agent discover this on its own by reading your code? If yes, delete it.

Мой «Архитектура проекта» - агент узнает за 3 секунды. Мой «Используемые технологии: Python 3.11, FastAPI, PostgreSQL» - он видит это в pyproject.toml. «Стиль кода: используем black и ruff» - конфиги лежат в корне.

Всё это - шум. Красивый, мне очень понравилось его писать. Но шум.

Что GPT-5.1 Mini делал с контекстом

В исследовании есть деталь, от которой я сначала не поверил. GPT-5.1 Mini, получив контекстный файл, начинал его перечитывать. Не один раз - несколько. Он тратил дополнительные шаги на повторное чтение уже загруженной информации. Reasoning tokens для GPT-моделей выросли на 14-22%.

Все четыре модели с контекстными файлами делали больше шагов: больше тестов, больше grep'ов, больше обходов файлов. Исследователи описывают это деликатно: «agents followed instructions in context files, resulting in more thorough approach.» А дальше: «often unnecessary for resolving the specific task at hand.»

Модель читает «всегда запускай тесты после изменений» - и послушно запускает тесты на задаче, где тесты не нужны. Модель читает «проверяй зависимости» - и проверяет зависимости там, где ты просто переименовываешь переменную. Отдельно забавно: когда в контекстном файле упоминались специфичные инструменты, использование этих инструментов прыгало с 0.05 до 2.5 вызовов в среднем. Агент читал инструкцию и начинал дёргать инструмент просто потому что ему про него рассказали.

На HN разработчик avhception рассказал историю: его агент, начитавшись контекстного файла, решил заменить SQLite на MariaDB. В контексте было написано «для продакшена используем MariaDB». Агент интерпретировал это как инструкцию к действию. Несколько строк в AGENTS.md, явно говорящих «не трогай базу данных» - не помогли.

Три файла, два формата, один бардак

Тут надо отступление. Не совсем по теме, но бесит.

У нас сейчас: CLAUDE.md, AGENTS.md, .cursorrules, copilot-instructions.md, CLAUDE.local.md. Пять файлов. Для одной цели - сказать AI-агенту, как работать с проектом.

На GitHub висит issue (#34235) с просьбой, чтобы Claude Code читал AGENTS.md нативно. Люди ведут один файл - и копируют из него в три разных формата. Кто-то в комментариях назвал корень репозитория «markdown museum for confused bots». Точнее не скажешь.

И каждый из этих файлов жрёт контекстное окно при каждом запросе. Даже когда ты спрашиваешь агента «переименуй переменную» - он сначала прочитает все твои инструкции, потому что они загружаются автоматически.

Так что, удалить?

Нет. Но радикально сократить.

Anthropic сами говорят: «keep it short and human-readable.» Fowler пишет: начинать постепенно, не фронтлоадить всё. Консенсус: меньше 300 строк, а лучше - меньше 60.

По данным исследования + Osmani + Fowler, вот что стоит оставить:

Оставить:

  • Команда для запуска тестов (если нестандартная)

  • Пакетный менеджер, если не очевидно (pnpm, не npm)

  • Кастомные линтеры с неочевидными настройками

  • Специфичные скрипты и инструменты

  • Конвенции именования, если они не выводятся из кода

Удалить:

  • Описание структуры проекта

  • Используемые языки и фреймворки

  • Общие паттерны кодирования

  • Архитектурные обзоры

  • Всё, что генерирует /init

pamelafox на HN написала: «I only add information to AGENTS.md when the agent has failed at a task... then revert and rerun to test improvement.» Не описывать проект заранее, а фиксировать ошибки. CLAUDE.md как баг-трекер для AI, а не как README для человека.

Мой файл до и после

Я перешёл от 200 строк к 47. Убрал «Архитектуру проекта» - 40 строк. Убрал «Используемые технологии» - 15 строк. Убрал «Стиль кода» - у меня есть .editorconfig и ruff.toml, агент их и так читает. Убрал описание API-эндпоинтов - агент и так заглядывает в docs/.

Оставил три команды, одну строку про пакетный менеджер, пять строк про деплой-специфику и ссылку на .env.example.

Не мерил разницу формально. Может, я делаю ту же ошибку что Lulla - субъективно кажется лучше, а может просто быстрее загружается. Но 47 строк я реально готов поддерживать. 200 строк устаревали быстрее, чем я успевал обновлять.

Чего не мерили

Исследование ETH Zurich тоже не идеальное. Мерили success rate - решил задачу или нет. Бинарно. Не мерили качество кода. Не мерили maintainability. Не мерили, следует ли агент конвенциям проекта.

rmunn на HN это подметил: то, что реально важно - стилистическая консистентность, правильные абстракции, следование паттернам - невозможно измерить бинарно.

Может оказаться, что агент без CLAUDE.md решает задачу чаще (потому что не отвлекается), но решает её в стиле, который не вписывается в проект. А с CLAUDE.md - решает реже, но результат лучше интегрируется. Этого пока никто не проверил.

vidarh вообще написал: «Without measuring quality of output, this seems irrelevant to me. Performance is not a consideration.» Жёстко, но логика есть. Если мне нужно 5 попыток вместо 3, но каждая попытка чище - success rate на первой попытке не так важен.

Хотя, может, я просто оправдываю свои 47 строк.

Один файл, чтобы править всеми

Знаете, что меня зацепило? Не сами числа. А скорость, с которой мы превратили простую идею в индустрию.

Год назад CLAUDE.md не существовал. Потом Anthropic добавил поддержку. Потом появились гайды. Потом шаблоны. Потом генераторы шаблонов. Потом исследования о том, что шаблоны не работают. Потом гайды о том, как правильно интерпретировать исследования.

Мы написали больше markdown'а про то, как разговаривать с AI, чем кода с его помощью.

sensanaty на HN напомнил: «thinking blocks are illusions - just tokens in sequence, not privileged reasoning layers.» Мы антропоморфизируем модели. Пишем им инструкции как стажёру. А они - статистические машины, предсказывающие следующий токен. Наши 200 строк контекста - это 200 строк токенов, которые сдвигают распределение вероятностей. Иногда в лучшую сторону. Иногда нет.

Fowler осторожно предупреждает: несмотря на слово «engineering» в «context engineering», исполнение остаётся вероятностным. Нельзя сказать «ensure it does X». Можно - «make it more likely to do X». И чем больше инструкций, тем выше вероятность конфликта между ними.

UPD: перечитал и понял, что сам грешу тем же. Мой CLAUDE.md на 47 строк - я его не тестировал. Не прогонял с ним и без него одни и те же задачи. Просто «чувствую, что лучше». Может, pamelafox права, и единственный честный подход - A/B тест на каждую строку. Но кто из нас это реально делает?

Комментарии (15)


  1. pda0
    14.03.2026 10:03

    Ну может если помощь в поиске AI не нужна, то использовать как каркас проекта? Типа такие файлы сюда, такие - сюда?


    1. diffnotes-tech Автор
      14.03.2026 10:03

      Ровно это исследование и проверяло - "такие файлы сюда, такие сюда" это и есть directory overview. И по данным ETH Zurich агент эту информацию игнорирует, потому что быстрее сам посмотрит через glob/grep чем читать описание.

      Но если речь про новый проект где файлов еще нет - тогда да, без каркаса в CLAUDE.md агент будет складывать всё как ему вздумается. Тут контекстный файл работает не как навигация, а как constraint. Другой кейс, исследование его не покрывало.


  1. aborouhin
    14.03.2026 10:03

    По-моему, ситуация для greenfield и brownfield проектов кардинально различается. Если во втором случае агент и может вывести структуру проекта, конвенции и пр. из кода - то в первом это всё для него - необходимые вводные. Ну и да, недостаточно просто дать ему инструкцию, надо вводить в воркфлоу этапы, на которых всё, что сделал агент, проверяется на соответствие этим принципам, и правится до момента, когда конфликтов не будет. SDD фреймворки в помощь, ну или свой велосипед.


    1. diffnotes-tech Автор
      14.03.2026 10:03

      Да, тут справедливо - оба исследования гоняли агентов на существующих репозиториях, greenfield вообще не трогали. На пустом проекте агенту неоткуда вывести конвенции, и контекстный файл это по сути единственный источник правды. Там вопрос скорее не "нужен ли CLAUDE.md" а "достаточно ли его". По опыту - на greenfield лучше работает plan.md или спека перед каждой задачей, потому что контекстный файл статичный, а проект на старте меняется каждый час. Но данных по этому нет, только ощущения.

      Про SDD согласен, валидация на каждом шаге снимает проблему "агент прочитал инструкцию и побежал не туда". По сути это тот же A/B тест pamelafox только встроенный в пайплайн.


  1. ruomserg
    14.03.2026 10:03

    Я не знаю как они делали это исследование, но это прямо противоречит моим прямым наблюдениям. Контекст - среднего размера Java-проект в корпоративной среде. Без заранее собранной отнологии проекта - любая задача начинается: "ах, давайте посмотрим на pom.xml; ах - давайте посмотрим примеры контроллеров... нет давайте посмотрим еще больше контроллеров чтобы понять эндпоинты; теперь давайте посмотрим бизнес-логику... нет давайте посмотрим больше бизнес логики... а еще посмотрим DTO" - и так уже бОльшая часть контекста кончилась. После появления файла онтологии - агент сразу идет в ту часть проекта, куда ему положено было бы идти - и там читает файлы для конкретной задачи.

    А еще - если у вас микросервисы, то вы должны дать агенту понимание что существует часть проекта вне его контроля, но с которой он взаимодействует. А еще - не дай бог в вашей корпоративной структуре есть разнообразные центры компетенций, которые вас снабжают шаблонами инфраструктуры и спринг-бут стартерами (которые агент в глаза не видел, и даже не подозревает об их существовании).

    В общем, это исследование - из серии "аэродинамики ЦАГИ после длительных продувок установили, что майский жук не способен к самостоятельному полету" (C).


    1. diffnotes-tech Автор
      14.03.2026 10:03

      Про Java-энтерпрайз - хороший пример, в статье этого не хватает. Исследование ETH гоняли на open-source Python-репозиториях, где структура обычно плоская и агент за пару grep'ов всё находит. Корпоративный Java-проект с микросервисами, внутренними стартерами и кастомной инфраструктурой - совсем другая история, там без онтологии агент реально утонет в контексте раньше чем доберётся до нужного модуля.

      Про внешние зависимости типа стартеров от центров компетенций - это вообще слепое пятно у обоих исследований. Агент не может загрепать то, о существовании чего он не подозревает. Тут контекстный файл не просто полезен, он необходим.

      Аналогия с жуком мне нравится, но я бы чуть скорректировал - скорее исследование показало что жук летает и без инструкции по полёту, но только если он маленький. Большой корпоративный жук без карты не взлетит.


      1. Norgat
        14.03.2026 10:03

        Да даже на python, если проект не тривиальный REST сервис, будет фронт, мб отдельные воркеры, отдельные микросервисы и тд.

        Я пришел к тому, что для подобного создал мастер репозиторий с понятной структурой, в него через submodule добавил компоненты и в мастер проекте завел доки с онтологией проекта. Почему так? Потому что тогда в доках понятно от какого корня писать пути до конкретных файлов (и это становится справедливо для всех частей проекта).


        1. diffnotes-tech Автор
          14.03.2026 10:03

          Интересный подход с мастер-репозиторием. По сути ты решаешь проблему которую исследование вообще не рассматривало - мультирепозиторная структура, где агент физически не видит соседние сервисы. Тут без явной онтологии он даже не узнает что они существуют.

          С submodules правда может быть нюанс - агент полезет в submodule как в обычную папку и начнет там что-то менять, не понимая что это отдельный репозиторий со своим циклом.
          Не сталкивался с таким?


          1. Norgat
            14.03.2026 10:03

            Это прописывается в инструкциях в README.md и AGENTS.md/CLAUDE.md
            В крайнем случае - ты же увидишь это на ревью кода (блокировки мастер веток для пуша для этого и созданы).


            1. diffnotes-tech Автор
              14.03.2026 10:03

              Логично, да. В итоге получается что CLAUDE.md тут работает не как "подсказка для навигации" (которую исследование критикует), а как constraint - "сюда не лезь". И это ровно тот тип инструкций который по данным ETH реально помогает.

              Ну и code review никто не отменял, согласен. Просто хочется чтобы агент не создавал лишнюю работу ревьюеру.


      1. ruomserg
        14.03.2026 10:03

        Ну да, беда таких исследований - они не объясняют понятным языком границу применимости. В результате - народ воспринимает это как инструкцию "не писать AGENTS.md". :-(


        1. diffnotes-tech Автор
          14.03.2026 10:03

          Ну я в статье старался это подчеркнуть - что success rate падает на LLM-сгенерированных файлах, а человеческие дают +4%. Но заголовок кликбейтный, да, виноват. Реальный вывод скорее "не генерируй через /init и не описывай то что агент сам найдет", а не "выкинь всё".


          1. ruomserg
            14.03.2026 10:03

            Да нет же! Генерация онтологии через /init - вполне годная вещь! Поймите, агент так устроен что он будет делать дискавери в пустом контексте. И на это дискавери он потратит очень ценные токены в начале контекста. У него начало контекста будет забито разными тул-коллами, причем часть файлов ему нафиг не нужна для работы - но он прочитал и развидеть уже не может. А вы через /init делаете чек-поинт дискавери, и при последующих запусках он СРАЗУ считает это чекпоинт, и будет тратить контекст на задачу. Это как минимум - большая экономия токенов (ибо результат дискавери будет переиспользован столько раз, сколько вы сбросите контекст)

            Я уж не говорю, что вы дискавери можете хорошо провести дорогой моделью (например Opus), а потом результат использовать дешевыми моделями. Которые в принципе не способны на качественный дискавери - и вместо этого нафантазируют себе всякое, а потом пойдут на основании этого чего-то править (тот же Haiku)...

            Так что нет - онтология при реальной работе важна и нужна. Внимательно посмотреть и почистить после автогенерации - конечно нужно. Но даже автоматическая - сильно лучше чем отсутствие таковой (в реальной жизни, не в исследовании!).


            1. diffnotes-tech Автор
              14.03.2026 10:03

              Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 15-20 tool calls на разведку - то закешировать это в файл логично, даже если качество самого кеша неидеальное.

              Про Opus для дискавери + Haiku для работы - тоже валидно. Исследование ETH гоняло каждую модель отдельно с одинаковым контекстным файлом, кейс "сгенерировал умной моделью, использовал дешевой" они вообще не тестировали. А это может быть тот самый сценарий где /init окупается.

              Наверное правильнее сказать не "не генерируй через /init", а "сгенерируй, вычисти мусор, и не дублируй то что и так в конфигах лежит". Тут я погорячился в формулировке)


    1. Romatio
      14.03.2026 10:03

      Поддерживаю. На одном проекте указано, что локально развернут в докере, взаиможействует с микросервисами, claude code не задает тупых вопросов и сразу сам все видит.
      На другом, мелком и простом, такого нет, и каждый раз приходится напоминать, что вот же все в докере, вот, смотри, лежит docker-compose. Каждый раз его пропускает. Но тут уже используется opencode с китайскими моделями, может, это и влияет.