Как я боялся Copilot, и продолжаю боятся

Здравствуйте!

Цель статьи – поделиться опасениями от использования ОТЛИЧНЫХ AI-ассистентов и услышать мнение сообщества по их поводу.

Я C# разработчик, и в своей работе в 90% случаев использую VisualStudio. 50% моей работы – создание типовых RESTful сервисов для бэкэнда нашего продукта. Еще процентов 30% – работа с обработкой изображений и видео. И процентов 20% рабочего времени я трачу на различные R&D исследования разной степени сложности.

В 2023 году ChatGPT плотно захватил умы прогрессивного человечества. Мы развлекались как могли. А я в свою очередь стал использовать ChatGPT, а затем и DeepSeek для рутинных задач. Например, сгенерировать набор классов по JSON, отредачить текстовку и т.п. Работа не всегда была выполнена чисто – то напутает с типами данных, то поломает стилистику. В общем приходилось ревьювить каждую генерацию. Но в целом, это здорово помогало экономить время. К тому же мало помалу я составил идеальные промты для каждой задачи, и казалось вот оно светлое будущее.

Затем появился Copilot и часть своих задач я начал выполнять непосредственно в VS. Copilot научился нативно интегрироваться в IDE, представлял удобнейший инструмент для включения результатов своей работы в код и остальные плюшки. Коллеги, между тем, на месте не стояли и расширяли набор сценариев взаимодействия с Copilot. Да и сам Copilot предлагал все более интересные модели.

Начались шуточные разговоры про бездушную машину, замену человека и прочие шутки в этом роде. И если вы подумали, что именно этого я боялся, то нет. Точнее на данном этапе я этого совсем не боялся.

Однажды на ревью, я столкнулся с тем, что программист не знает блок кода, который он выполнил. Небольшой анализ кода выявил странные решения, такие как нефункциональные блоки или не используемые переменные. В итоге выяснилось, что программист доверился модели GPT-mini в, как ему показалось, простой доработке функциональности и отнесся к проверке вайбкода безответственно. В итоге мы потратили больше времени на все этапы вывода доработки в прод.

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

У нас появился клиент, программный продукт которого был полностью “навайбкожен”. В прямом смысле слова. Клиент пришел к нам с просьбой оптимизировать самые “чувствительные” к производительности блоки его приложения. Но в остальном его все устраивало. Программист Технический специалист клиента вообще не понимал, как код устроен. Но зато хорошо понимал предметную область, бизнес процессы и модели данных. Я вспомнил про ситуацию на ревью и понял:

Страшно подумать, что будет с продуктом, если не следить за уровнем вайбкодинга.

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

Я конечно немного волновался, но время шло, модели росли, Gemini Pro уверенно набирал очки, и я стал доверять ему все больше и больше. Перешел от рутины к анализу багов, потом к небольшим функциональным блокам.

Примерно два месяца назад я решил провести эксперимент.
Я поставил копилоту две задачи:

Первая довольна типовая: добавить в модель новую сущность, реализовать в API полный CRUD, разделить доступ к методам CRUD по правам аналогично другим методам моего сервиса.
Вторая задача: реализовать фоновый сервис с довольно сложным алгоритмом, предусматривающим сбор данных, их группировку и маппинг, вычисление с множеством условий и маппинг результатов в сущности EFCore. Параллельно я принялся выполнять аналогичную работу сам.

Целью моего эксперимента было сравнение времени и качества выполнения задач. Условием приемки было тщательное полное ревью результатов AI.

Gemini Pro ожидаемо легко справился с первой задачей, представил хорошо читаемый ревью, и даже объяснил некоторые свои решения. Однако, оказалось, что время на создание промта, генерацию и ревью (еще и с учетом того, что я сам написал такой код час назад) ушло примерно столько же, сколько и у меня на всю работу.

Вторая задача давалась AI с трудом. Постоянно приходилось уточнять алгоритм, вылезали ошибки, генерилось не то что надо. По итогу я и вовсе отчаялся получить хорошее решение и перестал мучить ассистента. Возможно хороший, подробный промт мог бы помочь быстрее и лучше решить эту задачу. Но зачем писать промт, если можно сразу писать код?

В итоге я сделал два вывода:

1. Лучше отдавать задачу ассистенту мелкими промтами. Например: сгенерить новый сервис и добавить туда определенные классы из DI; добавить в сервис цикл по коллекции, внутри которой реализовать маппинг данных в Dto; и т.п

2. Если вы решаете нетиповую задачу, не факт что стоит писать для нее промт – скорее всего вы потратите больше времени на “объяснения” с AI, чем напишите это сами

Сделав эти выводы, я тут же понял:

Страшно подумать, сколько времени мы можем потерять, думая что AI экономят наши трудозатраты

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

А потом я открыл для себя ТРАБЛШУТИНГ! Точнее я понял, что траблшутинг можно поручить ассистенту. И он с блеском справлялся, даже с самыми сложными задачами.
– “Друг мой” – говорил он – “Вот тут ты не учел, что синтаксис XPath для Event Log не использует фигурные скобки для завершения выражения”. Или “Для запуска приложения с графическим интерфейсом из службы Windows необходимо преодолеть изоляцию сеансов (Session 0 Isolation).”
– “Мммм” – соглашался я – “Ну чтож, ОК!”

Copilot исправлял ошибки, правил код, вносил изменения, компилил и отлаживал. И я его во всем поддерживал…. пока у меня не возникла аналогичная бага в другом приложении. Но я не знал почему она возникла и как ее решать…

И тут я понял:

Страшно подумать, сколько знаний я упустил, доверив траблшутинг бездушной машине!

Выводы:

С вашего позволения я сделаю некоторые выводы из всего вышесказанного.

Я по прежнему не боюсь того, что AI заменит живого программиста.

• Даже после того, как я увидел коммерческие приложения, полностью сгенерированные AI

• Даже после того, как lovable сгенерил мне идеальную верстку по снапшотам из figma, и я с грустью вспомнил верстальщика-самоучку, которому я отвалил кучу денег. И от которого получил в итоге наполовину рабочую вёрстку с классами типа xxxLiniaTriTochki

• Даже после того, как copilot стал экономить до 30% моего рабочего времени

Я не боюсь что в ближайшие 10 лет решения уровня enterprise будут экономить на разработчиках. И вряд-ли когда то хоть один самолет поднимется в воздух с программным обеспечением, который не видел человек.

Однако некоторые опасения у меня возникают:

1. Вход в ИТ для молодых разработчиков станет очень высокоуровневым.

2. Всплеск использования AI ассистентов может сильно уронить уровень знаний программистов

3. Программисты перестанут быть востребованными на рынке фриланса. По сути требования к ним могут упроститься до уровня хорошего технического писателя

4. Мы станем слишком зависимыми от AI ассистентов. Работодатель в целом склонен “давить” на программистов с помощью различных инструментов управления аля скрам. Разумно сравнивая затраты, многие работодатели могут отдать целые рабочие стеки в AI. На текущем этапе это может быть дешевым решением. Но в перспективе AI может стать очень дорогим, и продеться вернуться к живым программистам. А пункт 1 и 2 намекают нам, что их может сильно убавиться

5. И восстанут машины из пепла ядерного огня, и пойдет война на уничтожения человечества ))

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

PS. Прошу не судить строго за стилистику повествования и ошибки. Текст был написан под влиянием момента, в порыве философских мук !