Всем привет! Если посмотрите на моей странице предыдущий пост, то увидите моё выступление против бездумного использования ИИ в работе. Хотел бы выдать небольшую сводку по тому, что произошло с тех пор.

За последние полгода я столкнулся с совершенно разными способами использования агентов в работе, причём от сотрудников разного уровня. Самый ужасный вариант, за который я буду вечно осуждать вас, каким бы высоким рангом вы ни обладали: копипаста ответа агента в почту. Я прошу, хотя бы посмотрите, что он там написал, и не выдавайте его мнение за своё. Особенно это касается сравнительных таблиц. Агент выдаст вам матрицу с десятком столбцов и строк сравнения, основная часть которых будет просто мусором и дублированием одной и той же информации. А ещё в этих таблицах будут пункты, в которых вы вообще не разбираетесь, но вы всё равно присылаете это как аналитику для решения задачи в компании.

Мой опыт Вопреки всем «прогрессивным» подходам ведения проектов при помощи ИИ, я всё ещё стараюсь оставаться где-то посередине. Говорить я буду только за ведение проектов в ИТ и саму разработку. Другие сферы затрагивать не могу, не имею опыта.

1. Роль PO/PM/BA С этой точки зрения стандартный подход бигтеха (проработка всех эпиков, юзерстори, аналитики целесообразности проекта и метрик) сразу отпадает. В моём процессе это встроить крайне сложно, потому что запрос поступает в формате «надо сделать и точка». Так что любая идея сразу попадает в проектирование и разработку.

2. Проектирование Тут я встречал высказывание: «ИИ это все навыки человечества, собранные в одном месте, которые работают быстро. И багаж знаний ИИ изначально больше любого специалиста». В этих словах есть буквы. НО. К сожалению, ни один агент не сможет корректно спроектировать систему, ни с точки зрения UX/UI, ни с технической. Он предложит усреднённое решение, которое для одних продуктов будет избыточным, а для других недостаточным. Именно поэтому в своей работе мы ежедневно редактируем наш харнесс своими скиллами. Без них у вас даже с GPT Astra будет энтерпрайз-приложение, написанное в одном файле на 20 тыс. строк, и шаблонный дизайн с фиолетовыми кнопками и градиентами. Скиллы с гитхаба это круто, но имеет смысл хотя бы базово прогонять их через сервисы проверки на инъекции, а лучше писать самому, что мы и стараемся делать. Главное не переборщите: не только дополняйте инструкции, но и удаляйте. С обновлениями они существенно замедляют агентов и создают излишний контекст.

3. Архитектура и оверинжиниринг В остальном есть один спорный аргумент, который я услышал и считаю по большей части верным. Речь про архитектуру, оверинжиниринг и плохой код.

Главная боль отдела разработки: каждый новый разработчик считает код предыдущего ужасным, не может в нём разобраться и переписывает его с нуля. Это повторяется всегда и во всех командах.

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

4. Написание кода И самое главное, уходящее в прошлое: НАПИСАНИЕ КОДА. Тут могу со 100% уверенностью сказать: если ты сегодня разработчик и пишешь самостоятельно больше 30% кода, с этим надо что-то делать, причём срочно. Больше двигайтесь к проектному мышлению, а не держитесь за подробные юзерстори в трекере. Об этом говорят на многих конференциях бигтеха: их команды меняются и переходят на владельца продукта с техническими скиллами, который всё больше отвечает за ведение проекта как PO, а не как разработчик. Можно сравнить это с промышленной революцией. Теперь у вас есть станок, который создаёт вам код, и ваше дело научиться с ним работать, это теперь основной хардскилл. А ручная разработка станет разработкой ювелирки на заказ: это дорого и для богатых :)

Буду рад Вашему мнению в комментариях, в конце года постараюсь сделать сводку по результатам ИИ разработки 2026.

Ну и по классике всхе постов тут нейрослоп-картинка