Justin Reock: код менять легче, деплоить страшнее (Рубрика #AI4SDLC) Новый доклад Justin Reock из DX продолжает его старую линию из предыдущего доклада, где речь шла о том, как процессы и инструменты вокруг инженера влияют на результат внедрения AI. А в новом докладе "The State of AI in Software Development: Data from 400+ Orgs" заместитель CTO компании DX возвращается к этой теме. Его тезис: ускорение генерации кода ограничено тем, как устроена остальная разработка. В данных, которые приводит Reock, есть интересное расхождение: - Оценка поддерживаемости кода разработчиками выросла почти на 4%; - Уверенность в изменениях снизилась на 6%; - Средний размер PR вырос примерно с 44 до 72 строк. Это наблюдения DX, а первые два показателя — оценки самих инженеров. Они не доказывают, что AI стал причиной всех изменений. Главный тезис доклада "Код стало проще менять, но деплоить его спокойнее не стало" и для меня здесь интересен разрыв между локальным пониманием и уверенностью в поведении всей системы. Агент может объяснить функцию и помочь ее переписать. Дальше остаются вопросы: какие контракты мы затронули, что действительно проверяют тесты, какие зависимости вообще не попали в контекст? Красивое объяснение diff само по себе на них не отвечает. Reock приводит пример: AI мгновенно генерирует функции, а сборка по-прежнему занимает 45–60 минут. Возникает соблазн собрать изменения в один большой PR. Это гипотеза о механизме, а не установленная причина роста PR во всей выборке. Я бы здесь проверял, сколько работы мы перекладываем на следующего человека. Автор быстрее закончил свою часть, а ревьюеру теперь нужно восстановить логику нескольких изменений одновременно. Если проверка обнаружит проблему, сколько времени займет переделка? И останется ли выигрыш после нее? Без этих вопросов легко принять локальную экономию времени за улучшение всего процесса. Кстати, это хороший повод вернуться к фреймворку DX Core 4, который я уже разбирал. Там продуктивность рассматривается через speed, effectiveness, quality и impact. Для такого кейса я бы смотрел рядом на время прохождения PR, его размер, возвраты на доработку и сбои после выпуска. Опрос про уверенность тоже нужен: он помогает найти места, где команда боится менять код, даже если счетчик поставленных изменений растет. А техническая сторона уже была в разборе Max Kanat-Alexander про DevEx для агентов: быстрые предсказуемые тесты, понятные ошибки, документация с контекстом и управляемая нагрузка на ревью. Если агент часто запускает тесты, каждая лишняя минута ожидания повторяется вместе с этим циклом. Получается вполне предметный повод наконец заняться медленным CI:) При этом размер PR я бы не превращал в самостоятельный KPI. Можно нарезать одно связное изменение на десяток неудобных кусков и получить красивый график. Важно, может ли проверяющий понять замысел, проверить последствия и при необходимости откатить изменение. Поэтому после внедрения AI я бы задавал команде такой вопрос: мы стали быстрее доводить изменения до состояния, за которое готовы отвечать, или пока только быстрее наполняем очередь на проверку? P.S. На обложку конечно вынесен более провокационный вопрос:) #AI4SDLC #Engineering #DevEx #Productivity #Metrics #Management