LLM в разработке ПО — мнение
Данная заметка написана по итогам нескольких месяцев попыток работы с ChatGPT и Github Copilot в связке c Visual Studio Code.
Работа с легаси
Удар молотком - 1 доллар. Знал, куда ударить - 9999 долларов. Итого за услуги - десять тысяч долларов. (с) Из старого анекдота
Github copilot не так давно стал резко полезнее благодаря команде workspace, позволяющей прикрутить к системе проект целиком и отвечать именно на основе знаний об этом конкретном проекте:
Это просто прекрасно. Как-то нам понадобилось добавить новую фичу в проект, с которым уже давно никто не работал. Я просто опробовал на нем workspace с вопросом, как мне это сделать. Система сразу указала мне, в какой файл надо заглянуть, и какую функцию добавить туда.
Плюсы. Резко снижает затраты на знакомство с новыми проектами и на онбоардинг.
Минусы. Их два:
С большими проектами (т.е. с большим размером кодовой базы) оно не работает. При попытке подгрузки зависает. Но это скорее вопрос не к Copilot, а к исходному проекту. Если его писали двадцать лет подряд как монолит, и не разделяли кодовую базу вообще никак, то Copilot тут (пока) не поможет.
Юридический момент. Он не предоставлял проблемы для меня, но, общаясь с менеджерами из разных контор, я обратил внимание, что они зачастую думают, что с приобретением лицензии enterprise на пользование copilot получают локальную версию, которая работает строго внутри конторы. Это не так, в чем можно убедиться, прочитав соглашение этой лицензии, а также просто попробовав поработать на основе этой лицензии, отключив сеть на машине. То есть плагин copilot производит отправку фрагментов кода на сервера Github. Microsoft лишь обязуется по этой лицензии НЕ использовать Ваши фрагменты для обучения своей сетки (т.е. что ваш код не будет выдан как пример другим на их запросы) и что Microsoft несет юридические риски в случае утечки Вашего кода на сторону. Это не то же самое, что локальный плагин внутри защищенного периметра компании. А команда workspace делает весьма легким процесс отправки всего кода проекта на сторонние сервера, пусть и по частям. Технически админы этих серверов могут восстановить Ваш проект у себя. Поэтому убедитесь, что Ваши разработчики используют enterprise лицензию для своих проектов, а не триальную. А заодно убедитесь, что Ваша контора не попадает под какое-либо правило регуляторов, строго-настрого запрещающих публиковать свой код вообще, пусть и таким интересным способом.
Галлюцинации
Да, галлюцинации имеют место быть. И дело тут не только в курьезных случаях вроде этого:
Скорее речь идет о потере контекста по ходу беседы. Например, один коллега в качестве пет-проекта делал скраппер одного сайта. Делал он его на основе BeautifulSoup. Он достаточно быстро написал обработку основных элементов страниц этого сайта. Однако, когда он попросил в беседе у chatgpt добавить обработку еще одного элемента, тот внезапно начал выдавать совершенно нерабочий код. Прикол был в том, что код был рабочий, однако под предыдущую мажорную версию библиотеки BS. Т.е. ChatGPT в какой-то момент в рамках беседы тупо забыл, что до этого весь код писал для одной версии, и начал генерировать новые фрагменты для другой версии библиотеки, и сколько бы ему не намекали в беседе начать писать в прежней версии, он этого не делал.
Справедливости ради, copilot в рамках VSCode меньше таким страдает, поскольку он имеет доступ к Вашему проекту напрямую, однако и у него такие проблемы случаются.
Угроза классическому поиску
Это то, в чем эти чаты реально хороши, причем пользу именно этого большинство потенциальных потребителей этой фичи еще не осознают до конца.
Приведу пример не из программирования. У меня в деревянной кровати отошла одна из планок. Оказалось, что производитель схалтурил, и никаких шайб там не использовал, а чисто шурупы. Я замерил их размеры и спросил у Copilot, какие шайбы лучше всего для этого использовать. Он ответил, что шайбы такие-то, и внезапно добавил, что в стране, где я сейчас нахожусь, шайбам такого-то российского ГОСТа соответствует такой-то немецкий стандарт DIN. Т.е. нейросеть смогла сопоставить данные с нескольких сайтов:
С какого-то российского форума, какие шайбы лучше всего юзать для креплений в деревянной мебели.
А также другой сайт со страницей эквивалентности российских и европейских стандартов.
Кровать я по итогам починил, а то, что я описываю, и есть главная причина, почему Гугл объявил красный код угрозе GPT. С GPT такие вещи выяснять гораздо проще, чем самому лазить по разным сайтам, сопоставлять там информацию и делать выводы.
Впрочем, конкретно в области разработки ИИ наступает на пятки классическому поиску еще и по-другому:
Теперь внутри VSCode можно не только сгенерировать рецепт, чего делать, но и сразу одним кликом запустить его в командной строке внутри, заставить Copilot проанализировать ошибки, которые выдала консоль, и предложить исправление.
Приведу пример, как это выглядит на практике. Нам понадобилось на одном проекте произвести обновление мажорной версии ключевой библиотеки. Когда я его произвел, при сборке и тестировании проекта выявилось последовательно пять ошибок. Из них с четырьмя я сумел справиться, просто тыкая в консоли на исправление ошибок с помощью copilot. Только для одной из них мне пришлось пойти на Reddit и StackOverflow и разбираться, как эту зависимость подключать в новой версии фреймворка.
Это весьма впечатляющий результат. По сути Copilot проворачивает с гуглом и другими поисковиками тот же трюк, что гугл проворачивает с сайтами. Т.е. сейчас, если пользователь ищет информацию в гугле, в большинстве случаев он не переходит на сторонние сайты, а только на сайты самой компании, типа Google maps. Теперь то же происходит с классическими поисковиками. Т.е. можно не покидая IDE решить все проблемы, которые возникают при разработке (ну или почти все).
Поэтому топ-менеджеры Гугла совершенно верно определили эти тулзы как угрозу самому существованию Гугла.
Программированию как професии конец?
TLDR - нет.
Если пространно, то есть ряд причин, почему программисты как профессия не исчезнут. Одна из них - вопрос ответственности:
В теории все выглядит заманчиво для руководителя бизнеса. Зачем мне отдел айти-разработки? Просто попрошу Copilot написать программу, дав ему детальное ТЗ. Но не тут-то было. Это примерно как "Если бухгалтер в расчетах в Excel допустил серьезную ошибку, то кто сядет - бухгалтер или разработчик Excel?"
Это та же причина, по которой IBM Watson (ставящий диагнозы лучше большинства докторов, к слову) не привел к исчезновению диагностов. Когда будете слышать такого рода идеи от какого-нибудь предпринимателя (типа сейчас программисты мне станут не нужны, потому что Copilot все напишет), спросите его "А ты готов бухгалтерию и расчеты поручить chatgpt?"
Но дело, конечно, не только в юридической ответственности. Вот написал вам copilot сайт для вашей фирмы. Как вы оцените, насколько он оптимизирован? Что вы будете делать, если в разгар рабочей недели сайт ляжет, и чинить надо срочно? Бросите все дела и будете дебажить на пару с Copilot (дебажит он, кстати, уже прилично)?
Хорошо, допустим, руководство убедили, что нам нужен разработчик в фирме. Но можно ли обойтись одним? Будет ли когда-нибудь так, что в фирме 50 различных проектов, написанных ИИ, и один разработчик, который за ними следит? Я в этом сомневаюсь - проблема в концентрации и прочих особенностях человеческой психики (если только помимо ИИ не начать с помощью биохакинга выполнять апгрейд самих разработчиков). Слово Ашманову:
Я глубоко убежден, что сделать проект с командой, работающей на полставки и думающей о проекте "на полставки" - нельзя. Здесь вопрос даже не в количестве рабочего времени в неделю, а в эмоциональной вовлеченности. Кто-то в проекте должен занять проектом свою голову и сердце на 100%. Лучше, чтобы это был руководитель проекта, но может быть и его заместитель, или главный разработчик.
Есть и еще одна проблема. Допустим, мы имеем несколько проектов и одного разработчика, который за ними следит, т.е. со временем ИИ будет по все более и более туманным описаниям делать все более и более хорошие программы. И вот мы решили развернуть еще пачку проектов, и добавить еще одного разработчика, присматривать за ними. А где его взять? Ведь если от всех джунов избавились, а заодно и от мидлов, оставив одного сеньора, то где брать новых сеньоров? Из кого они вырастут?
Мне думается, есть высокая вероятность того, что в разработке в ближайшие лет десять будет одно время такой период, когда менеджмент, обрадовавшись тулзам ИИ и то, что теперь один разработчик может работать за десятерых, произведут массовые сокращения. Потом, через некоторое время, столкнувшись с резким сокращением доступных разработчиков на рынке труда и тем, что оставшиеся тупо не справляются c поддержкой массива проектов в рабочем состоянии, эту практику резко прекратят. У нас есть прекрасный пример:
Когда в 80-х в Америке повсеместно внедряли банкоматы, была масса опасений, что банковские служащие (которые в основном и выполняли функции приема и выдачи наличных) будут массово сокращены. В реальности количество банковских служащих не только не сократилось, но и даже слегка возросло с тех пор - т.е. они просто стали заниматься другими задачами.
Итоги
Уже сейчас ChatGPT и Copilot позволяют значительно облегчить (даже с поправкой на галлюцинации) труд разработчика. Я лично смотрю на это с оптимизмом. На мой взгляд, численность разработчиков не сократится, просто они с помощью ИИ смогут делать гораздо более сложные программы, чем сейчас, с меньшим количеством дефектов на 1000 LOC. Т.е. численность людей в профессии не уменьшится, вместо этого тот же самый набор программистов будет производить гораздо больше интересных программ.
А что думаете Вы?