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/"ваша система сборки" зависимости на обе библиотеки. Иными словами, ответственность разработчика при использовании ИИ резко возрастает - он должен следить за согласованностью разработки отдельных фич.
Насчет того, чтобы это было безопасно - пока ИИ не только не помогает с кодом, но даже скорее ухудшает. Многие, наверное, наслышаны об истории про парня, который сделал приложение с помощью ИИ, но оно быстро было завалено хакерами, поскольку безопасностью в нем даже не пахло.
Промпты к ИИ не заменяют проектную документацию! Проектная документация и так является слабым местом при разработке проектов (особенно в стартапах), а взаимодействие с ИИ через систему промптов (причем история переписки может не сохраняться) провоцирует не вести документацию вообще.
Т.о., генеративный ИИ запросто может за пару месяцев добиться того, на что у людей раньше уходили годы - нагородить массу слабо-связанного между собой кода (слабо связанного не в плане модульности, а в плане стиля/подхода к решению проблем/переиспользования общих фрагментов).
На самом деле еще патриарх программирования Дональд Кнут при разработке литературного (грамотного) программирования отмечал следующее. Документация о программе, на основе которой автоматически генерируется код программы, по факту становится самой программой. Подобно тому, как из программы на языке высокого уровня может быть сгенерирован абсолютно нечитаемый машинный код, и это никого не волнует, из документа о программе может быть сгенерирован абсолютно нечитаемый код на языке высокого уровня, и это тоже никого не должно волновать, поскольку его никто и не должен будет читать.
Можно ли рассматривать таким образом ИИ? Пока нет. Его наборы промптов и выдача пока недостаточно структурированы, чтобы их можно было рассматривать как тексты литературного программирования. Возможно, когда-нибудь такое время настанет. Тогда программирование в современном понимании исчезнет, но просто потому, что программисты будут формулировать программы в чем-то наподобие мета-языков.
Подводя итог, генеративный ИИ не избавит от программистов, и не делает их тупее. Как это не сделали калькуляторы, логарифмические линейки, да и сами персональные компьютеры. Генеративный ИИ позволяет повысить производительность программистов, но одновременно резко повышает риски при неграмотном использовании. Точно так же в качалках есть тренажеры, которые могут использовать профессионалы, но к которым новичков в принципе подпускать нельзя (например, для проработки дефиниции верха спины).
А что думаете Вы?
