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