Почему AI не заменит программистов (и при чем тут краны)

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

Цифры рассказывают любопытную историю. В 1935 году в США было около 2000 операторов счётно-перфорационных машин. К 1965-му — уже 80 000 программистов. К 1995-му — полмиллиона. Сейчас — больше 2,5 миллиона. Несмотря на десятилетия «автоматизационной паники», профессия не просто выжила — она взорвалась.

Что реально изменилось? Не то, пишут ли люди код, а как и зачем.

Куда перемещается бутылочное горлышко

Самое интересное: каждый десяток лет кто-то объявляет, что «главная сложность» разработки наконец решена. Сначала компиляторы сделали ассемблер доступным. Потом языки высокого уровня спрятали управление памятью. Затем фреймворки автоматизировали типовые паттерны. Теперь AI-агенты обещают писать код сами.

Каждый раз сценарий одинаковый: узкое место уходит выше по цепочке.

Раньше программистам нужны были глубокие знания архитектуры железа — держать в голове сложные состояния, свободно говорить на диалектах компиляторов и оптимизаторов. Это было конкурентным преимуществом. Сейчас? Эти знания всё ещё важны, но это базовые требования, а не отличия.

Современные разработчики большую часть времени тратят на размытую работу: понять, что строить (спецификация), убедиться, что это работает, и отвечать за результат (ответственность), а также хранить глубокое институциональное знание, которое связывает бизнес-контекст с технической реализацией. Звучит знакомо? Это не ново — так было всегда. Просто сейчас мы замечаем это больше, потому что «исполнительный» слой всё легче передать кому-то другому.

Теория кранового оператора

Исследователи Арвинд Нараянан и Сайаш Капур недавно сделали наблюдение, которое заслуживает большего внимания: когда AI сжимает «исполнительный» слой разработки, роль разработчика всё больше напоминает кранового оператора на стройке.

Подумайте. Современные стройплощадки оснащены невероятно сложным оборудованием. Крановщик не поднимает материалы вручную — он управляет мощной машиной, которая делает тяжёлую работу. Навык не в физическом усилии, а в понимании что поднимать, куда класть и как координироваться с остальными.

Аналогично, разработчики, работающие с AI-кодерами, не строчат строки кода в спешке. Они направляют интеллектуальные инструменты, проверяют результаты, соединяют куски — и, что важнее всего, решают что эти куски должны собой представлять.

Крановый оператор не устранил строителей. Он трансформировал строительную работу и позволил возводить гораздо более сложные конструкции. То же самое произойдёт с AI в разработке.

Почему код никогда не был проблемой

И вот истина, которая часто теряется в споре AI vs разработчики: написание кода никогда не было узким местом.

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

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

2. Проверка и ответственность — Код, который «работает», может быть неправильным. Он может быть небезопасным, не масштабируемым или несовместимым с существующими системами. Кто-то должен за это отвечать.

3. Хранение институционального знания — Кодовые базы глубоко переплетены с бизнес-логикой, поведением пользователей и организационными особенностями. Этот контекст не существует ни в какой документации — он живёт в головах опытных разработчиков.

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

Исследование 270 профессий

Вот статистика, которая должна сбить спесь с любого AI-евангелиста: в Переписи населения США 1950 года было 270 различных занятий. Только одно было в итоге полностью автоматизировано — лифтёр.

Многие другие были трансформированы или сокращены новыми технологиями: телеграфисты, наборщики. Но не устранены полностью. Новые технологии создали категории работы, которых раньше просто не существовало.

Мы уже видим это с AI. Спрос на «AI-инженеров» и «промпт-инженеров» взлетел. Более тонко — растёт спрос на разработчиков, которые умеют эффективно управлять AI-инструментами. Эти роли не существовали пять лет назад.

Что это значит для вашей команды

Если вы строите стартап или управляете командой разработки, вот практический вывод: самые ценные разработчики в эпоху AI — это не обязательно те, кто пишет больше всех кода.

Это те, кто:

• Может чётко объяснить, что строить и почему
• Глубоко понимает бизнес, чтобы принимать правильные решения
• Знает, как проверять и (адекватно) доверять сгенерированному AI коду
• Умеет собирать разрозненные части в связные системы
• Хранит институциональное знание, которое делает возможной будущую разработку

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

Аналогия с хостингом

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

Эта автоматизация не устранила потребность в экспертизе инфраструктуры — она трансформировала её. Сегодня ценный навык — знать какие управляемые сервисы использовать, как проектировать масштабируемость и когда опускаться на уровень ниже.

AI-кодеры представляют ту же эволюцию для разработки. Рутинная работа автоматизируется. Работа по принятию решений остаётся человеческой.

Взгляд в будущее

Мы в захватывающем, неудобном переходном периоде. Инструменты мощные, но несовершенные. Workflows ещё выстраиваются. «Правильный способ» работы с AI-помощниками пока открыт.

Это и есть суть. Каждый серьёзный переход в разработке — от ассемблера к языкам высокого уровня, от монолитов к микросервисам, от on-premise к облаку — ощущался хаотичным во время перехода. Хаос — это там, где живёт возможность.

Разработчики, которые процветут, — это не те, кто сопротивляется AI-инструментам. Это те, кто разберётся, как их эффективно направлять — разовьёт суждение, контекст и навыки координации, которые AI не может воспроизвести.

Код будет писать себя всё больше. Интересные вопросы — какой код писать и почему — останутся упрямо, красиво человеческими.

Какие изменения вы заметили в своём рабочем процессе? Используете AI-помощников, и если да — что реально изменилось в том, как вы проводите время? Пишите в комментариях — хочется услышать, как эта эволюция проявляется в реальных командах.