Ну да, собственно в этом и проблема. Accept нажал ты, но решение принимала модель, а разбираться потом тебе. Классический mismatch между тем кто авторизовал и кто понимает что происходит)
Я не говорю что джуны не нужны ) я говорю что их перестали нанимать. Это разные вещи. Данные по найму однозначные: entry-level вакансии упали на 35-67% в зависимости от рынка. Компании решили что не нужны, а правы они или нет - покажет время.
Аналогия с трактором не совсем работает тут. Когда пришел трактор, тракториста всё равно надо было учить - и его учили. А сейчас компании говорят "зачем учить тракториста если трактор сам ездит". Только он пока не совсем сам ездит, и через 3 года когда понадобятся трактористы - учить будет некого.
Парадокс Джевонса тут хорошо ложится, я про него не подумал когда писал. Если код станет дешевым ресурсом - его будут производить больше, и потребность в людях которые разбираются в этом коде только вырастет. Вопрос только в тайминге - разрыв между фазой "увольняем" и фазой "ищем со свечкой" может быть болезненным.
Про безопасность - это самый сильный аргумент по-моему. У Veracode 45% AI-кода содержит уязвимости, а атакующим достаточно одной. Асимметрия только растет. И тут промптер не поможет, нужен человек который понимает что происходит под капотом.
Сочувствую что оказался за бортом. Надеюсь ненадолго.
Ахах, git blame на самого себя это классика. Но тут хотя бы есть шанс что вспомнишь контекст - "а, точно, это я в пятницу вечером фиксил тот баг". С нейронкой ты даже этого не вспомнишь, потому что контекста принятия решения у тебя вообще не было. Ты просто нажал accept.
Ну да, сеньор никуда не девается. Имелось в виду что менеджер смотрит на бюджет и думает "зачем нанимать двух джунов если сеньор с подпиской закроет тот же объем задач". Подписка заменяет джунов, не сеньора. Формулировка все же в статье была неудачная, @blik13 правильно поправил)
Вот это ровно то что Anthropic называет "permanent beginners" - ты ревьюишь код, вроде понимаешь, но ментальная модель не строится потому что ты его не писал руками. Читать и писать это разные процессы для мозга, как ты и говоришь про лекции.
А про легаси переписанное нейронкой - тут даже хуже. Раньше хоть один человек помнил почему вот этот костыль тут стоит. Теперь никто не помнит, и в коде тоже не написано, потому что AI не оставляет комментарии "сделал так потому что API банка возвращает 500 по четвергам". У тебя получается код который работает по неизвестным причинам, и это по сути тот же техдолг только замаскированный.
Можно, если эффект большой и направление совпадает с другими данными. 16 человек - это не основа для policy decisions, согласен. Но когда субъективная оценка расходится с объективной на 39 п.п. - это как минимум повод копнуть дальше, что METR и сделали во втором раунде. Я же не пишу "доказано что AI замедляет", я пишу что люди переоценивают свой буст. И вот это подтверждается не только METR - тот же Uplevel на 800 разработчиках показал похожую картину с perceived vs actual productivity.
Это специально написано от лица менеджера который так думает, не как мой тезис. Дальше по тексту я как раз разбираю почему эта логика ломается - и про техдолг, и про talent doom cycle. Фраза утрированная, да, но менеджеры реально так рассуждают когда смотрят в табличку с костами. Собственно в этом и проблема.
По METR - да, 16 человек это мало, я согласен. Я специально написал что они запустили второй раунд, и там результаты уже другие (30-50% отказались работать без AI). Первый эксперимент я привожу не как доказательство что AI бесполезен - он явно не бесполезен - а как пример разрыва между ощущением и реальностью. Этот разрыв сам по себе интересен даже на малой выборке.
А насчет "не умели разрабатывать с AI" - там были опытные контрибьюторы в проекты с 22K+ звезд, не студенты. Но fair point, навыки работы с AI тоже скилл который тогда был у мало кого.
Основной тезис статьи вообще не про то что AI не работает. Он работает. Проблема в другом - что конвейер подготовки людей ломается пока все увлечены оптимизацией.
Спека в git, модель под ней обновляется. Один .cs.md файл на Opus 4.6 и на Opus 5 даст разный код. В roadmap написано "при удалении кода его можно восстановить из спецификации" - но из какой версии модели восстанавливать? Обычные компиляторы дают reproducible builds, тут каждое обновление модели потенциально меняет реализацию
Автор переключился на ChatGPT с теми же локальными файлами и получил посредственный результат. То есть проблема не в потерянных диалогах. Проблема в том что за месяцы подстроил стиль работы под конкретную модель - знаешь когда ей доверять, как формулировать, где перепроверять. Эта калибровка не экспортируется. Мультипровайдерность из выводов звучит разумно но на практике работать с двумя моделями одинаково глубоко мало кто будет
Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 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. Другой кейс, исследование его не покрывало.
Ну да, собственно в этом и проблема. Accept нажал ты, но решение принимала модель, а разбираться потом тебе. Классический mismatch между тем кто авторизовал и кто понимает что происходит)
Я не говорю что джуны не нужны )
я говорю что их перестали нанимать. Это разные вещи. Данные по найму однозначные: entry-level вакансии упали на 35-67% в зависимости от рынка. Компании решили что не нужны, а правы они или нет - покажет время.
Аналогия с трактором не совсем работает тут. Когда пришел трактор, тракториста всё равно надо было учить - и его учили. А сейчас компании говорят "зачем учить тракториста если трактор сам ездит". Только он пока не совсем сам ездит, и через 3 года когда понадобятся трактористы - учить будет некого.
Парадокс Джевонса тут хорошо ложится, я про него не подумал когда писал. Если код станет дешевым ресурсом - его будут производить больше, и потребность в людях которые разбираются в этом коде только вырастет. Вопрос только в тайминге - разрыв между фазой "увольняем" и фазой "ищем со свечкой" может быть болезненным.
Про безопасность - это самый сильный аргумент по-моему. У Veracode 45% AI-кода содержит уязвимости, а атакующим достаточно одной. Асимметрия только растет. И тут промптер не поможет, нужен человек который понимает что происходит под капотом.
Сочувствую что оказался за бортом. Надеюсь ненадолго.
Cправедливо, ссылки надо было ставить
Спасибо за замечание)
Ахах, git blame на самого себя это классика. Но тут хотя бы есть шанс что вспомнишь контекст - "а, точно, это я в пятницу вечером фиксил тот баг". С нейронкой ты даже этого не вспомнишь, потому что контекста принятия решения у тебя вообще не было. Ты просто нажал accept.
Ну да, сеньор никуда не девается. Имелось в виду что менеджер смотрит на бюджет и думает "зачем нанимать двух джунов если сеньор с подпиской закроет тот же объем задач". Подписка заменяет джунов, не сеньора. Формулировка все же в статье была неудачная, @blik13 правильно поправил)
Вот это ровно то что Anthropic называет "permanent beginners" - ты ревьюишь код, вроде понимаешь, но ментальная модель не строится потому что ты его не писал руками. Читать и писать это разные процессы для мозга, как ты и говоришь про лекции.
А про легаси переписанное нейронкой - тут даже хуже. Раньше хоть один человек помнил почему вот этот костыль тут стоит. Теперь никто не помнит, и в коде тоже не написано, потому что AI не оставляет комментарии "сделал так потому что API банка возвращает 500 по четвергам". У тебя получается код который работает по неизвестным причинам, и это по сути тот же техдолг только замаскированный.
Можно, если эффект большой и направление совпадает с другими данными. 16 человек - это не основа для policy decisions, согласен. Но когда субъективная оценка расходится с объективной на 39 п.п. - это как минимум повод копнуть дальше, что METR и сделали во втором раунде. Я же не пишу "доказано что AI замедляет", я пишу что люди переоценивают свой буст. И вот это подтверждается не только METR - тот же Uplevel на 800 разработчиках показал похожую картину с perceived vs actual productivity.
Это специально написано от лица менеджера который так думает, не как мой тезис. Дальше по тексту я как раз разбираю почему эта логика ломается - и про техдолг, и про talent doom cycle.
Фраза утрированная, да, но менеджеры реально так рассуждают когда смотрят в табличку с костами. Собственно в этом и проблема.
По METR - да, 16 человек это мало, я согласен. Я специально написал что они запустили второй раунд, и там результаты уже другие (30-50% отказались работать без AI). Первый эксперимент я привожу не как доказательство что AI бесполезен - он явно не бесполезен - а как пример разрыва между ощущением и реальностью. Этот разрыв сам по себе интересен даже на малой выборке.
А насчет "не умели разрабатывать с AI" - там были опытные контрибьюторы в проекты с 22K+ звезд, не студенты. Но fair point, навыки работы с AI тоже скилл который тогда был у мало кого.
Основной тезис статьи вообще не про то что AI не работает. Он работает. Проблема в другом - что конвейер подготовки людей ломается пока все увлечены оптимизацией.
Спека в git, модель под ней обновляется. Один .cs.md файл на Opus 4.6 и на Opus 5 даст разный код. В roadmap написано "при удалении кода его можно восстановить из спецификации" - но из какой версии модели восстанавливать? Обычные компиляторы дают reproducible builds, тут каждое обновление модели потенциально меняет реализацию
Автор переключился на ChatGPT с теми же локальными файлами и получил посредственный результат. То есть проблема не в потерянных диалогах. Проблема в том что за месяцы подстроил стиль работы под конкретную модель - знаешь когда ей доверять, как формулировать, где перепроверять. Эта калибровка не экспортируется. Мультипровайдерность из выводов звучит разумно но на практике работать с двумя моделями одинаково глубоко мало кто будет
Аргумент про чекпоинт дискавери сильный, я так на это не смотрел. Действительно, если агент каждый раз при новом контексте тратит 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. Другой кейс, исследование его не покрывало.