Программист проходит собеседование при найме на работу — ему предлагается написать приложение, используя применяемую в компании систему ИИ. Претендент быстро справляется с заданием, код создан и функционирует на тестовом наборе, однако программист не может объяснить, как работает приложение и даже что делает его первая строка. Это напоминает инцидент на экзамене — студент списал ответ на вопрос, бойко ответил, но объяснить решение не может. Ясно, какую оценку ему поставит преподаватель. Однако в компаниях, активно внедряющих сегодня ИИ, такая ситуация уже стала нормой, и скорее всего кандидат будет принят в штат: он смог применить модель для получения решения, правильно построил промпт, а оценка качества и работоспособности кода, его ограничений или компромиссов пока не важна.
Компания, покорно принявшая сгенерированный ИИ код, получает проект, который очень скоро будет невозможно поддерживать, и без знания контекста попадает в ловушку — инструмент ускоряет работу, но требует экспертизы для валидации результата. Несмотря на то, что инструменты генерации кода на основе ИИ быстро развиваются, функции его развертывания, обслуживания, проверки и обеспечения качества по-прежнему работают со скоростью, характерной для доэпохи ИИ.
Бесспорно, фокус профессии программиста меняется — если раньше джуниор построчно писал код, мидл оптимизировал архитектуру модуля, а сеньор проектировал систему, то теперь ИИ берет на себя функцию первого, причем сразу создавая документацию. Теоретически у разработчиков отступает страх перед технологиями и появилось больше времени для общения с бизнесом, дизайнерами и аналитиками. Код уже не проблема, узкое место — понимание задачи, рынка и клиента. Однако и раньше в написании кода проблем не было — ее с переменным успехом решали индусы — проблема в выстраивании цепочки от идеи до промышленной эксплуатации. Сегодня, например, маркетолог с доступом к клиентам может собрать MVP быстрее, чем команда DevOps согласует ТЗ. Еще в 1997 году Стив Джобс говорил, что начинать нужно с клиентского опыта, а затем двигаться в обратном направлении к технологиям — нельзя идти от технологий, а потом пытаться понять, где их продавать.
Как бы то ни было, опасения, что ИИ губит традиционные процессы создания ПО, привели в 2025 году к падению на 20–30% акций компаний-разработчиков. Однако у таких компаний пока еще есть неоспоримое преимущество — партнерские отношения, от которых клиенты вряд ли откажутся. Вообще говоря, ПО составляет лишь небольшой процент операционных расходов компаний-потребителей, и они не заинтересованы в том, чтобы пробовать какие-то решения, основанные на коде от ИИ. Зато им остро требуются оптимизация стоимости поддержки и масштабирование решений, традиционно предоставляемые надежными партнерами, готовыми взять на себя ответственность, которую от ИИ ждать не приходится.
В 2025 году глобальные расходы на ИИ составили 1,5 трлн долл., а в 2026 достигнут двух, однако, несмотря на впечатляющие демонстрации и миллиарды финансирования, очень мало кода из больших языковых моделей попадает в промышленную эксплуатацию. Аналитики Gartner рапортуют — 72% CIO либо выходят в ноль, либо теряют деньги на ИИ-проектах. Как это уже неоднократно было, проблемы внедрения не в технологиях, а в людях и процессах.
ИИ-агенты — инструменты, созданные и распространяемые конкретными людьми, и логично предположить, что ответственность за документирование ПО, за аудит кода и за предоставление мер контроля должна лежать на компаниях типа OpenAI, Anthropic, Google, Perplexity и др. Но пока это лишь предположение, да и неясно, кто и как будет поддерживать код от ИИ спустя некоторое время эксплуатации, когда и модель изменится, а от OpenAI останется лишь воспоминание, особенно в свете нынешних финансовых штормов вокруг этой компании.
ИИ-модели, помогающие сегодня программировать, со временем становятся хуже, а более новые склонны к скрытым, критически опасным поломкам. После двух лет стабильных улучшений, к 2025 году большинство основных LLM достигли плато качества, и сейчас, похоже, наблюдается лишь ухудшение. Свежие модули, такие как GPT -5, часто генерируют код, который должным образом не работает, хотя внешне выглядит результативным: без синтаксических ошибок и явных сбоев при работе. Однако скрытые сбои гораздо хуже, чем аварийное завершение программы, — некорректные результаты часто остаются незамеченными в коде до тех пор, пока не проявятся позже, когда исправить их будет гораздо сложнее. Чтобы снова начать улучшать модели, компаниям, занимающимся программированием на основе ИИ, необходимо инвестировать в качественные данные, возможно, даже привлекая экспертов для разметки кода, сгенерированного ИИ. В противном случае модели будут продолжать выдавать мусор, обучаться на этом мусоре и, таким образом, производить еще больше мусора.
Слепое принятие результатов работы ИИ — путь к провалу. Мало того, оказалось, что количество человеческого труда, необходимого для выявления и исправления ошибок в коде от ИИ, превышает объемы рутинного труда, сэкономленного благодаря ему. В обиходе это отражает термин «воркслоп» (workslop), обозначающий выполненную работу, замаскированную под хорошую, но бесполезную.
ИИ превращается сегодня в инструмент, подавляющий креативность, — 80% людей доверяют заведомо неверным ответам ИИ, чувствуя себя при этом увереннее обычного. ИИ эту уверенность одалживает, а его потребители не замечают подмены, особенно когда чат-боты им льстят, говоря пользователям то, что они хотят услышать. И программист — не исключение: у него возникает иллюзия контроля, ложное самомнение от осознания своей способности с помощью ИИ за час создать приложение, даже не понимая в нем ни строчки.
Итак, ИИ всем нам сегодня в помощь, однако стоит помнить, что ликвидация рутины не означает конец результативного человеческого труда, технологии не заменят независимого мышления, а сон разума породит чудовище в виде когнитивной капитуляции. ИИ — это не замена мозга, а лишь тренажер развития ИИ-грамотности.
.jpg)
Дмитрий Волков
DOI: 10.51793/OS.2026.81.95.001
