Будущее AI в разработке ПО – интервью с CPO GitHub
Два дня назад вышло интересное интервью с CPO GitHub Инбал Шани от Ленни Рачински. Так как GitHub со своим Copilot для разработчиков — один из лидеров внедрения инноваций в кодинг, захотелось законспектировать основные мысли. Итак, вот они:
Заменит ли AI разработчиков. Счастье и продуктивность разработчиков сильно зависят от среды разработки и AI Copilot, встроенный в нее имеет здесь решающее значение. Около 92% разработчиков уже используют подобные инструменты в работе, но страхи о замене специалистов машинами преувеличены. Люди все-таки более творческие и понимающие, чем даже самые лучшие модели, более стратегически мыслящие. Просто люди будут отдавать AI простые задачи, а сами думать над общей картиной, архитектурой, модульностью. И джуниорам они конечно позволят быстрее погрузиться в продукт, основные модули, да и старших они будут отвлекать меньше, при этом генерируя неплохой код с помощником. Ну и конечно AI в разработке будет повсеместно.
Уже сейчас 37000 организаций и 1.5 миллиона разработчиков используют Copilot, при этом, по опросам, они пишут код на 55% быстрее, становятся на 85% увереннее в качестве кода и тестирование занимает на 15% меньше времени. В Accenture, например, код ревью прошло в итоге 88% сгенерированного кода. При этом сэкономленное время можно и нужно потратить на общение, творчество и инновации. Развитие AI ассистентов напоминает ситуации, когда все писали свои библиотеки и кучу кода для базовых вещей, а теперь многое есть прям в IDE, в новой версии какого-нибудь Python или скачивается одной кнопкой.
Чему уделяется меньше внимания, а зря. Тестированию с помощью AI. Информации мало, опыта мало, а ведь помощник может писать и модульные, и функциональные, и нагрузочные, и интеграционные тесты, порой даже лучше людей. Учитывая еще и что AI позволит генерировать больше кода в единицу времени, понадобится что-то сделать с другим узким горлышком — тестированием.
Какие ошибки совершают компании, внедряющие AI. Первое — думают, что изменения произойдут волшебным образом сами по себе, а ведь это огромное изменение парадигмы. И второе — пытаются везде запихнуть хоть какой-нибудь AI, не разбираясь, где вообще он нужен, а где — нет. Лучше сначала провести аудит своих типичных рабочих процессов, а потом обсудить с командами, где и каким образом можно использовать разные имеющиеся технологии. Если это будет насаждаться — вы просто заставите людей вас ненавидеть. Разработчики должны сами захотеть егоиспользовать.
Как тестируют новое. В первую очередь используют внутри компании, тот самый догфудинг. Сначала раскатывают внутри, потом — на клиентов. При этом дают время разработчикам на внедрение инноваций и эксперименты, которые могут и не взлететь, и это нормально. Тратят много времени на общение с пользователями, а также дают возможность описывать идеи и добиваться финансирования их прототипирования.
Команда GitHub Next — что это. Ученые-исследователи, которые работают вместе и на самом деле думают о горизонте трех-пяти лет, а не ближайшего года. Пишут статьи, проводят исследования, пробуют новые технологии. Но при этом не чистые теоретики, а работают вместе с основными командами Такой внутренний исследовательский университет с инкубатором.
Что думают о возможности программировать без знания кодинга. Думает, что это радикально ускорит коммуникацию и улучшит общение, потому что сократит время ожидания следующей итерации, особенно когда много неизвестного. Если продакт может сам сделать прототип и убедиться, что он имеет нужные свойства, сделать его в продакшн-качестве разработчику можно будет в 10 раз быстрее.
Любимый вопрос на собеседовании. Что является самым инновационным из того, что вы сделали, и почему, по вашему мнению, это инновационно?
Как стать CPO. Это должен быть руководитель, работающий и с продуктом и с бизнесом, лидер изменений, лидер команды в том числе. И учиться приходиться много, в том числе у людей, которые в чем-то лучше вас, просто для начала копируя их стиль и инструменты.
Самый большой фейл. Попытки просто прийти в работающий процесс с недостатками и с наскоку его изменить, не разобравшись, чего надо добиться, почему это происходит сейчас так, не замотивировав людей. В итоге конечно всё это обречено на провал.
3 книги, которые рекомендует. Failing Forward by John Maxwell, The Flywheel и Good to Great by Jim Collins, Dare to Lead Like a Girl by Dalia Feldheim.
Сериал. Весь невидимый нам свет
Девиз. Не будешь рисковать — не сможешь создать будущее.
P.S. Когда зарелизился OpenAI API и стало можно его внедрять в продукты (март-апрель 2023), мне посчастливилось поговорить с одним из членов команды общения с разработчиками из OpenAI. Я ему рассказал, как классно, всё, что они делают, и какие функции мы хотели внедрить в Wrike на базе API. Он посмотрел, что-то посоветовал, что-то подкорректировал, но сказал, что конечно люди пока не готовы к настоящим прорывным инновациям и такие небольшие шажки вперёд нужны, но глобально пора уже думать о новых рабочих отношениях, когда есть интеграция со всеми рабочими инструментами, и можно одним комментарием в рабочем чате «а кнопка тут должна быть левее» делать соответствующие коммиты в код, писать автотесты и сразу видеть результат. Тогда это казалось фантастикой, а сейчас мы кажется движемся именно в этом направлении. Удивительно время! Буду рад обсудить здесь или в телеграмме. Хороших вам выходных!
