Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Ну может если помощь в поиске AI не нужна, то использовать как каркас проекта? Типа такие файлы сюда, такие - сюда?
Ровно это исследование и проверяло - "такие файлы сюда, такие сюда" это и есть directory overview. И по данным ETH Zurich агент эту информацию игнорирует, потому что быстрее сам посмотрит через glob/grep чем читать описание.
Но если речь про новый проект где файлов еще нет - тогда да, без каркаса в CLAUDE.md агент будет складывать всё как ему вздумается. Тут контекстный файл работает не как навигация, а как constraint. Другой кейс, исследование его не покрывало.
По-моему, ситуация для greenfield и brownfield проектов кардинально различается. Если во втором случае агент и может вывести структуру проекта, конвенции и пр. из кода - то в первом это всё для него - необходимые вводные. Ну и да, недостаточно просто дать ему инструкцию, надо вводить в воркфлоу этапы, на которых всё, что сделал агент, проверяется на соответствие этим принципам, и правится до момента, когда конфликтов не будет. SDD фреймворки в помощь, ну или свой велосипед.
Да, тут справедливо - оба исследования гоняли агентов на существующих репозиториях, greenfield вообще не трогали. На пустом проекте агенту неоткуда вывести конвенции, и контекстный файл это по сути единственный источник правды. Там вопрос скорее не "нужен ли CLAUDE.md" а "достаточно ли его". По опыту - на greenfield лучше работает plan.md или спека перед каждой задачей, потому что контекстный файл статичный, а проект на старте меняется каждый час. Но данных по этому нет, только ощущения.
Про SDD согласен, валидация на каждом шаге снимает проблему "агент прочитал инструкцию и побежал не туда". По сути это тот же A/B тест pamelafox только встроенный в пайплайн.
Я не знаю как они делали это исследование, но это прямо противоречит моим прямым наблюдениям. Контекст - среднего размера Java-проект в корпоративной среде. Без заранее собранной отнологии проекта - любая задача начинается: "ах, давайте посмотрим на pom.xml; ах - давайте посмотрим примеры контроллеров... нет давайте посмотрим еще больше контроллеров чтобы понять эндпоинты; теперь давайте посмотрим бизнес-логику... нет давайте посмотрим больше бизнес логики... а еще посмотрим DTO" - и так уже бОльшая часть контекста кончилась. После появления файла онтологии - агент сразу идет в ту часть проекта, куда ему положено было бы идти - и там читает файлы для конкретной задачи.
А еще - если у вас микросервисы, то вы должны дать агенту понимание что существует часть проекта вне его контроля, но с которой он взаимодействует. А еще - не дай бог в вашей корпоративной структуре есть разнообразные центры компетенций, которые вас снабжают шаблонами инфраструктуры и спринг-бут стартерами (которые агент в глаза не видел, и даже не подозревает об их существовании).
В общем, это исследование - из серии "аэродинамики ЦАГИ после длительных продувок установили, что майский жук не способен к самостоятельному полету" (C).
Про Java-энтерпрайз - хороший пример, в статье этого не хватает. Исследование ETH гоняли на open-source Python-репозиториях, где структура обычно плоская и агент за пару grep'ов всё находит. Корпоративный Java-проект с микросервисами, внутренними стартерами и кастомной инфраструктурой - совсем другая история, там без онтологии агент реально утонет в контексте раньше чем доберётся до нужного модуля.
Про внешние зависимости типа стартеров от центров компетенций - это вообще слепое пятно у обоих исследований. Агент не может загрепать то, о существовании чего он не подозревает. Тут контекстный файл не просто полезен, он необходим.
Аналогия с жуком мне нравится, но я бы чуть скорректировал - скорее исследование показало что жук летает и без инструкции по полёту, но только если он маленький. Большой корпоративный жук без карты не взлетит.
Да даже на python, если проект не тривиальный REST сервис, будет фронт, мб отдельные воркеры, отдельные микросервисы и тд.
Я пришел к тому, что для подобного создал мастер репозиторий с понятной структурой, в него через submodule добавил компоненты и в мастер проекте завел доки с онтологией проекта. Почему так? Потому что тогда в доках понятно от какого корня писать пути до конкретных файлов (и это становится справедливо для всех частей проекта).
Интересный подход с мастер-репозиторием. По сути ты решаешь проблему которую исследование вообще не рассматривало - мультирепозиторная структура, где агент физически не видит соседние сервисы. Тут без явной онтологии он даже не узнает что они существуют.
С submodules правда может быть нюанс - агент полезет в submodule как в обычную папку и начнет там что-то менять, не понимая что это отдельный репозиторий со своим циклом.
Не сталкивался с таким?
Это прописывается в инструкциях в README.md и AGENTS.md/CLAUDE.md
В крайнем случае - ты же увидишь это на ревью кода (блокировки мастер веток для пуша для этого и созданы).
Логично, да. В итоге получается что CLAUDE.md тут работает не как "подсказка для навигации" (которую исследование критикует), а как constraint - "сюда не лезь". И это ровно тот тип инструкций который по данным ETH реально помогает.
Ну и code review никто не отменял, согласен. Просто хочется чтобы агент не создавал лишнюю работу ревьюеру.
Ну да, беда таких исследований - они не объясняют понятным языком границу применимости. В результате - народ воспринимает это как инструкцию "не писать AGENTS.md". :-(
Ну я в статье старался это подчеркнуть - что success rate падает на LLM-сгенерированных файлах, а человеческие дают +4%. Но заголовок кликбейтный, да, виноват. Реальный вывод скорее "не генерируй через /init и не описывай то что агент сам найдет", а не "выкинь всё".
Да нет же! Генерация онтологии через /init - вполне годная вещь! Поймите, агент так устроен что он будет делать дискавери в пустом контексте. И на это дискавери он потратит очень ценные токены в начале контекста. У него начало контекста будет забито разными тул-коллами, причем часть файлов ему нафиг не нужна для работы - но он прочитал и развидеть уже не может. А вы через /init делаете чек-поинт дискавери, и при последующих запусках он СРАЗУ считает это чекпоинт, и будет тратить контекст на задачу. Это как минимум - большая экономия токенов (ибо результат дискавери будет переиспользован столько раз, сколько вы сбросите контекст)
Я уж не говорю, что вы дискавери можете хорошо провести дорогой моделью (например Opus), а потом результат использовать дешевыми моделями. Которые в принципе не способны на качественный дискавери - и вместо этого нафантазируют себе всякое, а потом пойдут на основании этого чего-то править (тот же Haiku)...
Так что нет - онтология при реальной работе важна и нужна. Внимательно посмотреть и почистить после автогенерации - конечно нужно. Но даже автоматическая - сильно лучше чем отсутствие таковой (в реальной жизни, не в исследовании!).
Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 15-20 tool calls на разведку - то закешировать это в файл логично, даже если качество самого кеша неидеальное.
Про Opus для дискавери + Haiku для работы - тоже валидно. Исследование ETH гоняло каждую модель отдельно с одинаковым контекстным файлом, кейс "сгенерировал умной моделью, использовал дешевой" они вообще не тестировали. А это может быть тот самый сценарий где /init окупается.
Наверное правильнее сказать не "не генерируй через /init", а "сгенерируй, вычисти мусор, и не дублируй то что и так в конфигах лежит". Тут я погорячился в формулировке)
Поддерживаю. На одном проекте указано, что локально развернут в докере, взаиможействует с микросервисами, claude code не задает тупых вопросов и сразу сам все видит.
На другом, мелком и простом, такого нет, и каждый раз приходится напоминать, что вот же все в докере, вот, смотри, лежит docker-compose. Каждый раз его пропускает. Но тут уже используется opencode с китайскими моделями, может, это и влияет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваш CLAUDE.md делает агента тупее. Исследование на 138 репозиториях это доказало