Разработчики сталкиваются со сложными несоответствиями между ожиданиями и реальностью. То же самое можно сказать и обо всех остальных.
В зависимости от того, кого вы спросите, программирование с использованием ИИ либо обеспечивает разработчикам программного обеспечения беспрецедентный прирост производительности, либо приводит к созданию огромного количества плохо спроектированного кода, который отвлекает их внимание и создает серьезные проблемы с долгосрочным сопровождением программных проектов.
Проблема в том, что сейчас непросто определить, что из этого правда.
Поскольку технологические гиганты вкладывают миллиарды в большие языковые модели (LLM), программирование позиционируется как «убийственное приложение» этой технологии. И генеральный директор Microsoft Сатья Надела, и генеральный директор Google Сундар Пичаи утверждали, что около четверти кода их компаний теперь генерируется искусственным интеллектом. А в марте генеральный директор Anthropic Дарио Амодей предсказал, что в течение шести месяцев 90% всего кода будет написано искусственным интеллектом. Это привлекательный и очевидный вариант использования. Код — это форма языка, нам нужно много кода, и его создание вручную обходится дорого. Кроме того, легко проверить, работает ли он — запустите программу, и сразу станет ясно, функционирует ли она.
Эта статья является частью серии публикаций MIT Technology Review под названием «Коррекция ажиотажа» , которая призвана переосмыслить представления об искусственном интеллекте, его возможностях и направлениях нашего дальнейшего развития.
Руководители, очарованные потенциалом преодоления человеческих барьеров, подталкивают инженеров к освоению будущего, основанного на искусственном интеллекте. Но после опроса более 30 разработчиков, руководителей технологических компаний, аналитиков и исследователей, издание MIT Technology Review обнаружило, что ситуация не так проста, как может показаться.
Для некоторых разработчиков, работающих на передовой, первоначальный энтузиазм угасает по мере того, как они сталкиваются с ограничениями технологии. А поскольку все больше исследований показывают, что заявленные преимущества в производительности могут быть иллюзорными, некоторые задаются вопросом, не голый ли король.
Однако темпы прогресса усложняют ситуацию. Постоянный выпуск новых моделей означает, что возможности и особенности этих инструментов постоянно развиваются. А их полезность часто зависит от задач, для которых они применяются, и от организационных структур, построенных вокруг них. Все это заставляет разработчиков сталкиваться со сложными несоответствиями между ожиданиями и реальностью.
Сейчас лучшие или худшие времена (если использовать слова Диккенса) для программирования ИИ? Возможно, и то, и другое.
Быстро меняющееся поле
В наши дни сложно избежать инструментов для программирования ИИ. Существует ошеломляющее множество продуктов, как от разработчиков моделей, таких как Anthropic, OpenAI и Google, так и от компаний, подобных Cursor и Windsurf, которые интегрируют эти модели в удобное программное обеспечение для редактирования кода. И, согласно опросу разработчиков Stack Overflow 2025 года, они быстро набирают популярность: 65% разработчиков используют их как минимум еженедельно.
Инструменты для программирования с использованием ИИ впервые появились примерно в 2016 году, но получили мощный импульс с появлением программ на основе лингвистических моделей (LLM). Ранние версии функционировали лишь как автозаполнение для программистов, предлагая, что ввести дальше. Сегодня они могут анализировать целые кодовые базы, редактировать файлы, исправлять ошибки и даже генерировать документацию, объясняющую, как работает код. Все это осуществляется с помощью подсказок на естественном языке через чат.
«Агенты» — автономные инструменты программирования на основе LLM, способные брать высокоуровневый план и самостоятельно создавать целые программы, — представляют собой новейший рубеж в программировании с использованием ИИ. Этот скачок стал возможен благодаря новейшим моделям рассуждений, которые могут решать сложные задачи шаг за шагом и, что особенно важно, получать доступ к внешним инструментам для выполнения задач. «Именно так модель способна программировать, а не просто говорить о программировании», — говорит Борис Черни, руководитель Claude Code, агента программирования компании Anthropic.
Спросите ИИ. Почему это важно для вас? БЕТА-ВЕРСИЯ. Вот почему, по мнению ИИ, эта история может быть важна для вас. Это бета-версия, и ИИ может выдавать галлюцинации — это может быть странно . Отрасль, которая меня интересует, — это… Узнайте больше о том, как мы используем ИИ.
Эти агенты добились впечатляющих успехов в тестах по разработке программного обеспечения — стандартизированных тестах, измеряющих производительность моделей. Когда в августе 2024 года OpenAI представила тест SWE-bench Verified, предлагающий способ оценки успешности агентов в исправлении реальных ошибок в репозиториях с открытым исходным кодом, лучшая модель решила всего 33% проблем. Год спустя ведущие модели стабильно показывают результаты выше 70%.
В феврале Андрей Карпати, один из основателей OpenAI и бывший директор по искусственному интеллекту в Tesla, ввел термин «вайб-кодирование» — подход, при котором люди описывают программное обеспечение на естественном языке, а искусственный интеллект пишет, дорабатывает и отлаживает код. В социальных сетях множество разработчиков, поддержавших эту концепцию и заявляющих о значительном повышении производительности.
Однако, хотя некоторые разработчики и компании сообщают о таком повышении производительности, убедительные доказательства противоречивы. Ранние исследования GitHub, Google и Microsoft — всех поставщиков инструментов искусственного интеллекта — показали, что разработчики выполняют задачи на 20–55% быстрее. Но в сентябрьском отчете консалтинговой компании Bain & Company реальная экономия была названа «незначительной».
Данные аналитической компании GitClear, занимающейся изучением разработчиков, показывают, что большинство инженеров с 2022 года создают примерно на 10% более надежный код — код, который не удаляется и не переписывается в течение нескольких недель, — вероятно, благодаря искусственному интеллекту. Но этот рост сопровождался резким снижением ряда показателей качества кода. Опрос Stack Overflow также показал, что доверие и позитивное отношение к инструментам ИИ впервые значительно снизились. И что наиболее показательно, июльское исследование некоммерческой исследовательской организации Model Evaluation & Threat Research (METR) показало, что, хотя опытные разработчики считали, что ИИ делает их на 20% быстрее, объективные тесты показали, что на самом деле они работают на 19% медленнее.
Растущее разочарование
Для Майка Джаджа, ведущего разработчика в консалтинговой компании Substantial, исследование METR задело за живое. Он был одним из первых активных пользователей инструментов искусственного интеллекта, но со временем разочаровался в их ограничениях и скромном повышении производительности. «Я жаловался людям, потому что думал: „Он мне помогает, но я не могу понять, как заставить его действительно сильно мне помочь“», — говорит он. «Мне постоянно казалось, что ИИ очень глуп, но, может быть, я смогу обманом заставить его стать умным, если найду подходящее волшебное заклинание».
Связанная статья
Когда друг спросил Джаджа, тот оценил, что инструменты обеспечивают ускорение примерно на 25%. Поэтому, увидев аналогичные оценки, приписываемые разработчикам в исследовании METR, он решил проверить это самостоятельно. В течение шести недель он угадывал, сколько времени займет выполнение задачи, подбрасывал монетку, чтобы решить, использовать ли ИИ или писать код вручную, и засекал время. К своему удивлению, ИИ замедлил его работу в среднем на 21% — что совпало с результатами исследования METR.
Это заставило Джаджа углубиться в анализ данных. Если эти инструменты действительно ускоряют работу разработчиков, рассуждал он, то следует ожидать резкого роста числа новых приложений, регистраций на сайтах, видеоигр и проектов на GitHub. Он потратил часы и несколько сотен долларов на анализ всех общедоступных данных и обнаружил, что повсюду наблюдаются нулевые значения.
«Разве здесь не должно быть восходящей и правосторонней тенденции?» — спрашивает Джадж. «Где же хоккейная клюшка на этих графиках? Мне казалось, все невероятно продуктивны». Очевидный вывод, по его словам, заключается в том, что инструменты ИИ мало способствуют повышению производительности большинства разработчиков.
Разработчики, опрошенные MIT Technology Review, в целом сходятся во мнении о сильных сторонах инструментов ИИ: создание «шаблонных кодов» (многократно используемых фрагментов кода, повторяющихся в нескольких местах с минимальными изменениями), написание тестов, исправление ошибок и объяснение незнакомого кода начинающим разработчикам. Несколько человек отметили, что ИИ помогает преодолеть «проблему чистого листа», предлагая несовершенную первую попытку, которая стимулирует творческое мышление разработчика. Он также позволяет нетехническим коллегам быстро создавать прототипы функций программного обеспечения, снижая нагрузку на и без того перегруженных инженеров.
Эти задачи могут быть утомительными, и разработчики, как правило, с удовольствием передают их другим. Но они составляют лишь небольшую часть работы опытного инженера. Что касается более сложных задач, в решении которых инженеры действительно зарабатывают на жизнь, многие разработчики рассказали MIT Technology Review, что инструменты сталкиваются со значительными трудностями.
Пожалуй, самая большая проблема заключается в том, что LLM-ы могут удерживать лишь ограниченное количество информации в своем «контекстном окне» — по сути, в рабочей памяти. Это означает, что им трудно обрабатывать большие кодовые базы, и они склонны забывать, что делают при выполнении длительных задач. «Они становятся очень близорукими — они смотрят только на то, что находится прямо перед ними», — говорит Джадж. «И если вы поручите им сделать дюжину вещей, они сделают одиннадцать из них и просто забудут последнюю».
ДЕРЕК БРАХНИБлизорукость программистов с большим объемом знаний может создавать проблемы для программистов. Хотя сгенерированное программистом решение проблемы может работать изолированно, программное обеспечение состоит из сотен взаимосвязанных модулей. Если при их разработке не учитываются другие части программного обеспечения, это может быстро привести к запутанной, непоследовательной кодовой базе, которую трудно понять и, что более важно, поддерживать человеку.
Разработчики традиционно решали эту проблему, следуя соглашениям — расплывчатым правилам кодирования, которые сильно различаются между проектами и командами. «Искусственный интеллект имеет подавляющую тенденцию не понимать, каковы существующие соглашения в репозитории, — говорит Билл Хардинг, генеральный директор GitClear. — Поэтому он с большой вероятностью предложит свой собственный, немного отличающийся способ решения проблемы».
Модели также часто дают сбои. Как и все модели LLM, модели кодирования склонны к «галлюцинациям» — это проблема, заложенная в их работе. Но поскольку выдаваемый ими код выглядит таким отполированным, ошибки трудно обнаружить, говорит Джеймс Лю, директор по разработке программного обеспечения в рекламной технологической компании Mediaocean. Соедините все эти недостатки, и использование этих инструментов может напоминать попытку потянуть за рычаг однорукого бандита. «В некоторых проектах вы получаете 20-кратное улучшение скорости или эффективности, — говорит Лю. — В других же случаях все просто терпит крах, и вы тратите все это время, пытаясь заставить их исполнить ваше желание, а они просто не исполняют его».
Судья подозревает, что именно поэтому инженеры часто переоценивают прирост производительности. «Вы помните джекпоты. Вы не помните, как два часа сидели и вставляли жетоны в игровой автомат», — говорит он.
И это может быть особенно опасно, если разработчик не знаком с задачей. Джадж вспоминает, как попросил ИИ помочь настроить облачный сервис Microsoft под названием Azure Functions, которым он никогда раньше не пользовался. Он думал, что это займет около двух часов, но через девять часов сдался. «Он постоянно загонял меня в тупик, а я недостаточно разбирался в теме, чтобы сказать ему: „Эй, это бессмыслица“», — говорит он.
Долг начинает расти
Разработчики постоянно идут на компромисс между скоростью разработки и удобством сопровождения кода, создавая так называемый «технический долг», — говорит Джеффри Г. Паркер, профессор инженерных инноваций в Дартмутском колледже. Каждый такой компромисс усложняет кодовую базу и затрудняет ее управление, накапливая «проценты», которые в конечном итоге необходимо погасить путем реструктуризации кода. По мере накопления этого долга добавление новых функций и поддержка программного обеспечения становятся медленнее и сложнее.
Накопление технического долга неизбежно в большинстве проектов, но инструменты искусственного интеллекта значительно упрощают работу инженеров, испытывающих нехватку времени, по словам Хардинга из GitClear. И данные GitClear свидетельствуют о том, что это происходит в масштабах всей компании. С 2020 года компания наблюдает значительный рост количества скопированного и вставленного кода — показатель того, что разработчики повторно используют больше фрагментов кода, скорее всего, на основе предложений ИИ, — и еще большее снижение количества кода, перемещенного из одного места в другое, что происходит, когда разработчики очищают свою кодовую базу.
Связанная статья
По мере совершенствования моделей создаваемый ими код становится все более многословным и сложным, говорит Тарик Шаукат, генеральный директор компании Sonar, разрабатывающей инструменты для проверки качества кода. Это приводит к снижению количества очевидных ошибок и уязвимостей безопасности, но за счет увеличения числа «запахов кода» — труднообнаружимых недостатков, которые приводят к проблемам с поддержкой и техническому долгу.
Недавнее исследование компании Sonar показало, что на эти проблемы приходится более 90% ошибок, обнаруженных в коде, генерируемом ведущими моделями искусственного интеллекта. «Проблемы, которые легко обнаружить, исчезают, и остаются гораздо более сложные проблемы, на выявление которых требуется время», — говорит Шаукат. «Именно это нас сейчас беспокоит в этой области. Вас почти убаюкивают ложным чувством безопасности».
Если инструменты искусственного интеллекта будут все больше затруднять поддержку кода, это может иметь серьезные последствия для безопасности, говорит Джессика Джи, исследователь в области безопасности из Джорджтаунского университета. «Чем сложнее обновлять и исправлять ошибки, тем выше вероятность того, что кодовая база или любой конкретный фрагмент кода со временем станет небезопасным», — говорит Джи.
По ее словам, существуют и более специфические проблемы безопасности. Исследователи обнаружили тревожный класс галлюцинаций, когда модели ссылаются на несуществующие программные пакеты в своем коде. Злоумышленники могут использовать это, создавая пакеты с такими именами, которые содержат уязвимости, и которые модель или разработчик могут затем непреднамеренно включить в программное обеспечение.
Модели LLM также уязвимы для «атак отравления данных», когда хакеры заполняют общедоступные наборы данных, на которых обучаются модели, данными, которые изменяют поведение модели нежелательным образом, например, генерируют небезопасный код при срабатывании определенных фраз. В октябре исследование Anthropic показало, что всего 250 вредоносных документов могут внедрить подобный бэкдор в модель LLM независимо от ее размера.
Обращенные
Несмотря на эти проблемы, пути назад, вероятно, нет. «Скорее всего, те времена, когда каждую строчку кода писали вручную на клавиатуре, быстро уходят в прошлое», — говорит Кайл Дейгл, главный операционный директор принадлежащей Microsoft платформы для размещения кода GitHub, которая выпускает популярный инструмент на основе искусственного интеллекта под названием Copilot (не путать с одноименным продуктом Microsoft).
В отчете Stack Overflow говорится, что, несмотря на растущее недоверие к этой технологии, ее использование быстро и стабильно увеличивалось в течение последних трех лет. Эрин Йепис, старший аналитик Stack Overflow, говорит, что это свидетельствует о том, что инженеры используют инструменты, трезво оценивая риски. В отчете также отмечается, что активные пользователи, как правило, проявляют больший энтузиазм, а более половины разработчиков не используют новейшие агенты кодирования, что, возможно, объясняет, почему многие по-прежнему не в восторге от этой технологии.
Новейшие инструменты могут стать настоящим откровением. Тревор Диллей, технический директор агентства по разработке программного обеспечения Twenty20 Ideas, говорит, что он оценил функции автозаполнения в редакторах с искусственным интеллектом, но когда он пытался сделать что-то более сложное, это «проваливалось с катастрофическими последствиями». Затем в марте, во время отпуска с семьей, он запустил недавно выпущенный Claude Code в одном из своих хобби-проектов. Программа выполнила задачу, на которую ушло четыре часа, за две минуты, и код оказался лучше, чем тот, который он написал бы сам.
«Я подумал: „Ух ты!“ — говорит он. — „Для меня это был действительно переломный момент. Обратного пути нет“». С тех пор Диллей стал соучредителем стартапа DevSwarm, который разрабатывает программное обеспечение, способное объединять несколько агентов для параллельной работы над одной программой.
По словам Армина Ронахера, известного разработчика программного обеспечения с открытым исходным кодом, проблема заключается в том, что освоение этих инструментов требует времени, но усилий. До марта он не был впечатлен инструментами искусственного интеллекта, но после ухода из компании Sentry в апреле, чтобы запустить стартап, он начал экспериментировать с агентами. «В основном я провел много месяцев, занимаясь только этим», — говорит он. «Теперь 90% кода, который я пишу, генерируется искусственным интеллектом».
Достижение этого результата потребовало множества проб и ошибок, чтобы выяснить, какие проблемы чаще всего мешают работе инструментов, а с какими они могут эффективно справляться. По словам Ронахера, современные модели могут справиться с большинством задач программирования при наличии соответствующих ограничений, но эти ограничения могут быть очень специфичными для конкретной задачи и проекта.
Чтобы максимально эффективно использовать эти инструменты, разработчикам необходимо отказаться от контроля над отдельными строками кода и сосредоточиться на общей архитектуре программного обеспечения, говорит Нико Вестердейл, технический директор компании IndeVets, занимающейся подбором ветеринарного персонала. Недавно он создал платформу для анализа данных, состоящую из 100 000 строк кода, почти полностью основанную на подсказках моделей, а не на написании кода самостоятельно.
Процесс Вестердейла начинается с продолжительной беседы с агентом-модельером для разработки подробного плана того, что и как нужно построить. Затем он направляет его на каждом этапе. Редко что-то получается с первого раза, и требуется постоянная работа над этим, но если заставить его придерживаться четко определенных шаблонов проектирования, модели могут создавать высококачественный, легко поддерживаемый код, говорит Вестердейл. Он проверяет каждую строку, и код получается таким же хорошим, как и все, что он когда-либо создавал, говорит он: «Я просто считаю это абсолютно революционным. Это также вызывает разочарование, это сложно, это другой способ мышления, и мы только сейчас к нему привыкаем».
Но хотя отдельные разработчики учатся эффективно использовать эти инструменты, добиться стабильных результатов в большой инженерной команде значительно сложнее. Инструменты искусственного интеллекта усиливают как положительные, так и отрицательные стороны вашей инженерной культуры, говорит Райан Дж. Сальва, старший директор по управлению продуктами в Google. При наличии четких процессов, ясных шаблонов кодирования и хорошо определенных лучших практик эти инструменты могут проявить себя наилучшим образом.
ДЕРЕК БРАХНИНо если ваш процесс разработки неорганизован, это только усугубит проблемы. Также крайне важно кодифицировать эти институциональные знания, чтобы модели могли эффективно их использовать. «Необходимо проделать большую работу, чтобы помочь создать контекст и избавиться от устаревших знаний», — говорит он.
Криптовалютная биржа Coinbase активно заявляет о внедрении инструментов искусственного интеллекта. Генеральный директор Брайан Армстронг попал в заголовки новостей в августе, когда сообщил об увольнении сотрудников, не желавших использовать инструменты ИИ. Однако глава платформы Coinbase Роб Витофф рассказал MIT Technology Review, что, хотя в некоторых областях наблюдается значительный рост производительности, эффект от этого неравномерный. Для более простых задач, таких как реструктуризация кодовой базы и написание тестов, рабочие процессы на основе ИИ обеспечивают ускорение до 90%. Но для других задач прирост более скромный, и, по словам Витоффа, сбои, вызванные перестройкой существующих процессов, часто нивелируют увеличение скорости кодирования.
Один из факторов заключается в том, что инструменты ИИ позволяют младшим разработчикам создавать гораздо больше кода. Как и почти во всех инженерных командах, этот код должен проверяться другими, обычно более опытными разработчиками, чтобы выявлять ошибки и гарантировать соответствие стандартам качества. Но огромный объем кода, который сейчас создается, быстро перегружает возможности сотрудников среднего уровня по проверке изменений. «Это цикл, который мы проходим почти каждый месяц: мы автоматизируем что-то новое на более низком уровне стека, что создает дополнительную нагрузку на более высоких уровнях», — говорит он. «Затем мы рассматриваем возможность применения автоматизации к этому более высокому уровню».
По словам партнера Bain, разработчики тратят на кодирование всего 20–40% своего времени, поэтому даже значительное ускорение в этой области часто приводит к более скромным общим результатам. Остальное время разработчики тратят на анализ проблем программного обеспечения, обработку отзывов клиентов, разработку продуктовой стратегии и административные задачи. Для существенного повышения эффективности компаниям, возможно, потребуется применять генеративный ИИ и ко всем этим процессам, говорит Джу, и эта работа все еще продолжается.
Быстрая эволюция
Программирование с использованием агентов — это кардинальное отступление от прежних методов работы, поэтому неудивительно, что компании сталкиваются с некоторыми трудностями на начальном этапе. Кроме того, это очень новые продукты, которые меняются с каждым днем. «Каждые несколько месяцев модель улучшается, и происходит значительное изменение в возможностях программирования модели, поэтому требуется перенастройка», — говорит Черни из Anthropic.
Например, в июне Anthropic внедрила в Claude встроенный режим планирования; с тех пор его скопировали другие поставщики. В октябре компания также дала Claude возможность задавать пользователям вопросы, когда требуется дополнительная информация или когда рассматривается несколько возможных решений, что, по словам Черни, помогает избежать склонности просто предполагать, какой путь является наилучшим.
Связанная статья
Наиболее значительным нововведением стало добавление в Anthropic функций, которые позволяют Claude лучше управлять собственным контекстом. Когда он приближается к пределам своей рабочей памяти, он обобщает ключевые детали и использует их для запуска нового контекстного окна, фактически создавая «бесконечное» окно, говорит Черни. Claude также может привлекать субагентов для работы над более мелкими задачами, поэтому ему больше не нужно хранить все аспекты проекта в своей голове. Компания утверждает, что ее последняя модель, Claude 4.5 Sonnet, теперь может автономно программировать более 30 часов без существенного снижения производительности.
Новые подходы к разработке программного обеспечения также могут обойти другие недостатки программных агентов. Профессор Массачусетского технологического института Макс Тегмарк представил технологию, которую он называет «верикодированием», позволяющую агентам создавать полностью безошибочный код на основе описания на естественном языке. Она основана на подходе, известном как «формальная верификация», при котором разработчики создают математическую модель своего программного обеспечения, которая может неопровержимо доказать его корректную работу. Этот подход используется в таких ответственных областях, как системы управления полетом и криптографические библиотеки, но он остается дорогостоящим и трудоемким, что ограничивает его более широкое применение.
Быстрое совершенствование математических возможностей моделей с линейной логикой открыло заманчивую возможность создания моделей, которые производят не только программное обеспечение, но и математическое доказательство его отсутствия ошибок, говорит Тегмарк. «Вы просто задаете спецификацию, и ИИ возвращает код с доказанной корректностью, — говорит он. — Вам не нужно трогать код. Вам даже не нужно его просматривать».
Согласно неопубликованному исследованию группы Тегмарка, лучшие LLM-модели, протестированные на примерно 2000 задачах верикодирования в языке Dafny — языке, предназначенном для формальной верификации, — решили более 60% этих задач. Это было достигнуто с помощью готовых LLM-моделей, и Тегмарк ожидает, что обучение, специально разработанное для верикодирования, может быстро улучшить результаты.
И, как ни парадоксально, скорость, с которой ИИ генерирует код, может также снизить проблемы с его поддержкой. Алекс Уорден, ведущий инженер в гиганте бизнес-программного обеспечения Intuit, отмечает, что поддержка часто затруднена, потому что инженеры повторно используют компоненты в разных проектах, создавая клубок зависимостей, где одно изменение вызывает каскадные эффекты по всей кодовой базе. Повторное использование кода раньше экономило время разработчиков, но в мире, где ИИ может генерировать сотни строк кода за секунды, эта необходимость исчезла, говорит Уорден.
Вместо этого он выступает за «одноразовый код», где каждый компонент генерируется независимо искусственным интеллектом, независимо от того, соответствует ли он шаблонам проектирования или общепринятым стандартам. Затем они соединяются через API — наборы правил, которые позволяют компонентам запрашивать информацию или услуги друг у друга. Внутреннее устройство каждого компонента не зависит от других частей кодовой базы, что позволяет удалять и заменять их без более масштабных последствий, говорит Уорден.
«В отрасли по-прежнему обеспокоены тем, что люди будут поддерживать код, сгенерированный ИИ, — говорит он. — Я сомневаюсь, как долго люди будут смотреть на код или вообще интересоваться им».
Сужение кадрового резерва
Однако в обозримом будущем людям по-прежнему придется понимать и поддерживать код, лежащий в основе их проектов. И одним из самых пагубных побочных эффектов инструментов ИИ может стать сокращение числа людей, способных это делать.
Предварительные данные свидетельствуют о том, что опасения по поводу разрушительного воздействия ИИ на рынок труда могут быть оправданы. Недавнее исследование Стэнфордского университета показало, что занятость среди разработчиков программного обеспечения в возрасте от 22 до 25 лет сократилась почти на 20% в период с 2022 по 2025 год, что совпало с ростом популярности инструментов программирования на основе ИИ.
Опытные разработчики тоже могут столкнуться с трудностями. Лучано Нойен, инженер в компании Companion Group, занимающейся разработкой игровой инфраструктуры, активно использовал инструменты искусственного интеллекта на своей основной работе, где они предоставлялись бесплатно. Но когда он начал свой сторонний проект, не имея доступа к этим инструментам, он обнаружил, что ему трудно справляться с задачами, которые раньше давались легко. «Я чувствовал себя таким глупым, потому что то, что раньше было инстинктивным, стало выполняться вручную, иногда даже громоздко», — говорит Нойен.
Подобно тому, как спортсмены до сих пор выполняют базовые упражнения, он считает, что единственный способ сохранить инстинкт к программированию — это регулярно практиковаться в выполнении черновой работы. Именно поэтому он в значительной степени отказался от инструментов искусственного интеллекта, хотя и признает, что здесь играют роль и более глубокие мотивы.
Одна из причин, по которой Нойен и другие разработчики, с которыми беседовало издание MIT Technology Review, выступают против инструментов искусственного интеллекта, заключается в ощущении, что они лишают их любимой работы тех аспектов, которые им необходимы. «Я занялся разработкой программного обеспечения, потому что мне нравится работать с компьютерами. Мне нравится заставлять машины делать то, что я хочу», — говорит Нойен. «Просто сидеть и ждать, пока за меня сделают работу, — это не весело».
Источник: www.technologyreview.com
