Является ли генерация кода ИИ эпохой промышленной революции для предприятий, занимающихся разработкой программного обеспечения?

Является ли генерация кода ИИ эпохой промышленной революции для предприятий, занимающихся разработкой программного обеспечения?

3 января 2024 г.

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

В наш информационный век спрос на цифровые продукты находится на пике, и, следовательно, технологическая отрасль находится под огромным давлением, требующим массового выпуска своих продуктов и усовершенствований для завоевания значительной доли рынка. Разработчикам приходится жить с постоянным спросом на выпуск продуктов. Как показано в колесе телеги, разработчики уделяют кодированию только 25% своего времени, стремясь к состоянию потока, сродни артистизму. Технологическая индустрия сталкивается с проблемами повышения общей производительности разработчиков, и, по-видимому, это стало самым шокирующим открытием для директора по вопросам разработки Github Инбала Шани.

В этой статье рассматриваются стратегии, позволяющие усилить влияние этих важнейших 25 %, а также способы повышения производительности в ограниченные сроки написания кода.

С появлением кода LLM, таких как CodeT5, CodeLlama, Star Программисты и т. д., все техническое сообщество обсуждает и внедряет инновации, чтобы сделать «время кодирования» для разработчиков более эффективным, и это захватывающее время наблюдать, куда движется попутный ветер генерации кода с использованием GenAI и как это повлияет на более быстрая смена кода. Давайте сегментируем и попытаемся найти ответы, чтобы лучше понять всю эту ситуацию, по этим общим вопросам:

* Какую проблему для разработчиков решают инструменты генерации кода?

* Какие команды разработчиков считают это серьезной проблемой?

* Какие существуют решения и как они решают вышеуказанную проблему?

* Каковы возможные способы измерения эффективности этих инструментов в жизненном цикле разработчика?

1. Какую проблему для разработчиков решают инструменты генерации кода?

В пределах 25% «времени на код» почти половина времени разработчика уходит на написание основной бизнес-логики (что является настоящим искусством), в то время как остальная часть его времени занята рефакторингом артефактов кода из его предыдущей работы. , написание базовых шаблонов, написание моделей баз данных (если таковые имеются), базовая проверка и утилиты для общих сценариев использования и т. д.

Учитывая количество времени, затрачиваемое на написание тривиальных потоков, если эти инструменты генерации кода смогут сэкономить хотя бы половину времени компаний и разработчиков, то это может улучшить общий опыт разработчиков и улучшить их качество. производительность. Один из последних обзорных отчетов McKinsey отражает мнение сообщества разработчиков, которое твердо убеждено в том, что по крайней мере 30-35% всего времени, затраченного на написание, документирование и рефакторинг кода, можно сэкономить с помощью новейших моделей Gen AI для генерации кода и связанных с ними решений. .

2. Какие возможные решения сейчас доступны на рынке?

С появлением более совершенных моделей LLM появилось множество компаний, которые решают проблему генерации кода. Некоторые из этих решений либо распространяются путем интеграции с IDE (VS Code, IntelliJ и т. д.), такими как Codium, Sourcegraph, Tabnine, GitHub Copilot и т. д.; с другой стороны, мало кто ориентирован на браузерные редакторы кода, такие как replit.

Поскольку все эти решения представляют естественный язык как новый интерфейс программирования и генерации кода, качество генерируемого кода напрямую зависит от предоставленной подсказки и контекста; в настоящее время такие игроки, как GitHub, имеют максимальное преимущество по сравнению со всеми новыми участниками из-за большого количества кода. База данных, на которой он работает, и развитие модели OpenAI, новый участник по-прежнему будет иметь преимущество, если он будет тесно сотрудничать с предприятиями и решать проблемы безопасности и конфиденциальности, которые были ключевыми для GitHub Copilot, как и действующий игрок. Недавние отчеты Accenture выглядят многообещающе для космоса, а с недавним объявлением о доступности чата второго пилота на GitHub масштабы инноваций в этих решениях для генерации кода широко открываются.

3. Какие разработчики применяют такие решения?

Среди корпоративных инструментов генерации кода GitHub CoPilot занимает первое место: почти 37 тысяч предприятий используют его в своем рабочем процессе и имеют более 1,5 миллиона активных разработчиков, в то время как разработчики, работающие в корпоративных или стартап-командах, в основном проголосовали за использование инструментов генерации кода полезен, потому что:

* Повторяющиеся и избыточные изменения кода, связанные с меняющимися требованиями пользователей, могут быть быстро реализованы.

* Сокращение необходимости написания стандартного кода для быстрого прототипирования.

* Эффективное сотрудничество между командами для создания PR, проверки и других подобных вариантов использования.

* Сокращено время на подключение нового разработчика.

Если GitHub Copilot активно внедряется среди корпоративных команд, значительная часть трафика разработчиков также использует эти инструменты генерации кода для изучения новых навыков кодирования или изучения базовых основ программирования. Это можно увидеть по возросшему использованию replit.com за последние несколько месяцев: около 3-5 миллионов активных разработчиков ежемесячно посещают эти инструменты [src -likeweb.com]. Недавний опрос GitHub также дает четкое представление о случаях использования, в которых разработчики чаще всего используют эти инструменты.

4. Каковы возможные способы измерения эффективности этих инструментов в жизненном цикле разработчика?

Мы начали эту дискуссию с того, что в центре внимания оказалась производительность разработчиков и то, как эти решения могут сократить «время написания кода» и помочь разработчикам быстрее выпускать код, но в индустрии программного обеспечения сложно измерить эффективность и рентабельность инвестиций только с точки зрения времени из-за Это субъективная количественная оценка, но могут быть и другие косвенные способы, которые команды разработчиков и руководители инженеров могут использовать для измерения рентабельности инвестиций и эффективности:

* Измерение относительных изменений показателей DORA с помощью таких инструментов, как LinearB, Middleware HQ и т. д., а также других инструментов с открытым исходным кодом, таких как ApacheDevLake.

* KLOC (строка кода), созданная с помощью этих инструментов, уже запущена в производство.

* Относительное изменение рейтинга Developer Experience.

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

Путь вперед

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

В книге «Мифический человеко-месяц» программист Фред Брукс заметил, что простое добавление ресурсов в большой программный проект не ускоряло его, а в большинстве случаев только ухудшало ситуацию.

Пока не ясно, поможет ли ИИ в планировании и управлении проектом или сократит общие усилия, необходимые для большого проекта по программированию, но как программист я могу ручаться за то, что «подсказка о кодировании» определенно будет, в той или иной форме. увидеть массовое внедрение в сфере разработки программного обеспечения.


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE