ИИ раздали — пользоваться не научили. Почему он не окупается

[GlukKazan]

Зачем здесь хаб "Ненормальное программирование"?

[Miller87]

странно, вроде не ставил. может при модерации изменилось

[netricks]

До тех пор, пока материалы по агентам постят в хаб "Ненормальное программирование", оно и будет восприниматься ненормально. И вообще, под агентов нужен отдельный хаб. Потому как даже хаб "Искуственный интеллект" - это не то.

[G4vni1L]

какой пользоваться, я через раз вижу вакансии от рекрутеров, которые забыли сменить placeholder-ы сегенеренные ИИ

[ch1971]

Самое мерзкое что делал это разгребание чужого кода. А тут получается будет работа в том чтобы разобраться в ИИшном коде и отловить хорошо спрятанные и совершенно неочевидные ошибки. Адская горбуха будет а не работа. И почему всё время советуют доверить ИИ полномасштабную картину и дать построить глобальный проект - по сути позиционируют его как архитектора. ИМХО логичнее его юзать на уровне джуна и давать писать функциональные модули типа "вещь в себе" которые можно протестить входными данными с предсказуемым результатом не заморачиваясь с тем что у него внутри а уже из модулей архитектор пусть собирает проект и пишет работу шин данных тоже сам. Доверять контролировать ИИ логичность и связность данных, маршруты и состояния транзакций я бы прям побоялся. Потом если на проекте в проде начнутся проблемы а ИИ разведёт руками то будет просто крах. Если рухнет модуль его можно както заглушить на время ремонта а если крякнет шина то это сурово

[Miller87]

Да, согласен. Я бы тоже не отдавал ИИ роль архитектора, особенно там, где речь про связность данных, транзакции, маршруты, шины и состояние системы.

Для меня нормальная модель — ИИ как исполнитель на ограниченном участке: модуль, тест, адаптер, обработчик, кусок логики с понятным контрактом. Вход понятен, выход понятен, результат можно проверить. А архитектура, границы ответственности и критические решения остаются за человеком.

Но даже на уровне отдельного модуля важен не сам факт: «мы дали разработчику ИИ». Важно, чтобы в команде были правила, как именно этим ИИ пользоваться: что можно отдавать агенту, что нельзя, как формулировать задачу, где обязательна проверка человеком, какие решения нельзя принимать без архитектора или лида.

И вот это, на мой взгляд, часто недооценивает менеджмент. Доступ к Copilot, Cursor или Claude сам по себе не равен внедрению ИИ в разработку. На начальном этапе нужны отдельные люди в команде, которые будут этим заниматься: формировать правила, помогать разработчикам, смотреть первые PR, собирать типовые ошибки и постепенно встраивать ИИ в рабочий процесс.

То есть речь не о том, чтобы доверять ИИ больше. Наоборот — о том, чтобы ограничить его область применения и сделать использование управляемым. Иначе команда получает не ускорение, а новый слой чужого кода, только теперь сгенерированного.

[mist56]

>Опытные разработчики с ИИ‑ассистентом нередко работают медленнее, а не быстрее. В рандомизированном эксперименте METR (июль 2025)

METR уже сам себя опроверг, а его всё цитируют в нейрослопе.

[Miller87]

Да, важное уточнение, спасибо.

У METR действительно есть апдейт от февраля 2026. Они уточнили, что результат 2025 года уже не стоит воспринимать как универсальный вывод про современные ИИ-инструменты.

Но я бы не называл это полным опровержением. Старый эксперимент был про конкретный момент времени и конкретные условия: early-2025 инструменты, опытные open-source разработчики и задачи в знакомых репозиториях. Позже инструменты стали сильнее, а эффект от ИИ мог измениться.

Плюс сами METR пишут, что свежие данные сложно трактовать из-за перекоса выборки: часть разработчиков и задач просто хуже попадает в эксперимент, потому что люди уже не хотят выполнять некоторые задачи без ИИ.

Для моей статьи ключевой тезис не в том, что «ИИ всегда замедляет». Я как раз пишу, что ИИ не бесполезен. Тезис другой: нельзя просто купить доступ к Copilot/Cursor/Claude и считать, что внедрение произошло. Нужны правила использования, ревью под ИИ-код и люди, которые на начальном этапе помогают встроить инструмент в процесс команды.