TLDR; – нет, программисты не глупеют от использования ИИ, но вполне могут при неправильном использовании.
Процесс достижения истины так же драгоценен, как и сама истина. Я лишил вас этого. Я даю вашим ученым истину, но не всю, ибо они не знают, как достигнуть ее без моей помощи. Было бы лучше, если б они познавали ее ценой многих ошибок… Ученый спрашивает меня, что происходит в живой клетке, и я говорю ему. Но если бы он исследовал клетку самостоятельно – пусть ценою затраты многих лет, он пришел бы к финишу не только с этим знанием, но и множеством других, со знанием вещей, о которых он сейчас даже не подозревает, а они тесно связаны с его наукой. Он получил бы много новых методов исследования. (с) Мешок. Уильям Моррисон
Не так давно попалась на глаза статья (не знаю, переводил ли ее кто для Хабра, но вообще блог весьма хороший, рекомендую к прочтению), где утверждается, что уровень джунов очень знатно просел за последние два года, и это связывается напрямую с широким распространением генеративного ИИ. Попросту говоря, молодые программисты, когда получают задачу, даже не пытаются разобраться с сутью вопроса, а просто скармливают задачу Copilot/Claude/ChatGPT и вставляют в проект полученный код.
Надо сказать, что я такой старый, что это не первая жалоба на молодежь, тупеющую из-за новой технологии, которую я застал при жизни:
-
Эту первую жалобу я не застал, но от старшего поколения слышал, когда сам был подростком. Когда начали широкое хождение карманные калькуляторы, на полном серьезе утверждалось многими педагогами, что это приведет к тому, что люди в принципе разучатся считать и отупеют. А во многих учебных заведениях до сих пор на экзамене запрещают пользоваться калькуляторами при решении математических задач.
-
Смартфоны, которые приводят к клиповому мышлению.
-
StackOverflow, с которого тупо копипастят ответы. Забавно, что статья жалуется на ИИ, но при этом превозносит ответы со StackOverlow, которые не просто отвечают, но еще и дают отличные пояснения как пищу для ума.
-
Ну и теперь, значит, генеративный ИИ.
Что тут сказать? Когда сейчас жалуются на засилие генеративного ИИ, ведущего к отуплению программистов, как бы забывают, что явление тупости у программистов – давнее, и будет постарше многих жалующихся. Еще в конце 90-х появилось понятие Script kiddies, а с появлением StackOverflow в наш обиход прочно вошло понятие копипастеров, даже не пытающихся понять суть кода, который они копируют.
Генеративный ИИ можно уподобить спортивным тренажерам. Тренажеры в зале весьма полезны, но при неправильной технике новичка они не только не сделают его сильнее, но и могут привести к травмам (или даже пожизненной инвалидности).
Аналогично с генеративным ИИ, особенно в области разработки. Я вижу в нем как возможные перспективы, так и серьезные угрозы. Я верю, что AI Augmented Development – это будущее программирования. Разработчика НЕ заменят, а дополнят, однако его работа станет существенно сложнее (вопреки распространенному мнению, что благодаря ИИ теперь обычные пользователи смогут писать программы).
Бизнес должен четко понимать при этом, какие угрозы исходят от такой разработки. Приведу пример. Представим, что в сетевом стеке некоего вычислительного центра была обнаружена серьезная уязвимость. Уточняю – но дело происходит в начале 80-х где-нибудь в СССР, и этот центр не связан ни с какими остальными. Эту уязвимость по идее надо исправить, но… а кто конкретно ею сможет воспользоваться? Кто вообще за пределами центра о ней знает, а даже если узнает, как он проникнет во внутренюю сеть центра?
Совсем иной расклад в современном интернете, где те же script kiddies c помощью сканеров портов на раз-два обнаружат вашу уязвимость и ею воспользуются. Время, необходимое на латание дыр в уязвимости, сокращается до дней и даже часов.
Что касается разработки, то здесь основная угроза от ИИ, по моему мнению – сокращение времени застывания бетона. Это если на сленге строителей, а если на сленге разработки – ИИ резко повысит вероятность превращения проектов в безнадежные системы костылей. Почему я так думаю?
При разработке большинства коммерческих проектов всегда есть романтическая фаза, когда проект существует пока что в рамках концепции и идеи, позволяющей захватить какую-то нишу на рынке. Что важно в рамках данной темы, что на этой фазе контроль над разработчиками относительно слаб. Никто из менеджмента не проверяет, внедрили ли ребята контроль зависимостей и мониторят ли они их на наличие CVE. Никто не закладывается на то, чтобы архитектура приложения сразу поддерживала возможности модификации в дальнейшем. Никто не отслеживает, насколько хорошо проект разбит на модули и т.д. Никто не бьет программистов по рукам, если проект сложно тестировать и они собирают его на коленке (особенно если этот программист заодно и является руководителем проекта и делает его в одно лицо). И это даже оправданно – поскольку нет времени сделать все правильно, и конкуренты могут опередить. Поэтому сейчас делаем MVP, если выстрелит, потом доработаем.
Такая фаза обычно длится максимум два года, а вот проект встает на развилке. Если руководство вменяемое, то в эти моменты обычно начинаются рефакторинги, введение различных best industry practices, и т.д. Если же руководство считает, что все в порядке, два года все нормально было и дальше будет, бетон проекта постепенно начинает застывать. То есть новые фичи добавлять становится все сложнее, и даже небольшие изменения начинают требовать непропорционально много времени. Это из-за того, что код становится все более запутанным и в нем возрастает Accidental Complexity. И постепенно проект превращается в безнадежный.
Кстати, мне доводилось встречать программистов, знающих про эту романтическую фазу и цинично ее использующих. Т.е. они охотно встревали в нарождающиеся проекты, делали там портянки кода, и уходили за пару месяцев до начала серьезных проблем, при этом с отличным резюме, если смотреть формально – этот проект успешно разработали с нуля, тот проект сделали. И все вроде хорошо, если не учесть, что у новых разработчиков, нанятых на этот проект после ухода начальной команды, начинаются серьезные проблемы с поддержкой и доработкой проекта. Логика у таких программистов циничная – заказчик мне платит деньги за фичи, он получит фичи, а что там будет через пару лет, так заказчик мне не отец и не мать, чтобы я за них переживал.
Переработка таких проектов во вменяемые является нетривиальной инженерной задачей. Достаточно упомянуть классическую книгу Michael Feathers “Working effectively with legacy code”, для погружения в проблему. А при чем здесь ИИ? А ИИ здесь при том, что благодаря нему можно существенно быстрее довести проект с нуля до такого состояния. Генеративный ИИ по определению способен генерировать массу кода по запросам промпт инженеров и вот тут проблемы:
-
Из-за некоторой недетерминированности, заложенной в генеративный ИИ by design (поэтому на один и тот же запрос ИИ может отвечать по-разному), проблема неконсистентности кода резко возрастает. В одном месте для парсинга HTML ИИ предложит код, использующий одну библиотеку. В другом классе он может предложить использовать другую библиотеку, и охотно добавит в maven/gradle/”ваша система сборки” зависимости на обе библиотеки. Иными словами, ответственность разработчика при использовании ИИ резко возрастает – он должен следить за согласованностью разработки отдельных фич.
-
Насчет того, чтобы это было безопасно – пока ИИ не только не помогает с кодом, но даже скорее ухудшает. Многие, наверное, наслышаны об истории про парня, который сделал приложение с помощью ИИ, но оно быстро было завалено хакерами, поскольку безопасностью в нем даже не пахло.
-
Промпты к ИИ не заменяют проектную документацию! Проектная документация и так является слабым местом при разработке проектов (особенно в стартапах), а взаимодействие с ИИ через систему промптов (причем история переписки может не сохраняться) провоцирует не вести документацию вообще.
Т.о., генеративный ИИ запросто может за пару месяцев добиться того, на что у людей раньше уходили годы – нагородить массу слабо-связанного между собой кода (слабо связанного не в плане модульности, а в плане стиля/подхода к решению проблем/переиспользования общих фрагментов).
На самом деле еще патриарх программирования Дональд Кнут при разработке литературного (грамотного) программирования отмечал следующее. Документация о программе, на основе которой автоматически генерируется код программы, по факту становится самой программой. Подобно тому, как из программы на языке высокого уровня может быть сгенерирован абсолютно нечитаемый машинный код, и это никого не волнует, из документа о программе может быть сгенерирован абсолютно нечитаемый код на языке высокого уровня, и это тоже никого не должно волновать, поскольку его никто и не должен будет читать.
Можно ли рассматривать таким образом ИИ? Пока нет. Его наборы промптов и выдача пока недостаточно структурированы, чтобы их можно было рассматривать как тексты литературного программирования. Возможно, когда-нибудь такое время настанет. Тогда программирование в современном понимании исчезнет, но просто потому, что программисты будут формулировать программы в чем-то наподобие мета-языков.
Подводя итог, генеративный ИИ не избавит от программистов, и не делает их тупее. Как это не сделали калькуляторы, логарифмические линейки, да и сами персональные компьютеры. Генеративный ИИ позволяет повысить производительность программистов, но одновременно резко повышает риски при неграмотном использовании. Точно так же в качалках есть тренажеры, которые могут использовать профессионалы, но к которым новичков в принципе подпускать нельзя (например, для проработки дефиниции верха спины).
А что думаете Вы?
Автор: spirit1984
