Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 15-20 tool calls на разведку - то закешировать это в файл логично, даже если качество самого кеша неидеальное.
Про Opus для дискавери + Haiku для работы - тоже валидно. Исследование ETH гоняло каждую модель отдельно с одинаковым контекстным файлом, кейс "сгенерировал умной моделью, использовал дешевой" они вообще не тестировали. А это может быть тот самый сценарий где /init окупается.
Наверное правильнее сказать не "не генерируй через /init", а "сгенерируй, вычисти мусор, и не дублируй то что и так в конфигах лежит". Тут я погорячился в формулировке)
Логично, да. В итоге получается что CLAUDE.md тут работает не как "подсказка для навигации" (которую исследование критикует), а как constraint - "сюда не лезь". И это ровно тот тип инструкций который по данным ETH реально помогает.
Ну и code review никто не отменял, согласен. Просто хочется чтобы агент не создавал лишнюю работу ревьюеру.
Ну я в статье старался это подчеркнуть - что success rate падает на LLM-сгенерированных файлах, а человеческие дают +4%. Но заголовок кликбейтный, да, виноват. Реальный вывод скорее "не генерируй через /init и не описывай то что агент сам найдет", а не "выкинь всё".
Интересный подход с мастер-репозиторием. По сути ты решаешь проблему которую исследование вообще не рассматривало - мультирепозиторная структура, где агент физически не видит соседние сервисы. Тут без явной онтологии он даже не узнает что они существуют.
С submodules правда может быть нюанс - агент полезет в submodule как в обычную папку и начнет там что-то менять, не понимая что это отдельный репозиторий со своим циклом. Не сталкивался с таким?
Про Java-энтерпрайз - хороший пример, в статье этого не хватает. Исследование ETH гоняли на open-source Python-репозиториях, где структура обычно плоская и агент за пару grep'ов всё находит. Корпоративный Java-проект с микросервисами, внутренними стартерами и кастомной инфраструктурой - совсем другая история, там без онтологии агент реально утонет в контексте раньше чем доберётся до нужного модуля.
Про внешние зависимости типа стартеров от центров компетенций - это вообще слепое пятно у обоих исследований. Агент не может загрепать то, о существовании чего он не подозревает. Тут контекстный файл не просто полезен, он необходим.
Аналогия с жуком мне нравится, но я бы чуть скорректировал - скорее исследование показало что жук летает и без инструкции по полёту, но только если он маленький. Большой корпоративный жук без карты не взлетит.
Оценку выставляет GPT-5.3 Codex - один из участников. LLM-оценщики стабильно предпочитают стиль кода своей семейки моделей, это известная проблема. Для контроля стоило прогнать оценку через Claude или Gemini параллельно - разница в баллах покажет насколько оценки зависят от судьи
Ровно это исследование и проверяло - "такие файлы сюда, такие сюда" это и есть directory overview. И по данным ETH Zurich агент эту информацию игнорирует, потому что быстрее сам посмотрит через glob/grep чем читать описание.
Но если речь про новый проект где файлов еще нет - тогда да, без каркаса в CLAUDE.md агент будет складывать всё как ему вздумается. Тут контекстный файл работает не как навигация, а как constraint. Другой кейс, исследование его не покрывало.
Да, тут справедливо - оба исследования гоняли агентов на существующих репозиториях, greenfield вообще не трогали. На пустом проекте агенту неоткуда вывести конвенции, и контекстный файл это по сути единственный источник правды. Там вопрос скорее не "нужен ли CLAUDE.md" а "достаточно ли его". По опыту - на greenfield лучше работает plan.md или спека перед каждой задачей, потому что контекстный файл статичный, а проект на старте меняется каждый час. Но данных по этому нет, только ощущения.
Про SDD согласен, валидация на каждом шаге снимает проблему "агент прочитал инструкцию и побежал не туда". По сути это тот же A/B тест pamelafox только встроенный в пайплайн.
lightContext: true на heartbeat отрезает историю разговора, агент видит только HEARTBEAT.md. Но в чеклисте написано "проверь срочное в текущих задачах" - а откуда он узнает задачи без контекста? Либо ты даёшь tools и он тратит вызовы чтобы вспомнить что происходит, либо heartbeat вслепую. Полезный heartbeat это скорее lightContext: false на длинном интервале типа 2-4h, а не lightContext: true каждые полчаса
Лицензии защищали не через суды а через экономику - переписать было дороже чем соблюдать. Маленький разраб никогда не засудит корпорацию, тут уже написали. Phoenix потратил месяцы на клон BIOS, окупалось только при огромных ставках. При $14 за lodash барьера больше нет, и неважно сатира это или нет
1.29% по JPlag - это сходство текста кода. Поведение при этом совпадает почти полностью, тот же API те же кодировки. Google v Oracle (2021) уже решили что реимплементация API это fair use. Тут логика та же - поведение повторили, код нет
Автор выбрал Claude частично за тариф $100/мес. Но сам же пишет что Claude тратит в 3-4 раза больше токенов на тех же задачах. На фиксированном тарифе это значит упрёшься в потолок в 3-4 раза быстрее
проверяет Draft Writer, но кто проверяет Critic? Если Draft Writer естественно вписал неверный факт, Critic с теми же слепыми пятнами скорее всего пропустит. Тот же паттерн в code review субагентах - ревьюер-LLM стабильно пропускает ошибки которые сам бы допустил. Три итерации Critic -> Draft Writer улучшают стиль и структуру, но фактические ошибки проходят через все три
ursorrules, copilot-instructions. Файлы в корне проекта где руками описываешь архитектуру, конвенции, что куда класть. AI читает при каждом запросе. По факту время переехало с написания кода на написание инструкций для того кто код пишет
700 дней по 10 минут это ~117 часов. Для русского FSI дает 1100 часов. Объясниться получилось - значит для базового уровня работает. Но это 10% от того что нужно для свободного владения. Собственно про это и статья - база да, fluency нет. А про регулярность согласен, тут Дуо реально сильнее всех AI-тьюторов
800 дней это серьезный страйк) и вот это ровно то что я имел в виду - Duolingo не про язык, а про привычку. И если привычка работает - отлично, это уже больше чем у 90% людей которые "хотят выучить язык". AI пока не умеет так цеплять
В текстовом чате - да, работает. А в Voice Mode нет, он продолжает разговор даже если ты сказал полную ерунду. Видимо чтобы не ломать flow. Можно попросить в системном промпте "поправляй меня" но по факту он всё равно пропускает большинство ошибок
Ну вот Voice Mode как раз для таких пауз между командировками мог бы пригодиться хоть какая-то разговорная практика. Другое дело что без реальных ставок мотивация так себе
Cправедливо, репетитор и правда заинтересован в процессе а не в результате - как и Duolingo собственно. Получается AI тут даже честнее, ему платишь подписку а не за час, ему всё равно сколько ты занимаешься
Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 15-20 tool calls на разведку - то закешировать это в файл логично, даже если качество самого кеша неидеальное.
Про Opus для дискавери + Haiku для работы - тоже валидно. Исследование ETH гоняло каждую модель отдельно с одинаковым контекстным файлом, кейс "сгенерировал умной моделью, использовал дешевой" они вообще не тестировали. А это может быть тот самый сценарий где /init окупается.
Наверное правильнее сказать не "не генерируй через /init", а "сгенерируй, вычисти мусор, и не дублируй то что и так в конфигах лежит". Тут я погорячился в формулировке)
Логично, да. В итоге получается что CLAUDE.md тут работает не как "подсказка для навигации" (которую исследование критикует), а как constraint - "сюда не лезь". И это ровно тот тип инструкций который по данным ETH реально помогает.
Ну и code review никто не отменял, согласен. Просто хочется чтобы агент не создавал лишнюю работу ревьюеру.
Ну я в статье старался это подчеркнуть - что success rate падает на LLM-сгенерированных файлах, а человеческие дают +4%. Но заголовок кликбейтный, да, виноват. Реальный вывод скорее "не генерируй через /init и не описывай то что агент сам найдет", а не "выкинь всё".
Интересный подход с мастер-репозиторием. По сути ты решаешь проблему которую исследование вообще не рассматривало - мультирепозиторная структура, где агент физически не видит соседние сервисы. Тут без явной онтологии он даже не узнает что они существуют.
С submodules правда может быть нюанс - агент полезет в submodule как в обычную папку и начнет там что-то менять, не понимая что это отдельный репозиторий со своим циклом.
Не сталкивался с таким?
3/4 кода на модерацию - и это ещё без реальных пользователей. Подожди пока начнут обходить правила, тогда понадобится читать то что Cursor написал
Про Java-энтерпрайз - хороший пример, в статье этого не хватает. Исследование ETH гоняли на open-source Python-репозиториях, где структура обычно плоская и агент за пару grep'ов всё находит. Корпоративный Java-проект с микросервисами, внутренними стартерами и кастомной инфраструктурой - совсем другая история, там без онтологии агент реально утонет в контексте раньше чем доберётся до нужного модуля.
Про внешние зависимости типа стартеров от центров компетенций - это вообще слепое пятно у обоих исследований. Агент не может загрепать то, о существовании чего он не подозревает. Тут контекстный файл не просто полезен, он необходим.
Аналогия с жуком мне нравится, но я бы чуть скорректировал - скорее исследование показало что жук летает и без инструкции по полёту, но только если он маленький. Большой корпоративный жук без карты не взлетит.
Оценку выставляет GPT-5.3 Codex - один из участников. LLM-оценщики стабильно предпочитают стиль кода своей семейки моделей, это известная проблема. Для контроля стоило прогнать оценку через Claude или Gemini параллельно - разница в баллах покажет насколько оценки зависят от судьи
Ровно это исследование и проверяло - "такие файлы сюда, такие сюда" это и есть directory overview. И по данным ETH Zurich агент эту информацию игнорирует, потому что быстрее сам посмотрит через glob/grep чем читать описание.
Но если речь про новый проект где файлов еще нет - тогда да, без каркаса в CLAUDE.md агент будет складывать всё как ему вздумается. Тут контекстный файл работает не как навигация, а как constraint. Другой кейс, исследование его не покрывало.
Да, тут справедливо - оба исследования гоняли агентов на существующих репозиториях, greenfield вообще не трогали. На пустом проекте агенту неоткуда вывести конвенции, и контекстный файл это по сути единственный источник правды. Там вопрос скорее не "нужен ли CLAUDE.md" а "достаточно ли его". По опыту - на greenfield лучше работает plan.md или спека перед каждой задачей, потому что контекстный файл статичный, а проект на старте меняется каждый час. Но данных по этому нет, только ощущения.
Про SDD согласен, валидация на каждом шаге снимает проблему "агент прочитал инструкцию и побежал не туда". По сути это тот же A/B тест pamelafox только встроенный в пайплайн.
lightContext: true на heartbeat отрезает историю разговора, агент видит только HEARTBEAT.md. Но в чеклисте написано "проверь срочное в текущих задачах" - а откуда он узнает задачи без контекста? Либо ты даёшь tools и он тратит вызовы чтобы вспомнить что происходит, либо heartbeat вслепую. Полезный heartbeat это скорее lightContext: false на длинном интервале типа 2-4h, а не lightContext: true каждые полчаса
Лицензии защищали не через суды а через экономику - переписать было дороже чем соблюдать. Маленький разраб никогда не засудит корпорацию, тут уже написали. Phoenix потратил месяцы на клон BIOS, окупалось только при огромных ставках. При $14 за lodash барьера больше нет, и неважно сатира это или нет
1.29% по JPlag - это сходство текста кода. Поведение при этом совпадает почти полностью, тот же API те же кодировки. Google v Oracle (2021) уже решили что реимплементация API это fair use. Тут логика та же - поведение повторили, код нет
Автор выбрал Claude частично за тариф $100/мес. Но сам же пишет что Claude тратит в 3-4 раза больше токенов на тех же задачах. На фиксированном тарифе это значит упрёшься в потолок в 3-4 раза быстрее
проверяет Draft Writer, но кто проверяет Critic? Если Draft Writer естественно вписал неверный факт, Critic с теми же слепыми пятнами скорее всего пропустит. Тот же паттерн в code review субагентах - ревьюер-LLM стабильно пропускает ошибки которые сам бы допустил. Три итерации Critic -> Draft Writer улучшают стиль и структуру, но фактические ошибки проходят через все три
ursorrules, copilot-instructions. Файлы в корне проекта где руками описываешь архитектуру, конвенции, что куда класть. AI читает при каждом запросе. По факту время переехало с написания кода на написание инструкций для того кто код пишет
700 дней по 10 минут это ~117 часов. Для русского FSI дает 1100 часов. Объясниться получилось - значит для базового уровня работает. Но это 10% от того что нужно для свободного владения. Собственно про это и статья - база да, fluency нет. А про регулярность согласен, тут Дуо реально сильнее всех AI-тьюторов
800 дней это серьезный страйк) и вот это ровно то что я имел в виду - Duolingo не про язык, а про привычку. И если привычка работает - отлично, это уже больше чем у 90% людей которые "хотят выучить язык". AI пока не умеет так цеплять
В текстовом чате - да, работает. А в Voice Mode нет, он продолжает разговор даже если ты сказал полную ерунду. Видимо чтобы не ломать flow. Можно попросить в системном промпте "поправляй меня" но по факту он всё равно пропускает большинство ошибок
Ну вот Voice Mode как раз для таких пауз между командировками мог бы пригодиться хоть какая-то разговорная практика. Другое дело что без реальных ставок мотивация так себе
Cправедливо, репетитор и правда заинтересован в процессе а не в результате - как и Duolingo собственно. Получается AI тут даже честнее, ему платишь подписку а не за час, ему всё равно сколько ты занимаешься