ИИ забирает работу у программистов. Но настоящая проблема гораздо серьезнее1
Сразу предупреждаю: эта статья полностью сгенерирована ИИ по моему промпту.
Я сформулировал основные тезисы, аргументы и собственную позицию, а нейросети поручил подготовить связный текст. Сам я не очень уважаю нейрослоп, особенно когда им бездумно заваливают интернет, поэтому считаю правильным предупредить об этом заранее. Если вам принципиально не нравится читать тексты, написанные ИИ, лучше закрыть пост прямо сейчас. Я вполне пойму.
При этом я прекрасно понимаю неприязнь к нейрослопу, но не понимаю, зачем автоматически записывать в него любой текст, созданный с помощью ИИ. Хороший материал не становится плохим только потому, что его написала нейросеть. Как и откровенная хрень не превращается в качественную статью оттого, что автор собственноручно набрал ее на клавиатуре. Оценивать, на мой взгляд, нужно содержание, аргументацию, достоверность и пользу для читателя, а не способ производства текста.
Почему тогда не написал самостоятельно? Не потому, что не умею. У меня есть опыт научной работы, публикаций и подготовки самых разных текстов. При необходимости вполне мог бы написать эту статью не хуже. Но сейчас у меня есть более важные дела, на которые я предпочитаю тратить собственное время.
Кроме того, это продолжение моего эксперимента с использованием ИИ. Мы с ним уже довольно долго работаем над одним проектом, причем работа не ограничивается написанием программ. За это время мы неоднократно пересматривали архитектуру, анализировали ошибки, проводили технические аудиты, проверяли сотни тестовых сценариев, обсуждали безопасность, надежность и производительность системы. И эта работа продолжается.
В доступной истории нашей переписки накопилось огромное количество технических подробностей, промежуточных решений, обнаруженных проблем и выводов. Чтобы самостоятельно восстановить всю последовательность событий и выбрать существенное для статьи, мне пришлось бы перечитывать множество обсуждений. ИИ может проанализировать доступные ему материалы нашей совместной работы, сопоставить разные этапы разработки и выделить из них наиболее интересное. То есть в данном случае он не просто пишет текст вместо меня, а помогает обобщить большой объем уже проделанной работы. Причем это как раз иллюстрация основной мысли статьи: определить, ЧТО нужно сделать и КАК это должно быть устроено, зачастую гораздо сложнее, чем непосредственно выполнить работу.
С чего все началось
Недавно я опубликовал на Пикабу пост о том, как за несколько часов собственного времени создал семейного ИИ-ассистента в Telegram, не написав самостоятельно ни одной строки кода. Всю техническую реализацию поручил облачному ИИ-агенту. Обсуждение получилось интересным. Кто-то оценил возможности современных нейросетей, кто-то не понял, зачем вообще понадобилось создавать очередного бота, а некоторые подняли вопросы, оказавшиеся гораздо серьезнее самого проекта.
В частности, один из комментаторов, профессиональный архитектор в строительстве, высказал вполне обоснованное опасение: если мы передадим ИИ всю относительно простую работу, на которой сегодня учатся молодые специалисты, откуда через двадцать лет возьмутся опытные инженеры? Кто будет проверять проекты мостов, зданий и других ответственных сооружений, если их научится генерировать ИИ, а специалистов, способных самостоятельно оценить результат, уже не останется?
Я начал писать ответ, рассуждать о перестройке системы образования и подготовке специалистов, а потом поймал себя на мысли, что проблема действительно гораздо серьезнее, чем кажется на первый взгляд.
Тем более что я смотрю на нее с двух сторон. В ИТ я почти тридцать лет, начинал с технических специальностей, профессионально занимался программированием, затем перешел к руководству разработкой и управлению бизнесом. При этом сам активно использую ИИ практически во всех рабочих процессах, включая разработку сложной технической документации и программно-аппаратных комплексов.
То есть я одновременно заинтересован в максимальном повышении производительности труда и прекрасно понимаю, чем может обернуться сокращение подготовки новых специалистов.
И чем больше работаю с современными ИИ-агентами, тем отчетливее вижу подтверждение одной давно известной лично мне закономерности.
Кодить всегда было сравнительно легко. Самое сложное в разработке программного обеспечения вообще не в написании кода. И именно поэтому ИИ настолько сильно меняет эту профессию.
Кодить легко. Определять, что и как кодить, гораздо сложнее
Сразу уточню, что речь не о разработке сложнейших алгоритмов, систем реального времени, низкоуровневом программировании и других задачах, требующих серьезной самостоятельной инженерной работы. Но если взять массовую заказную разработку, значительная ее часть всегда представляла собой довольно механическую деятельность.
Есть техническое задание. Определена архитектура, выбран язык программирования, описаны интерфейсы, структуры данных, алгоритмы и критерии приемки. Берешь и пишешь код.
Разумеется, для этого нужны знания и навыки, но когда все принципиальные решения уже приняты, основная работа сводится к их технической реализации. Это чисто исполнительнский труд - квалифицированный, иногда дорогой, зачастую трудоемкий, но все-таки исполнительский.
И именно эту работу современные нейросети научились выполнять просто великолепно.
Раньше программист мог неделями писать модули, реализовывать интерфейсы, интеграции, обработчики событий, работу с базами данных. Заказчик платил за это вполне приличные деньги, потому что разработка требовала значительного количества человеко-часов. Сегодня квалифицированный специалист может сформулировать требования к тому же модулю и поручить реализацию ИИ. Причем не просто получить готовый код, а заставить агента самостоятельно создать файлы, установить зависимости, запустить программу, написать тесты и исправить обнаруженные ошибки.
Конечно, результат необходимо проверять, и иногда на исправление последствий неудачных решений агента уходит немало времени. Но при правильной организации работы экономия может оказаться огромной.
Поэтому если ваша работа заключалась или пока еще заключается преимущественно в разработке отдельных программных модулей на заранее определенном языке по готовому техническому заданию, у меня для вас плохие новости. Именно ваша специализация сейчас находится под серьезнейшим ударом. Не обязательно завтра вас уволят, но рассчитывать, что механическое написание кода и дальше будет стоить столько же, сколько раньше, довольно наивно.
Если вы сами составляли эти задания, выясняли требования заказчика, устраняли противоречия и определяли критерии приемки, ситуация лучше. С этим ИИ справляется гораздо менее надежно.
А если занимались архитектурой, системным анализом, проектированием сложных решений или управлением разработкой, то для вас сейчас вообще открываются совершенно другие возможности. Вместо нескольких программистов-исполнителей вы получаете инструмент, способный самостоятельно выполнить значительную часть их работы. Правда, при условии, что вы действительно понимаете, что делаете, а не просто занимаете соответствующую должность.
Как это выглядит на практике. История Владимира
В предыдущей публикации я рассказывал о своем семейном ИИ-ассистенте, которого мы назвали Владимиром. Идея была простой: создать единый интерфейс в Telegram, через который каждый член семьи мог бы взаимодействовать с полноценным облачным ИИ-агентом, имеющим собственный компьютер, браузер, терминал, файловую систему и другие инструменты. При этом у каждого должна быть собственная история общения, персональный контекст, задачи и разграничение доступа.
Основой стал Grok Bot, а для постоянно работающей части системы я использовал арендованный виртуальный сервер в Нидерландах. Никаких принципиально новых технологий здесь нет. Интересен именно процесс разработки: я ставил задачи обычным языком, а агент самостоятельно выбирал технологии, писал программы, устанавливал зависимости, настраивал серверы, тестировал код и исправлял ошибки.
Первый работающий вариант появился за несколько часов моего непосредственного участия. Если бы я занимался этим самостоятельно, потребовалось бы значительно больше времени. Причем не потому, что я не умею программировать, а потому, что пришлось бы лично выполнять огромное количество технических операций.
Но создать работающий прототип и довести его до достаточно надежной и безопасной системы оказались совершенно разными задачами.
Первая проблема: надежность.
Первоначально Владимир периодически переставал отвечать на сообщения. Оказалось, что его облачный компьютер засыпает при отсутствии активности. Агент самостоятельно добавил диагностику, установил причину и перенес постоянно работающую часть на мой сервер. Написал необходимый код, настроил systemd, автоматический перезапуск и контроль зависаний.
Затем обнаружились другие проблемы: не всегда сохранялась история переписки, сообщения попадали в служебные журналы, возникали вопросы надежности доставки и восстановления после сбоев. Все это он тоже постепенно исправлял. С обычными программистами подобные истории происходят регулярно, но теперь для внесения исправлений мне не нужно самостоятельно лезть в код. Достаточно сформулировать проблему, определить ожидаемое поведение и проверить результат.
Вторая проблема: безопасность.
При анализе архитектуры выяснилось, что значительная часть ограничений существовала только в инструкциях самого ИИ, а агент имел довольно широкие полномочия на серверах. Фактически охранник сам устанавливал правила, сам контролировал их соблюдение и при необходимости мог самостоятельно их отменить.
Меня такая архитектура категорически не устроила.
Я потребовал отделить защищенные компоненты от самого агента. В результате появился отдельный программный шлюз, обеспечивающий авторизацию пользователей, разграничение переписки, управление токенами, очередями сообщений и подтверждениями значимых операций. Агент сохранил возможность развивать собственную прикладную функциональность, но лишился права произвольно изменять механизмы защиты шлюза.
Затем я привлек другую ИИ-модель для независимой технической экспертизы. И выяснилось, что первоначально разработанные механизмы содержали довольно неприятные ошибки:
Просроченное подтверждение операции могло оставаться действительным.
Напоминание после аварийного завершения процесса могло навсегда зависнуть в промежуточном состоянии.
Два одинаковых сообщения ошибочно воспринимались как разные задания.
При миграции могли теряться незавершенные поручения.
Ключ доступа мог сохранять действительность после отвязки пользователя.
Причем часть этих проблем не выявлялась первоначальными автоматическими тестами. Пришлось менять логику отдельных компонентов, расширять испытания и повторно проверять связанные механизмы.
Разработка шлюза прошла через множество версий и сотни автоматизированных проверок. Например, по отчету об испытаниях подготовленной версии 1.7.0 успешно прошли 553 теста, тогда как рабочая система на тот момент оставалась на версии 1.6.0.
Но даже это не означает, что система теперь идеальна. Автоматические тесты подтверждают только проверенные сценарии, а не абсолютную надежность. Кроме того, шлюз не контролирует автоматически все внешние действия, которые агент способен выполнять через другие сервисы.
Третья проблема: производительность.
Сейчас мы занимаемся дальнейшим развитием Владимира. В работе участвуют два отдельных агента: один обслуживает пользователей, другой занимается администрированием и разработкой. И появилась новая проблема: иногда даже простейший запрос обрабатывается 15–20 секунд, а более сложные операции занимают еще больше времени.
Первоначальные предложения агента выглядели стандартно: сократить инструкции, уменьшить объем передаваемых данных, упростить правила. Но почему мы решили, что причина именно в объеме инструкций? Их физический размер мало о чем говорит. Гораздо важнее логическая сложность, количество последовательных операций, вызовов инструментов и обменов между агентами.
Мы начали измерять реальные задержки. В одной из серий из 40 сообщений медианное время от передачи задания через webhook до ответа составляло около 33 секунд. Для простых запросов оно было заметно меньше, для сложных операций с инструментами значительно больше. При этом измерения еще не позволяли однозначно определить, какой именно внутренний механизм создает основную задержку.
Можно поручить ИИ переписать половину системы, потратить на это кучу времени и вычислительных ресурсов, а потом обнаружить, что быстрее она работать не стала.
Для меня это принципиальная разница. Написать программный модуль агенту относительно просто. А определить, действительно ли он нужен, как его следует спроектировать, какие он создает риски и как объективно проверить результат, уже гораздо сложнее.
Три уровня работы: ЧТО, КАК и СДЕЛАТЬ
На мой взгляд, практически в любой профессиональной деятельности можно выделить три уровня работы.
Первый: ЧТО нужно сделать. Определить реальную потребность, сформулировать цель, установить приоритеты, ограничения и критерии успеха.
Второй: КАК это сделать. Спроектировать решение, выбрать архитектуру, технологии, методы реализации, оценить риски и возможные последствия.
Третий: непосредственно СДЕЛАТЬ. Написать код, собрать программу, настроить оборудование, подготовить документы и выполнить необходимые операции.
Разумеется, в реальной работе эти уровни постоянно пересекаются. Но в целом чем выше уровень принимаемых решений, тем больше требуется самостоятельного мышления, профессионального опыта и ответственности за результат.
Именно третий, преимущественно исполнительский уровень сейчас сравнительно успешно передается ИИ. Причем не только в программировании. Нейросети уже помогают готовить чертежи, документы, отчеты, презентации, обрабатывать данные и выполнять множество других формализуемых операций.
На уровне КАК ситуация сложнее. ИИ способен предложить вполне разумную архитектуру, сравнить альтернативы и даже обнаружить серьезные недостатки человеческих решений. Но при этом может совершенно уверенно нести чушь, не замечать противоречий и недооценивать последствия собственных предложений.
А на уровне ЧТО все еще хуже, если речь идет не о генерации красивого перечня целей, а о реальном выборе между противоречащими друг другу потребностями, ресурсами и рисками.
В бизнесе я постоянно сталкиваюсь с ситуациями, когда основная сложность вообще не связана с технической реализацией. Нужно разобраться, чего действительно хочет заказчик, почему его формальные требования противоречат реальным потребностям, какие обязательства можно принять, а какие приведут к неоправданным рискам. И иногда правильным решением оказывается вообще ничего не разрабатывать, отказаться от первоначального подхода или изменить саму постановку задачи.
ИИ может помочь с анализом, подготовить документы, предложить аргументы и альтернативы. Но решение все равно принимает человек, потому что именно ему придется отвечать за последствия.
ИИ может предложить, что делать. Но решить, что действительно нужно делать и зачем, по-прежнему должен человек. По крайней мере, в тех системах и задачах, с которыми мы имеем дело сегодня.
А теперь главная проблема. Откуда возьмутся новые специалисты?
При всей моей уверенности в преимуществах ИИ есть одна проблема, которая меня действительно беспокоит.
Как руководитель и владелец ИТ-компании я прекрасно понимаю экономику разработки. Если значительную часть работы младшего программиста можно поручить ИИ, причем быстрее и дешевле, у бизнеса возникает совершенно естественное желание сократить соответствующие затраты.
Зачем нанимать джуна, платить ему зарплату, тратить время сеньоров на обучение, исправлять ошибки и ждать несколько лет, пока он приобретет необходимую квалификацию? Гораздо проще использовать готового агента и поручить контроль опытному инженеру.
Для отдельно взятой компании решение выглядит вполне рациональным.
Но если так начнут поступать все, откуда через десять или двадцать лет возьмутся новые сеньоры и архитекторы?
И это не только теоретическое предположение. Исследование Stanford Digital Economy Lab, обновленное в августе 2026 года, выявило заметное отставание динамики занятости молодых работников в профессиях, наиболее подверженных воздействию ИИ. Для возрастной группы 22–25 лет разница относительно сопоставимых менее затронутых профессий составляла 19%.
Разумеется, это не означает, что ИИ уже уничтожил 19% рабочих мест или что все наблюдаемое снижение вызвано исключительно им. Но тенденция соответствует тому, чего можно ожидать при автоматизации начальных исполнительских функций.
В других инженерных отраслях последствия могут оказаться еще серьезнее. В строительстве ошибка при проектировании ответственного узла может привести не просто к финансовым потерям, а к человеческим жертвам. В промышленной автоматизации неправильно выбранная архитектура системы управления или защиты способна привести к аварии технологического оборудования, остановке производства и другим тяжелым последствиям.
Молодой инженер традиционно начинал с относительно простых задач, постепенно приобретал опыт, учился понимать взаимосвязи между решениями и их последствиями. А если все типовые решения, простые проекты и документацию начнет генерировать ИИ, на чем он будет учиться? Кто объяснит ему, почему внешне правильный расчет или чертеж на самом деле содержит ошибку?
И кто через двадцать лет сможет проводить независимую экспертизу документации, если несколько поколений специалистов будут преимущественно проверять результаты работы нейросетей, так и не научившись самостоятельно решать аналогичные задачи?
Фактически мы рискуем разрушить механизм воспроизводства квалифицированных специалистов.
Причем проблема здесь не столько технологическая, сколько экономическая. Каждой отдельной компании выгодно сократить расходы на подготовку начинающих сотрудников, используя уже имеющиеся компетенции опытных инженеров и возможности ИИ. Но всей отрасли необходимо, чтобы кто-то продолжал готовить следующее поколение специалистов.
Получается классическая ситуация: экономию бизнес получает сегодня, а последствия нехватки квалифицированных кадров через десять или двадцать лет достанутся всем. И рассчитывать, что компании добровольно откажутся от очевидной краткосрочной выгоды ради интересов будущих поколений, довольно наивно.
Выход есть, но придется менять систему подготовки
Тем не менее тупиковой эту ситуацию я не считаю. Просто придется существенно перестраивать подготовку специалистов.
Начинающих разработчиков нужно учить не только программировать, но и формулировать требования, проектировать архитектуру, анализировать чужой и сгенерированный код, проводить испытания, выявлять ошибки и оценивать последствия технических решений.
При этом самостоятельную практику нельзя исключать. Человек должен уметь написать программу без ИИ, понимать используемые алгоритмы, устройство операционной системы, сетей и баз данных. Иначе никаким полноценным инженером он не станет. А уже после освоения фундаментальных принципов нужно учить его эффективно использовать ИИ как инструмент.
Возможно, такой подход позволит готовить квалифицированных специалистов даже быстрее, чем раньше. Ведь ИИ способен не только выполнять работу за человека, но и объяснять сложные вещи, разбирать ошибки, моделировать ситуации и выступать персональным преподавателем.
Но для этого придется сознательно сохранять задачи, которые учащийся должен выполнять самостоятельно, и создавать новые механизмы приобретения практического опыта. Компании, учебные заведения и профессиональные сообщества должны будут пересмотреть принципы подготовки, стажировок и аттестации.
А в критически важных областях потребуется особенно жестко разделять автоматизированную подготовку решений и их независимую проверку квалифицированными специалистами. Нельзя допускать ситуации, когда инженер просто подписывает документацию, сформированную ИИ, не имея достаточных знаний для ее самостоятельной проверки.
Прогресс или деградация?
В комментариях к предыдущему посту один из участников назвал происходящее деградацией человека. Я с этим не согласен.
Развитие программирования вообще представляет собой историю последовательного избавления специалистов от ручной работы. Сначала появились ассемблеры, затем языки высокого уровня, компиляторы, библиотеки, фреймворки, системы автоматической сборки и тестирования.
Каждая следующая технология позволяла выполнять меньше механических операций и заниматься задачами более высокого уровня. Когда программисты перестали вручную переводить каждую инструкцию в машинные коды, программирование почему-то не деградировало. Наоборот, появились программные системы такой сложности, которую раньше невозможно было даже представить.
Сейчас происходит следующий этап, причем гораздо более масштабный. ИИ избавляет человека не просто от необходимости писать отдельные инструкции, а от значительной части непосредственной технической реализации.
Но есть существенное отличие от предыдущих этапов автоматизации. Компилятор не выбирал за программиста архитектуру приложения, не проектировал систему безопасности и не принимал самостоятельных решений о том, какие компоненты необходимо добавить.
Современный ИИ-агент уже пытается делать все это. Иногда вполне успешно, а иногда с совершенно непредсказуемыми последствиями. Поэтому чем больше самостоятельности мы ему предоставляем, тем важнее становится квалификация человека, который определяет цели, выбирает решения и контролирует результат.
Именно поэтому я продолжаю разбираться в том, что делает Владимир, анализировать его предложения, привлекать независимые проверки и требовать исправления обнаруженных проблем. Хотя при желании вполне мог бы ограничиться общими поручениями и радоваться тому, что бот вроде бы работает.
При этом самостоятельно писать весь код больше не вижу никакого смысла. Я уже умею это делать. Просто теперь могу использовать свое время на более сложные вопросы, а непосредственную реализацию поручать ИИ.
Проблема не в том, что люди перестанут писать код собственными руками. Проблема возникнет, если они перестанут понимать, как он работает, почему система устроена именно так и какие последствия могут иметь принимаемые решения.
Вместо заключения
За время работы над Владимиром я убедился в двух вещах.
Во-первых, современный ИИ уже способен самостоятельно выполнять огромный объем технической работы, которая раньше требовала значительных трудозатрат квалифицированных разработчиков. Причем речь не только о генерации кода, но и о настройке инфраструктуры, тестировании, исправлении ошибок и развитии работающей системы.
Во-вторых, написать программу и создать правильную, надежную и безопасную систему далеко не одно и то же. ИИ отлично справляется с реализацией достаточно четко сформулированных задач, заметно менее надежно с самостоятельным проектированием сложных решений и еще хуже с определением того, какие решения вообще следует принимать в конкретных обстоятельствах.
Поэтому для квалифицированных специалистов происходящее открывает огромные возможности. Для тех, чья работа ограничивалась выполнением заранее определенных операций, перспективы гораздо менее радужные. И это касается далеко не только программистов.
Но наиболее серьезная проблема связана не с сокращением отдельных рабочих мест, а с воспроизводством профессиональных компетенций. Если мы перестанем готовить начинающих специалистов, потому что их сегодняшнюю работу дешевле выполняет ИИ, через какое-то время может оказаться, что техническую реализацию нам есть кому поручить, а вот определить, что именно нужно делать, как это правильно спроектировать и кто должен отвечать за последствия, уже некому.
И дело тут не в том, что искусственный интеллект слишком быстро развивается. Дело в том, что бизнес может слишком увлечься сегодняшней экономией и забыть о необходимости готовить тех, кто будет принимать решения завтра.
А это уже проблема, которую никаким вайбкодингом не решить.
Исследование рынка труда: Stanford Digital Economy Lab, Canaries in the Coal Mine, август 2026 года.
