У METR действительно есть апдейт от февраля 2026. Они уточнили, что результат 2025 года уже не стоит воспринимать как универсальный вывод про современные ИИ-инструменты.
Но я бы не называл это полным опровержением. Старый эксперимент был про конкретный момент времени и конкретные условия: early-2025 инструменты, опытные open-source разработчики и задачи в знакомых репозиториях. Позже инструменты стали сильнее, а эффект от ИИ мог измениться.
Плюс сами METR пишут, что свежие данные сложно трактовать из-за перекоса выборки: часть разработчиков и задач просто хуже попадает в эксперимент, потому что люди уже не хотят выполнять некоторые задачи без ИИ.
Для моей статьи ключевой тезис не в том, что «ИИ всегда замедляет». Я как раз пишу, что ИИ не бесполезен. Тезис другой: нельзя просто купить доступ к Copilot/Cursor/Claude и считать, что внедрение произошло. Нужны правила использования, ревью под ИИ-код и люди, которые на начальном этапе помогают встроить инструмент в процесс команды.
Да, согласен. Я бы тоже не отдавал ИИ роль архитектора, особенно там, где речь про связность данных, транзакции, маршруты, шины и состояние системы.
Для меня нормальная модель — ИИ как исполнитель на ограниченном участке: модуль, тест, адаптер, обработчик, кусок логики с понятным контрактом. Вход понятен, выход понятен, результат можно проверить. А архитектура, границы ответственности и критические решения остаются за человеком.
Но даже на уровне отдельного модуля важен не сам факт: «мы дали разработчику ИИ». Важно, чтобы в команде были правила, как именно этим ИИ пользоваться: что можно отдавать агенту, что нельзя, как формулировать задачу, где обязательна проверка человеком, какие решения нельзя принимать без архитектора или лида.
И вот это, на мой взгляд, часто недооценивает менеджмент. Доступ к Copilot, Cursor или Claude сам по себе не равен внедрению ИИ в разработку. На начальном этапе нужны отдельные люди в команде, которые будут этим заниматься: формировать правила, помогать разработчикам, смотреть первые PR, собирать типовые ошибки и постепенно встраивать ИИ в рабочий процесс.
То есть речь не о том, чтобы доверять ИИ больше. Наоборот — о том, чтобы ограничить его область применения и сделать использование управляемым. Иначе команда получает не ускорение, а новый слой чужого кода, только теперь сгенерированного.
Да, важное уточнение, спасибо.
У METR действительно есть апдейт от февраля 2026. Они уточнили, что результат 2025 года уже не стоит воспринимать как универсальный вывод про современные ИИ-инструменты.
Но я бы не называл это полным опровержением. Старый эксперимент был про конкретный момент времени и конкретные условия: early-2025 инструменты, опытные open-source разработчики и задачи в знакомых репозиториях. Позже инструменты стали сильнее, а эффект от ИИ мог измениться.
Плюс сами METR пишут, что свежие данные сложно трактовать из-за перекоса выборки: часть разработчиков и задач просто хуже попадает в эксперимент, потому что люди уже не хотят выполнять некоторые задачи без ИИ.
Для моей статьи ключевой тезис не в том, что «ИИ всегда замедляет». Я как раз пишу, что ИИ не бесполезен. Тезис другой: нельзя просто купить доступ к Copilot/Cursor/Claude и считать, что внедрение произошло. Нужны правила использования, ревью под ИИ-код и люди, которые на начальном этапе помогают встроить инструмент в процесс команды.
странно, вроде не ставил. может при модерации изменилось
Да, согласен. Я бы тоже не отдавал ИИ роль архитектора, особенно там, где речь про связность данных, транзакции, маршруты, шины и состояние системы.
Для меня нормальная модель — ИИ как исполнитель на ограниченном участке: модуль, тест, адаптер, обработчик, кусок логики с понятным контрактом. Вход понятен, выход понятен, результат можно проверить. А архитектура, границы ответственности и критические решения остаются за человеком.
Но даже на уровне отдельного модуля важен не сам факт: «мы дали разработчику ИИ». Важно, чтобы в команде были правила, как именно этим ИИ пользоваться: что можно отдавать агенту, что нельзя, как формулировать задачу, где обязательна проверка человеком, какие решения нельзя принимать без архитектора или лида.
И вот это, на мой взгляд, часто недооценивает менеджмент. Доступ к Copilot, Cursor или Claude сам по себе не равен внедрению ИИ в разработку. На начальном этапе нужны отдельные люди в команде, которые будут этим заниматься: формировать правила, помогать разработчикам, смотреть первые PR, собирать типовые ошибки и постепенно встраивать ИИ в рабочий процесс.
То есть речь не о том, чтобы доверять ИИ больше. Наоборот — о том, чтобы ограничить его область применения и сделать использование управляемым. Иначе команда получает не ускорение, а новый слой чужого кода, только теперь сгенерированного.