Автор: Игорь Акимов. Два дня назад вышло интересное интервью с 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 – что это. Ученые-исследователи, которые работают вместе и на самом деле думают о горизонте трех-пяти лет, а не ближайшего года. Пишут статьи, проводят исследования, пробуют новые технологии. Но при этом не чистые теоретики, а работают вместе с основными командами Такой внутренний исследовательский университет с инкубатором.

Что думают о возможности создания продуктов без знания кодинга.

Думают, что это радикально ускорит коммуникацию между продактами/аналитиками/дизайнерами и разработчиками, потому что сократит время ожидания следующей итерации, особенно когда много неизвестного. Если продакт может сам сделать прототип и убедиться, что он имеет нужные свойства, сделать фичу разработчику по нему вместо плохо проработанного ТЗ можно будет гораздо быстрее.

Любимый вопрос на собеседовании. Что является самым инновационным из того, что вы сделали, и почему, по вашему мнению, это инновационно?

Как стать CPO. Это должен быть руководитель, работающий и с продуктом и с бизнесом, лидер изменений, лидер команды в том числе. И учиться приходиться много, в том числе у людей, которые в чем-то лучше вас, просто для начала копируя их стиль и инструменты.

Самый большой фейл. Попытки просто прийти в работающий процесс с недостатками и с наскоку его изменить, не разобравшись, чего надо добиться, почему это происходит сейчас так, не замотивировав людей. В итоге, конечно, всё это обречено на провал.

3 книги, которые рекомендуют. Failing Forward by John Maxwell, The Flywheel и Good to Great by Jim Collins, Dare to Lead by Dalia Feldheim.

Сериал. Весь невидимый нам свет

Девиз. Не будешь рисковать – не сможешь создать будущее.

P.S. Когда зарелизился OpenAI API и стало можно его внедрять в продукты (март-апрель 2023), мне посчастливилось поговорить с одним из членов команды общения с разработчиками из OpenAI. Я ему рассказал, как классно, всё, что они делают, и какие функции мы хотели внедрить в Wrike на базе API. Он посмотрел, что-то посоветовал, что-то подкорректировал, но сказал, что конечно люди пока не готовы к настоящим прорывным инновациям и такие небольшие шажки вперёд нужны, но глобально пора уже думать о новых рабочих отношениях, когда есть интеграция со всеми рабочими инструментами, и можно одним комментарием в рабочем чате «а кнопка тут должна быть левее» делать соответствующие коммиты в код, писать автотесты и сразу видеть результат. Тогда это казалось фантастикой, а сейчас мы кажется движемся именно в этом направлении.

Удивительно время!