ИИ-апокалипсис: не ждать, а готовиться? Наблюдаем, как англоязычное инфополе штормит после нашумевшего эссе от Мэтта Шумера про то, как весь офисный люд заменит ИИ. Кто-то уже мысленно распустил команды. В свете этих событий передаем слово Владимиру Кондратьеву, PDE Облакотеки. Он предлагает убавить градус апокалипсиса и включить здравый смысл. ⏪ В эссе есть сравнение с началом 2020 года, когда многие продолжали жить обычной жизнью, а перемены, которые принес нам ковид, прошли ураганом по многим отраслям и людям. Автор предлагает не ждать, а быть готовым к буму ИИ, не заблудиться и не отстать. На мой взгляд, он переоценивает степень готовности к полной автономности, когда ИИ создает новые версии себя сам. То есть предложение «не ждать» верно, а вот впадать в панику и принимать резкие решения — опрометчиво. Реальный проект не ограничивается написанием кода. Это и постоянно меняющиеся требования заказчика, и интеграции, и поиск ошибок, и контроль качества. ИИ быстро пишет код, но без правильной обратной связи может так же быстро сделать не то. Это очень наглядно показано в истории моего знакомого тестировщика: Он работал в интернет-проекте над закрытой социальной сетью с небольшой командой разработки. Он был единственным тестировщиком и отвечал за весь процесс QA. Руководитель компании долго экспериментировал с ИИ: сначала использовал для генерации иллюстраций и текстов, затем начал применять для внесения изменений в код, которые потом проходили через разработчиков и тестирование. В какой-то момент руководитель решил, что ИИ способен заменить большинство специалистов. Поэтому однажды вечером сотрудников собрали и объявили, что с завтрашнего дня команда распускается: оставили только DevOps-специалиста и тимлида, а дизайн, аналитику, разработку и тестирование планировалось закрыть силами ИИ и самого руководителя. После увольнений процесс разработки пошел по новой схеме: изменения, сгенерированные ИИ, начали внедрять пакетами, без полноценного code review и тестирования. По словам моего знакомого, еще раньше было заметно, что такой код сложнее проверять — он часто содержал множество лишних правок, не связанных напрямую с задачей. Итак, через пару недель после перехода на новую модель работы произошел серьезный сбой: изменения выкатили в продакшн вечером в пятницу, на тестовой среде все выглядело рабочим, но на боевом сервере система упала. Попытки отката не помогли, и сайт оставался недоступен более суток — как раз в период повышенной активности пользователей. В итоге в срочном порядке пришлось возвращать ранее уволенных специалистов: сначала backend-разработчиков, чтобы восстановить работоспособность, а затем и фронтов, поскольку стало понятно, что ИИ не учитывает архитектурный контекст, старые обходные решения, старые костыли и особенности проекта. Вернувшиеся разработчики фактически занялись анализом и исправлением кода, который генерировал ИИ. Аналитика и тестировщика пока не вернули, но это — пока … Здесь ключевой ошибкой стала замена людей без изменения процессов управления качеством. Самое дорогое обычно не написать, а безопасно встроить и при этом не сломать. Ошибки стоят денег и репутации, поэтому нужен владелец решения, а ИИ владельцем быть не может. ❓ Тогда где ИИ действительно уместен? Везде, где важны скорость и «объем» при понятных критериях результата. Например, быстро набросать черновик кода, сделать типовые изменения и аккуратный рефакторинг, помочь с автотестами и так далее. Разгрузив команду от рутины, вы скоро увидите, что задачи на развитие выполняются быстрее. Также ИИ очень хорош для обучения, расширения кругозора и хобби. А вот туда, где цена ошибки высока, ИИ лучше не подпускать без жесткого человеческого контроля. Особенно ко всему, что связано с безопасностью, платежами и персональными данными. ИИ ускоряет и помогает, но контекст и ответственность за решения остаются у человека. Если перефразировать один из ключевых принципов Фирмы 1С: используйте ИИ, но думайте своей головой ⏩. #искусс