Чего разработчики ждут от AI?

Александр открывает очередной разбор из серии Developer Productivity for Humans — пару статей оттуда в подкасте уже обсуждали — и зовёт коллегу по Т-Банку Колю Бушкова. Тот работает в R&D-центре: направление называется R&D инженерной продуктивности, а метод — применять искусственный интеллект и машинное обучение, чтобы эту продуктивность поднимать, и заодно измерять её саму и спрос на конкретные фичи, потому что управлять тем, что не меряешь, нельзя. Статья, по словам Александра, летняя, 2024 года, и не техническая, а скорее концептуальная: инструменты в SDLC внедряют все, но спросить самих разработчиков, куда их полезнее встроить, часто забывают, — и авторы делают шаг назад. Коле она в целом понравилась, местами до очевидных вещей, под которыми он готов подписаться, но бросается в глаза, что текст очень метафоричный: метафоры, метафоры, метафоры.

Первая из них — приписываемая Генри Форду «быстрая лошадь»; в статье помечено, что фраза, скорее всего, не его, но суть важнее авторства: ни разработчики, ни любые другие участники продуктовых опросов не всегда готовы сказать, чего хотят, и слишком крупные изменения лучше проектировать, опираясь на пользователей будущего. Александру больше понравилась параллель с электричеством: когда-то все говорили про электрификацию, сейчас стадия та же — «давайте добавим сюда, давайте добавим туда», — а в итоге AI так или иначе будет сопровождать нас везде. Авторы из Google, и в первую очередь их интересует Google, но многое переносимо на другие крупные технологические компании, «даже вроде нашего Т-Банка». Локальная цель статьи — не дизраптивные продукты, которые строят на глобальном видении, а локальные изменения: спросить инженеров, где болит, убрать рутину и поднять Developer Experience, который, по мнению Коли, тянет за собой и продуктивность.

Метод авторов в статье дуальный: ежеквартальные опросы плюс логи того, как инженеры действительно пользуются инструментами. Рядом оказываются ощущение — каково это, когда ассистент помогает с ревью или предлагает тесты, — и объективная метрика вроде доли принятых подсказок; третьим слоем идут интервью, чтобы понять, почему человеку не нравится ассистент: то ли он предлагает не то, то ли человек в принципе против изменений. В Т-Банке практикуют то же самое, данных собрано достаточно, чтобы на них опираться, и гибрид опросов с объективными данными — лучшее, что есть; в разговоре звучит формула: объективность — это хорошо организованная субъективность. А за такими статьями, напоминает Александр, стоит команда исследователей человек на 152 — точнее он не помнит, — которая скорее оптимизирует, чем делает революцию: вдвое больше инфраструктуры ускоряет сборку не вдвое, а процентов на 15–20, и дальше начинается экономическая задачка.

Дальше — трёхуровневая модель: ассистирование текущим возможностям, их расширение и полное делегирование работы машине, объяснённая в статье через автомобили. Антиблокировочная система тормозит так, как человек в экстренной ситуации не умеет, и это аналог автодополнения кода: инлайн- и блочные подсказки уже неплохо работают и в Т-Банке, и на рынке в целом, а сценарий начал развиваться ещё до момента GPT, на моделях поколения GPT-3. Здесь мы сейчас и находимся, постепенно переходя на второй уровень — как мониторинг слепых зон и парктроники, которые компенсируют физические ограничения человека. Для кодовых ассистентов это ревью и подсказки в CI-пайплайне, с которыми в компании как раз экспериментируют. Ревью — большая задача со множеством параметров, и важно прицелиться: где нужны модели, где хватает статических анализаторов и линтеров, а где лучше оставить решение человеку, которого в обозримой перспективе не исключают, а лишь минимизируют его участие.

Александр вспоминает распечатанную статью Google, где комментарии в ревью по-прежнему пишут люди, но автор изменений получает вместе с комментарием и предложение, как его реализовать: переименовать, использовать другое. Похожее есть и в Т-Банке — комментарий про уязвимость оставляет анализатор, а исправление предлагает модель, — правда, нынешнее название продукта Александр не вспомнил. Коля соглашается, что это, наверное, одно из наиболее зрелых решений в категории код-ревью, но команда ориентируется на более свежую работу другой крупной технологической компании: там таксономия тем ревью с четырьмя верхнеуровневыми направлениями, одно из которых — уязвимости в коде; ссылку решают приложить к выпуску. Уязвимости в статье названы важным блокером внедрения: сгенерированный код выходит более уязвимым, а уверенности в его надёжности у людей при этом больше. Найти уязвимость сейчас сложнее, чем исправить: с исправлением модели в целом справляются, и ставка тут на то, что они умнеют.

Всё это, добавляет Александр, работает там, где есть гардрейлы зрелых процессов: статический анализатор, разбирающий синтаксические деревья, а не текст, и тесты всех видов, через которые можно прогнать сгенерированную версию и убедиться, что хуже не стало. У формальных проверок, отвечает Коля, есть потолок: часть того, на что смотрят люди в ревью, в линтер не формализуется, — и если на большой выборке модель обходит анализатор, её стоит поставить вместо него даже ценой интерпретируемости, но без офлайн-метрик внедрять никто не даст. Топ-3 проблем продуктивности в Google — технический долг, плохая документация и изучение новой платформы; долг слишком плохо определён, чтобы браться за него целиком, и в разборе с Димой Гаевским звучало, как Google декомпозировал его и за три-четыре года увёл в опросах с первого места на средний уровень. С документацией беда не в поиске, а в том, что лучшие описания пишут не авторы системы, а те, кто с ней интегрировался: отсюда ставка на чат поверх проиндексированной базы, который умеет отказаться от ответа, — залогированные вопросы превращаются в план по документации.