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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Раньше процесс решения задач разработчиком выглядел примерно так. Столкнувшись с непонятной проблемой, программист сначала погружался в себя, затем обращался к коллегам, искал ответы через 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 этот принцип проявляется особенно ярко: сложные системы требуют больше, а не меньше экспертизы.

Заключение

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

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

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