Почему «старые» IT-шники ненавидят AI. И почему они правы

Стена, которую я встречаю каждый раз

Я внедряю AI-решения в компании. И почти каждый проект начинается одинаково. Не с технических проблем. Не с нехватки данных. С сопротивления изнутри.

Заказчик говорит «да». Руководство говорит «вперёд». А IT-отдел молча строит стену.

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

Обидно? Конечно.

Но дело не в обиде. Дело глубже. Намного глубже. И чтобы понять это, нужно вернуться в 1981 год.

Кривая Бёма. График, который построил всю IT-индустрию

В 1981 году инженер по имени Барри Бём нарисовал один график. Он назвал его «кривая стоимости изменений» (Cost of Change Curve).

Суть была простой и пугающей одновременно.

В классической разработке каждая правка дорожает экспоненциально по мере продвижения проекта:

• Ошибка на этапе требований стоит $1
• Та же ошибка на этапе проектирования стоит $5
• На этапе разработки $10
• На этапе тестирования $50
• На продакшене, когда продукт уже живой, та же самая ошибка обходится в $10,000

Один и тот же баг. Разница в десять тысяч раз. Просто потому, что его нашли поздно.

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

Это не тупость. Это рациональная защита. В мире, где каждая ошибка становится бомбой замедленного действия, паранойя является нормой.

Потом попробовали работать «короткими забегами». Стало лучше, но не сильно

В начале 2000-х в IT придумали новый подход. Вместо того чтобы полгода строить продукт «вслепую», а потом показывать заказчику, начали работать короткими циклами по 2 недели. Каждые две недели показываешь результат, получаешь обратную связь, корректируешь курс.

Этот подход назвали Agile (от англ. «гибкий»). Идея простая: чем чаще проверяешь, тем меньше накапливается ошибок. Двухнедельный цикл вместо полугодового релиза означал, что стоимость ошибки снизилась в разы.

Но проблема не исчезла. Она стала мягче.

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

Стало лучше, да. Но правило осталось тем же: чем позже меняешь, тем дороже платишь.

А потом пришёл AI. И сломал кривую

Когда работаешь через Claude Code и подобные AI-инструменты, первые четыре шага классического цикла разработки. понять, найти, поменять, протестировать. схлопываются в один промпт.

Цикл итерации сжимается с дней до минут.

Пивот перестаёт быть катастрофой с пересмотром бюджета. Он становится штатной операцией. Как сохранение файла. Как переключение вкладки.

Реальный пример с прошлой недели. Заказчик трижды менял логику воркфлоу в проекте автоматизации. В старой парадигме это означало бы:

• Три раунда согласований
• Дополнительные бюджеты на переработку
• Спокойный нервный тимлид
• Срыв сроков минимум на две недели

У меня это заняло три промпта и час работы. Без согласований. Без доп. бюджета. Без нервов.

Что я на самом деле продаю

И вот тут я осознал свою реальную ценность.

Я не продаю код. Код может написать кто угодно. Даже ChatGPT. Ладно, не будем об этом.

Я продаю плоскую кривую стоимости изменений.

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

И это больше не стоит состояние.

Мне не нужно чётко формализованное техническое задание, разложенное по полочкам. Мне нужно понять результат. Дальше идут итерации по живой обратной связи от бизнеса.

Почему IT-шники сопротивляются. И почему они правы

Теперь давайте будем честны.

IT-специалисты сопротивляются не потому что глупые. Не потому что ленивые. Не потому что «боятся нового».

Они сопротивляются, потому что вся их экономическая модель построена на одном фундаменте: изменения дорогие.

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

А теперь приходит кто-то и демонстрирует, что изменения стали почти бесплатными.

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

Конечно, это больно. Конечно, это вызывает сопротивление. И они имеют на это полное право.

Три типа реакции, которые я наблюдаю

За десятки внедрений я выделил три типа реакции IT-специалистов на AI-инструменты.

«Это игрушка»

«Нейросеть пишет говнокод. Это не для серьёзных проектов. Через год хайп пройдёт.»

Обычно это говорят люди, которые пробовали ChatGPT один раз, получили кривой ответ и решили, что весь AI такой. Они оценивают технологию 2025 года по опыту с демо-версией 2023 года.

«Это угроза»

Молчаливое сопротивление. Саботаж на уровне процессов. «Нам нужно ещё три недели на ревью архитектуры». «Без полного покрытия тестами не деплоим». «У нас политика безопасности не позволяет».

Формально всё правильно. Фактически, это способ замедлить то, что нельзя остановить.

«Это инструмент»

Самая малочисленная, но самая перспективная группа. Люди, которые не воюют с новой реальностью, а адаптируются. Синьор, который использует AI для рутины и фокусируется на архитектуре. Тимлид, который переосмысляет процессы. Разработчик, который учится управлять AI-инструментами вместо того, чтобы конкурировать с ними.

Угадайте, какая группа через пять лет будет диктовать рынок.

Новая экономика разработки

Давайте посмотрим на цифры. Не абстрактные, а конкретные.

Классический проект автоматизации бизнес-процесса:

• Сбор требований: 2–4 недели
• Проектирование: 2–3 недели
• Разработка: 4–8 недель
• Тестирование: 2–3 недели
• Правки после тестирования: 2–4 недели
• Итого: 3–6 месяцев, команда 5–8 человек

Тот же проект с AI-подходом:

• Первый рабочий прототип: 1–3 дня
• Итерации по обратной связи: 1–2 недели
• Финализация и деплой: 1 неделя
• Итого: 2–4 недели, 1–2 специалиста

Разница не в процентах. Разница в порядках. И это не фантазии. Это реальные кейсы из практики Progressive AI.

Что это значит для бизнеса

Если вы руководитель и читаете это, вот что вам нужно понять.

Плоская кривая стоимости изменений означает свободу.

Свободу ошибаться на старте. Свободу менять направление после первых результатов. Свободу экспериментировать без шестизначных бюджетов.

Вам не нужно тратить три месяца на идеальное ТЗ. Потому что стоимость ошибки в требованиях перестала быть катастрофической.

Вам не нужна команда из десяти человек. Потому что AI умножает производительность одного специалиста в десятки раз.

Вам не нужно бояться пивота. Потому что разворот на 180 градусов стоит столько же, сколько мелкая правка.

Лучшее время внедрять AI было год назад. Второе лучшее время. сейчас.

Мир дорогих изменений заканчивается

Мы находимся в точке перелома. Старая парадигма, где изменения дорогие и каждое решение нужно обдумывать месяцами, уходит.

Новая реальность, где итерация стоит копейки, а скорость запуска измеряется днями, уже здесь.

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

Вопрос не в том, произойдёт ли это. Вопрос в том, на какой стороне кривой вы окажетесь.