Непопулярное мнение: ИИ не изменит IT

ИИ обучается на существующих данных, как джуниор-разработчик на Stack Overflow, и становится похож на мидла. Но сможет ли он когда-нибудь дорасти до сеньора?

Заголовки вроде «Программисты будут не нужны через пять лет» появляются всё чаще, а модели, такие как ChatGPT и GitHub Copilot, демонстрируют впечатляющие способности в написании кода, однако мы считаем, что никаких серьезных изменений в IT-сфере в ближайшие годы не случится. В этой статье мы предлагаем к обсуждению свои аргументы для такого непопулярного мнения.

Новые инструменты часто описываются как серебряные пули, но на практике такими не оказываются

Эта мысль не нова: в статье «No Silver Bullet» Фредерик Брукс ещё в 1986 году писал о том, что нет технологии, способной радикально ускорить разработку. Он говорил, что «серебряной пули» нет:

• Нельзя автоматизировать творчество и анализ требований.

• Даже ИИ не устраняет необходимость понимать задачу.

• 90% работы — это «некодируемые» аспекты: общение, компромиссы, адаптация к изменениям.

Прошло почти 40 лет, но его выводы остаются актуальными. Творчество ИИ — глючно, так как не удовлетворяет неявным требованиям. Связь с реальностью, необходимая для действительного понимания задачи, отсутствует у всех LLM, поэтому они не могут создавать решения без человека. И, конечно, общение с ИИ не заменяет общение в команде, шеринг общего понимания задачи и решения.

Тем не менее в маркетинговых статьях новому инструменту поются дифирамбы. Почему это происходит? В книге «Человеческий фактор» Том Демарко и Тимоти Листер заявляют так: «Многие руководители готовы согласиться с тем, что сталкиваются больше с человеческим фактором, нежели с техническими сложностями. Однако они редко учитывают это на практике. Они руководят так, будто их главной заботой является именно технология. Они проводят столько времени в размышлениях о самых запутанных и интересных головоломках, которые предстоит решать подчиненным, будто сами собираются делать эту работу, а не руководить коллективом. Они находятся в вечном поиске технологического прибамбаса, который должен автоматизировать часть работы (более подробно об этом эффекте рассказано в главе 6 «Лаетрил»), тогда как направление их деятельности, связанное с человеческим ресурсом, зачастую получает низший приоритет.»

Упомянутый лаетрил — это бесцветный экстракт из абрикосовых косточек. Мошенники в Мексике продают его как лекарство от рака. Разумеется, он ничего не лечит. Но раковые больные находятся в отчаянном положении и готовы поверить на слово. Кажется, что и менеджеры в погоне за производительностью приходят в такое же отчаяние, и становятся подвержены ложным надеждам на технологии. Листер и Демарко собрали целый букет ложных надежд в сфере ИТ и перечислили их в разделе «семь надежд руководителя разработки программного обеспечения». Приведем один из примеров: «Все уже автоматизировано; не пора ли напрочь автоматизировать персонал, разрабатывающий программное обеспечение?» И исследователи отвечают: «Это ещё одна вариация на тему иллюзии высоких технологий — вера в то, что разработчики программ выполняют работу, легко поддающуюся автоматизации. Их основная работа — человеческое взаимодействие, позволяющее преобразовать изложенные пользователями потребности в формальное представление. Кто-то должен делать эту работу независимо от того, какие формы принимает цикл жизни продукта. И вряд ли возможно данную задачу автоматизировать.»

При взгляде снаружи кажется, что люди поглощают данные и выплёвывают файлы: аналитики, менеджеры, архитекторы и разработчики — все занимаются этим. Все эти тексты, схемы и картинки хранятся на компьютере в цифровом формате, так почему бы не автоматизировать перевод из одного формата данных в другой?

От потребностей пользователей — в формальное представление, как это происходит?

Преобразование расплывчатых пожеланий пользователей в работающее ПО — многоэтапный процесс, где на каждом шаге теряется часть информации, но добавляется формальность. Сначала требования просто фиксируют на естественном языке: описывают текущие процессы, боли и желания пользователей. Уже здесь возникает первая проблема — люди не привыкли вербализировать весь контекст, который используют в реальном процессе.

Затем начинается анализ: функциональный (что нужно сделать) перетекает в системный (как это реализовать). На каждом этапе часть нюансов теряется, часть — формализуется. Архитектор, получая эти артефакты, проектирует систему, порождая новые документы — спецификации, файлы конфигурации, скрипты. Здесь проявляется неявное знание, которое нельзя было прямо вывести из изначальных требований. Далее менеджеры создают структуру проекта (задачи в трекерах, дорожные карты), а разработчики пишут код.

В принципе, на каждом этапе современные большие языковые модели могут помогать. Но они могут помогать именно как источники шаблонных решений, не учитывающие всего контекста конкретного проекта. И их решение необходимо проверять специалистам соответствующей квалификации.

Итого: даже с ИИ каждый этап требует экспертов, которые:

1. Восстанавливают утраченные на предыдущих шагах нюансы,

2. Добавляют профессиональное суждение,

3. Проверяют, что формальные артефакты действительно решают изначальную проблему.

Именно поэтому «просто записать требования и нажать на кнопку ИИ» не получится — цепочка преобразований слишком сложна и контекстно-зависима.

Производительность разработки ограничена не скоростью написания кода, а скоростью уточнения требований и проверки гипотез

Многие задачи в IT связаны не столько с написанием кода, сколько с пониманием того, что именно нужно реализовать. Поиск общего видения, обсуждение требований, согласование деталей с заказчиком — всё это занимает больше времени и сил, чем кажется. И именно на этом этапе могут возникать недопонимания, которые приводят к правкам и существенно удорожают проект.

Понимание сложных задач требует значительных ресурсов, поэтому их часто доверяют узкому кругу специалистов: продукт-менеджеру, аналитику и архитектору. Эти эксперты полностью погружаются в контекст, удерживают в голове общую картину и разбивают крупную задачу на четкие подзадачи для разработчиков, дизайнеров и тестировщиков. Такой подход позволяет сохранить целостное видение задачи и избежать искажений при передаче.

Но синтез решения становится возможен благодаря личному опыту специалистов, который выступает контекстом решения задачи. Этот контекст по принципу системного мышления ^[1] никогда не бывает полностью задокументирован. Поэтому даже если ИИ поможет создать решение, его необходимо будет проверить человеку.

Эволюция поиска решений в разработке программного обеспечения

Раньше процесс решения задач разработчиком выглядел примерно так. Столкнувшись с непонятной проблемой, программист сначала погружался в себя, затем обращался к коллегам, искал ответы через Google, изучал решения на Stack Overflow или читал тематические статьи на Хабре. Это был полностью ручной процесс поиска информации, требующий значительных временных затрат. Найденные решения интегрировались и проверялись, а задача отправлялась в тестирование.

С появлением ИИ-технологий процесс изменился не существенно. Теперь разработчик может напрямую обратиться к ИИ-ассистенту, встроенному в среду разработки или доступному через специальные чаты. Такой помощник мгновенно генерирует возможные решения или объяснения. Однако важно понимать, что ИИ не всегда предоставляет идеальные ответы — иногда код оказывается устаревшим или содержит ошибки, а в случае уникальных проблем (например, багов после обновления системы) ИИ и вовсе может оказаться бесполезным. Как и раньше, предложенные решения необходимо проверять.

Эффективность применения ИИ определяется природой самих задач. Для типовых, уже решенных кем-то проблем, современные инструменты (как традиционные, так и ИИ) работают прекрасно. Но поскольку автоматизированные системы обучаются на существующих данных, они не могут помочь, когда разработчик сталкивается с по-настоящему новой, нестандартной задачей.

При этом важно отметить, что основная сложность современной разработки заключается не столько в написании кода (хотя это остается важной частью работы), сколько в грамотном проектировании архитектуры приложений, эффективной автоматизации бизнес-процессов и создании действительно полезных инструментов, улучшающих жизнь пользователей. Именно эти аспекты требуют глубокого понимания и человеческого подхода, который пока не может быть полностью автоматизирован.

А разве ИИ не может помочь с грамотной архитектурой?

ИИ может помочь и с архитектурой, например, предложить подходящие шаблоны проектирования, набросать базовую структуру для работы с данными, но его решения не смогут учесть всех нюансов. Чтобы создать правильный промпт, вам понадобится провести аналитическую работу по сбору требований, а потом еще одну — по проверке предложенного решения.

В каких задачах ИИ может помочь? В рутинных или стандартных, таких как:

1. Генерация шаблонных решений
   ИИ хорошо справляется с типовыми сценариями: может предложить стандартную схему микросервисов для e-commerce или типовую клиент-серверную архитектуру. Например, по запросу "спроектируй REST API для трекинга заказов" выдаст вполне работоспособную базовую структуру. Но опытные специалисты и раньше не делали работу с нуля, а брали за пример похожее готовое решение или шаблон.

2. Анализ требований
   Нейросети умеют вычленять ключевые нефункциональные требования (нагрузка, отказоустойчивость) из ТЗ и подсказывать подходящие паттерны (например, предложить кеширование Redis при частых запросах одних данных).

3. Выявление противоречий
   Некоторые ИИ (например, Amazon CodeWhisperer) могут находить архитектурные антипаттерны в существующем коде — скажем, избыточную связность модулей.

Для младших разработчиков или тех, кто впервые начинает проект, такие подсказки могут показаться значительными. Но для опытных разработчиков использование ИИ избыточно усложняет процесс: когда ты уже понял задачу от бизнеса и знаешь, как лучше её решать — работать над промптом ИИ, а потом проверять его решение.

Проблема заключается не только в том, что решения ИИ нужно проверять, но и в том, что высокая скорость генерации этих решений подталкивает пользователя к созданию вариантов выбора. Однако анализ и выбор из них может занять длительное время. ИИ не сможет принимать решение в следствие ограничений:

1. Он не понимает всего контекста бизнеса,

2. Не может учесть всех ограничений реальной системы,

3. Не понимает специфики legacy-систем, с которыми нужно интегрироваться.

Это напоминает ситуацию с CAD-системами в строительстве: компьютер рисует идеальные чертежи, но инженер должен понимать, где будет стоять здание и кто в нём будет жить.

Конечно, можно сказать: «пусть он не понимает контекста бизнеса, но ведь можно же загрузить ему этот контекст!» Вроде бы действительно можно, если у вас есть документация, список требований, вы готовы загрузить документы, которые касаются бюджета, и главное — есть человек, который этим займётся.

Ключевые решения всё равно принимает человек, потому что:

1. Архитектура — это компромисс между техникой, бизнесом и людьми,

2. 50% работы архитектора — это коммуникация (стейкхолдеры, команда), где ИИ бесполезен,

3. Настоящие проблемы проявляются только в процессе реализации.

Вот как об этом сказал Питер Друкер: «В интеллектуальном труде задачу нужно сформулировать самому. “Каковы ожидаемые результаты этой работы?” — вот главный вопрос, определяющий эффективность интеллектуального работника. Этот вопрос требует рискованных решений. Обычно на него нет правильного ответа — есть только разные варианты действий. Нужно четко понимать конечный результат, чтобы добиться эффективности при его достижении.»

Почему ИИ не заменит менеджеров проектов

Одно из основных препятствий для замены менеджеров ИИ — вопрос ответственности. Управление проектом подразумевает принятие решений и несение ответственности за результат, что невозможно переложить на инструмент, даже самый совершенный. ИИ может выступать консультантом или автоматизировать рутину, но конечное решение всегда остаётся за человеком — точно так же, как в медицине или юриспруденции.

Что ИИ действительно может сделать:

• Генерировать стандартные отчёты (хотя эту задачу решали и до появления ИИ);

• Анализировать объёмную переписку и документацию, делая выжимки;

• Ускорять работу с wysiwyg-редакторами, например, создавать презентации по кратким описаниям.

Но ключевая проблема не в этом:
Когда ИИ экономит время менеджера, бизнес чаще всего использует это не для улучшения качества управления, а для увеличения нагрузки. Менеджер, который раньше вёл один проект, теперь получает два — и вынужден постоянно переключаться между контекстами. Это приводит к поверхностной работе, ошибкам и выгоранию.

Альтернатива — тратить сэкономленное время на:

• Глубокую работу с командой (фасилитация, налаживание процессов),

• Личное развитие и отдых сотрудников.

Однако бизнес редко выбирает этот путь: повышение лояльности команды не выглядит для него достаточным аргументом. В результате ИИ становится не инструментом разгрузки, а способом увеличить нагрузку — и это лишь усугубляет главную проблему управления: необходимость человеческого внимания и ответственности.

ИИ изменит не суть работы менеджера, а лишь её интенсивность. Без пересмотра подходов к организации труда автоматизация приведёт не к освобождению, а к перегрузу — и тем ярче проявит ценность настоящего управления, которое невозможно без человеческого участия.

Два типа задач в технической поддержке и роль ИИ

Теперь поговорим о техподдержке — фронтире, на котором одним из первых были введены чат-боты, и который, по мнению некоторых журналистов, должны быть в скором времени полностью заменены ИИ.

В работе технической поддержки можно выделить два принципиально разных типа задач, каждый из которых требует особого подхода:

1. Стандартные запросы: это коммуникация о полностью известной проблеме или задаче. Для таких рутинных операций полностью определена последовательность действий, и нужная информация имеется в базе данных. Часто, подобную задачу можно решить самостоятельно без обращения в техподдержку.

Примеры:

• Запрос справочной информации;

• Диагностическая проверка по скрипту;

• Ответы на часто задаваемые вопросы.

2. Нестандартные запросы. В этом случае коммуникация ведется о новой, неизвестной задаче, для которой необходимо провести анализ и предложить творческое решение. Эти случаи характеризуются:

• Отсутствием готового шаблона для решения;

• Необходимостью анализа контекста;

• Требованием индивидуального подхода;

• Возможностью множества вариантов интерпретации.

Примеры:

• Уникальные или новые баги, не описанные в документации;

• Запросы на доработку системы;

• Ситуации, когда клиент не может чётко сформулировать проблему;

• Необходимость найти обходное решение при ограничениях системы.

Проблема применения ИИ в том, что он не может одновременно анализировать контекст и предлагать творческие решения. Он либо строго следует инструкциям и бесполезен для сложных кейсов, либо «фантазирует», рискуя дать ложный ответ.

Первый уровень поддержки — уже регламентирован

Обычно первый уровень поддержки осуществляют люди-операторы, работающие по шаблонам:

• У них есть готовые сценарии ответов на типовые вопросы;

• Они действуют строго по протоколу.

Сейчас в некоторых компаниях их заменяют:
✔ Голосовые роботы (распознают речь и отвечают записанными фразами).
✔ Простые ИИ-помощники (например, чат-боты с предсказуемыми ответами).

Такая автоматизация может ускорять решение простых кейсов, но усложняет коммуникацию для нестандартных запросов. Если вопрос выходит за рамки шаблонов, система не справляется — приходится переключать на человека. Клиент раздражается от того, что вынужден «заново» ждать, пока сотрудник поддержки погрузится в их проблему. Поэтому многие сразу пишут в чат «Позовите человека», не желая тратить время на этап с ИИ-ботом. Хотя чат-боты действительно сокращают затраты компаний, живая поддержка сохраняет лояльность клиентов — что в долгосрочной перспективе может принести больше прибыли, чем экономия на персонале.

Клиенто-ориентированная техподдержка — почему её нельзя поручить ИИ

Инженеры техподдержки, обрабатывающие нестандартные запросы клиентов, не могут быть заменены искусственным интеллектом из-за особенностей своей работы.

Во-первых, такой специалист становится полноценным представителем интересов клиента внутри компании. Он имеет доступ к реальным системам логирования и мониторинга, к базам данных и конфигам, внутренним сервисам компании. Он может инициировать межотдельное взаимодействие, например, обратиться к разработчикам для хотфикса.

Во-вторых, инженер, в отличие от ИИ, несёт финансовую и юридическую ответственность, и так же может принимать решения об эскалации проблемы, привлечении ресурсов и изменения приоритетов обработки. Он предсказывает риски и предпринимает шаги для уменьшения последствий для процессов клиента.

В-третьих, специалист техподдержки адекватно интерпретирует эмоциональные обращения и имеет контекстную экспертизу, учитывающую:

• Историю взаимоотношений с клиентом;

• Особые условия контракта;

• Уникальные доработки системы.

Поэтому клиенто-ориентированная поддержка требует полномочий для действий в реальном мире, способности учитывать скрытый контекст и готовности нести ответственность за решения. Всё это могут только люди.

Автоматизация vs. реальная эффективность: почему ИИ не станет «серебряной пулей» для IT

Когда нам предлагают очередное «революционное» решение — стоит задать простой вопрос: кому на самом деле это упрощает жизнь? Cтремление к автоматизации пронизывает всё общество, и прежде чем предрекать замену разработчиков ИИ, давайте рассмотрим эволюцию розничной торговли — здесь уже произошла «революция автоматизации», результаты которой поучительны:

1. Как работал традиционный магазин (1990-е – 2000-е):
Цепочка поставок: Производитель → Оптовый склад → Склад магазина → Продавец.

• Роль персонала:

  • Товароведы формировали удобную выкладку,

  • Продавцы знали ассортимент и быстро комплектовали заказы,

  • Кассиры профессионально обслуживали очередь.

• Клиентский опыт: Покупка 10 товаров занимала 5-7 минут.

2. «Оптимизированный» современный супермаркет:

• Что изменилось:

  • Клиент сам ищет товары в огромном зале (экономия на товароведах),

  • Самообслуживание на кассах (сокращение штата кассиров).

• В результате — скрытые издержки:

  • Среднее время покупки выросло до 25-30 минут,

  • Ошибки при самопроверке создают очереди на перепроверку,

  • Потеря персонального сервиса.

3. Парадокс автоматизации:
Магазины преподносят это как удобство, но реальные выгоды получает только бизнес:

• Снижение затрат на персонал на 40-60%,

• Увеличение импульсных покупок за счет долгого нахождения клиента в зале,

• Перенос труда (и ответственности за ошибки) на покупателя

Если провести параллель с IT, то становится видно, то же самое происходит с идеей заменить разработчиков ИИ:

1. Мнимая эффективность:

   • Да, ИИ генерирует код быстрее человека

   • Но вся нагрузка по проверке, тестированию и доработке ложится на:

     • Менеджеров (которые не являются техническими специалистами),

     • Тестировщиков (чей штат не увеличивают),

     • Пользователей (которые хотят быстрого решения своих задач, а не создавать баг-репорты).

2. Скрытые затраты:

   • Время на исправление ошибок ИИ часто превышает время ручного написания кода,

   • Потеря экспертизы (как в магазинах исчезли профессиональные продавцы),

   • Рост технического долга из-за неоптимальных решений,

   • Потеря лояльности аудитории.

Поэтому автоматизация должна:
✔ Сохранять профессиональные роли,
✔ Учитывать реальные, а не гипотетические процессы,
✔ Улучшать, а не ухудшать качество результата.

Как показал опыт ритейла, перенос труда на конечного пользователя — это не инновация, а регресс. В IT этот принцип проявляется особенно ярко: сложные системы требуют больше, а не меньше экспертизы.

Заключение

ИИ становится привычной частью рабочих процессов, и это — естественное развитие технологий. Инженерам не стоит воспринимать это как угрозу, скорее как возможность. Новые инструменты позволяют сосредоточиться на сложных задачах, оставить рутину машине и делать работу быстрее и качественнее.

Важно помнить, что ценность интеллектуального труда — в человеке, который принимает решения, умеет работать с неопределённостью и создаёт новое. Именно эти качества определяют хорошего инженера, и именно они остаются вне зоны досягаемости ИИ.

Мы считаем, что каким бы умным не был ИИ, он не сможет брать на себя ответственность. Да и вы навряд ли захотите её отдавать. Проверим? Ответьте на пару вопросов!