Полгода я собирал идеальный 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)

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

diffnotes-tech Автор
14.03.2026 10:03Да, тут справедливо - оба исследования гоняли агентов на существующих репозиториях, greenfield вообще не трогали. На пустом проекте агенту неоткуда вывести конвенции, и контекстный файл это по сути единственный источник правды. Там вопрос скорее не "нужен ли CLAUDE.md" а "достаточно ли его". По опыту - на greenfield лучше работает plan.md или спека перед каждой задачей, потому что контекстный файл статичный, а проект на старте меняется каждый час. Но данных по этому нет, только ощущения.
Про SDD согласен, валидация на каждом шаге снимает проблему "агент прочитал инструкцию и побежал не туда". По сути это тот же A/B тест pamelafox только встроенный в пайплайн.

ruomserg
14.03.2026 10:03Я не знаю как они делали это исследование, но это прямо противоречит моим прямым наблюдениям. Контекст - среднего размера Java-проект в корпоративной среде. Без заранее собранной отнологии проекта - любая задача начинается: "ах, давайте посмотрим на pom.xml; ах - давайте посмотрим примеры контроллеров... нет давайте посмотрим еще больше контроллеров чтобы понять эндпоинты; теперь давайте посмотрим бизнес-логику... нет давайте посмотрим больше бизнес логики... а еще посмотрим DTO" - и так уже бОльшая часть контекста кончилась. После появления файла онтологии - агент сразу идет в ту часть проекта, куда ему положено было бы идти - и там читает файлы для конкретной задачи.
А еще - если у вас микросервисы, то вы должны дать агенту понимание что существует часть проекта вне его контроля, но с которой он взаимодействует. А еще - не дай бог в вашей корпоративной структуре есть разнообразные центры компетенций, которые вас снабжают шаблонами инфраструктуры и спринг-бут стартерами (которые агент в глаза не видел, и даже не подозревает об их существовании).
В общем, это исследование - из серии "аэродинамики ЦАГИ после длительных продувок установили, что майский жук не способен к самостоятельному полету" (C).

diffnotes-tech Автор
14.03.2026 10:03Про Java-энтерпрайз - хороший пример, в статье этого не хватает. Исследование ETH гоняли на open-source Python-репозиториях, где структура обычно плоская и агент за пару grep'ов всё находит. Корпоративный Java-проект с микросервисами, внутренними стартерами и кастомной инфраструктурой - совсем другая история, там без онтологии агент реально утонет в контексте раньше чем доберётся до нужного модуля.
Про внешние зависимости типа стартеров от центров компетенций - это вообще слепое пятно у обоих исследований. Агент не может загрепать то, о существовании чего он не подозревает. Тут контекстный файл не просто полезен, он необходим.
Аналогия с жуком мне нравится, но я бы чуть скорректировал - скорее исследование показало что жук летает и без инструкции по полёту, но только если он маленький. Большой корпоративный жук без карты не взлетит.

Norgat
14.03.2026 10:03Да даже на python, если проект не тривиальный REST сервис, будет фронт, мб отдельные воркеры, отдельные микросервисы и тд.
Я пришел к тому, что для подобного создал мастер репозиторий с понятной структурой, в него через submodule добавил компоненты и в мастер проекте завел доки с онтологией проекта. Почему так? Потому что тогда в доках понятно от какого корня писать пути до конкретных файлов (и это становится справедливо для всех частей проекта).

diffnotes-tech Автор
14.03.2026 10:03Интересный подход с мастер-репозиторием. По сути ты решаешь проблему которую исследование вообще не рассматривало - мультирепозиторная структура, где агент физически не видит соседние сервисы. Тут без явной онтологии он даже не узнает что они существуют.
С submodules правда может быть нюанс - агент полезет в submodule как в обычную папку и начнет там что-то менять, не понимая что это отдельный репозиторий со своим циклом.
Не сталкивался с таким?
Norgat
14.03.2026 10:03Это прописывается в инструкциях в README.md и AGENTS.md/CLAUDE.md
В крайнем случае - ты же увидишь это на ревью кода (блокировки мастер веток для пуша для этого и созданы).
diffnotes-tech Автор
14.03.2026 10:03Логично, да. В итоге получается что CLAUDE.md тут работает не как "подсказка для навигации" (которую исследование критикует), а как constraint - "сюда не лезь". И это ровно тот тип инструкций который по данным ETH реально помогает.
Ну и code review никто не отменял, согласен. Просто хочется чтобы агент не создавал лишнюю работу ревьюеру.

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

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

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

diffnotes-tech Автор
14.03.2026 10:03Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 15-20 tool calls на разведку - то закешировать это в файл логично, даже если качество самого кеша неидеальное.
Про Opus для дискавери + Haiku для работы - тоже валидно. Исследование ETH гоняло каждую модель отдельно с одинаковым контекстным файлом, кейс "сгенерировал умной моделью, использовал дешевой" они вообще не тестировали. А это может быть тот самый сценарий где /init окупается.
Наверное правильнее сказать не "не генерируй через /init", а "сгенерируй, вычисти мусор, и не дублируй то что и так в конфигах лежит". Тут я погорячился в формулировке)

Romatio
14.03.2026 10:03Поддерживаю. На одном проекте указано, что локально развернут в докере, взаиможействует с микросервисами, claude code не задает тупых вопросов и сразу сам все видит.
На другом, мелком и простом, такого нет, и каждый раз приходится напоминать, что вот же все в докере, вот, смотри, лежит docker-compose. Каждый раз его пропускает. Но тут уже используется opencode с китайскими моделями, может, это и влияет.
pda0
Ну может если помощь в поиске AI не нужна, то использовать как каркас проекта? Типа такие файлы сюда, такие - сюда?
diffnotes-tech Автор
Ровно это исследование и проверяло - "такие файлы сюда, такие сюда" это и есть directory overview. И по данным ETH Zurich агент эту информацию игнорирует, потому что быстрее сам посмотрит через glob/grep чем читать описание.
Но если речь про новый проект где файлов еще нет - тогда да, без каркаса в CLAUDE.md агент будет складывать всё как ему вздумается. Тут контекстный файл работает не как навигация, а как constraint. Другой кейс, исследование его не покрывало.