"ИИ не сделал программирование проще, он просто сделал его по-другому сложным" — CACM преподнесла анти-хайп цитату

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

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

Контекст

За последние 18 месяцев комментарии лидеров в области инженерии — Карпати об автозаполнении, Нейтан Ламберт о «6 месяцах до конца», гехот о «шорах» — сходятся к общему наблюдению: программирование с помощью LLM ускоряет простые части (шаблонный код, начальную структуру, мелкие рефакторинги) и концентрирует усилия на том, что и так было сложным (проектирование систем, инварианты, анализ крайних случаев, отладка поведения кода, который ты не писал сам).

Анализ

Три тезиса из эссе, которые стоит выделить:

1. Оценка теперь — узкое место. Когда модель может выдавать правдоподобный код за секунды, минута инженера уходит на то, чтобы проверить, правильный ли это код — притом что сами спецификации часто размыты. Чтение незнакомого кода на скорости — это действительно сложный навык, а не «лёгкая» сторона программирования.

2. Отладка смещается с твоих ошибок на ошибки модели. Сбои в коде, сгенерированном LLM, отличаются от человеческих: тонко нарушенные инварианты, неидиоматичные паттерны, которые проходят тесты, но «плывут» во время исполнения, «галлюцинации» API-вызовов. Отладочные приёмы, которые ты выучил на коде от людей, плохо переносятся.

3. Когнитивная нагрузка растёт, а не падает. Даже если скорость работы растёт, инженеру приходится держать в голове две ментальные модели — замысел и сгенерированную реализацию — и проверять их согласованность. Это дорого, и именно это «выгорает» у опытных инженеров.

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

Что с этим делать

• Индивидуальное мастерство: инвестируйте в скорость чтения кода, написание спецификаций и контрольные списки оценки. Эти навыки теперь дают больший эффект, чем скорость набора текста.
• Командная практика: тестовые наборы снова становятся критически важными. Property-based тестирование и проверки инвариантов выявляют классы ошибок в коде от LLM, которые не ловят обычные unit-тесты.
• Архитектура: школа «маленькие модули, слабая связанность» получает второе дыхание — когда каждый модуль достаточно мал, чтобы его можно было легко оценить, сгенерированный LLM код становится безопаснее.

Сценарии

• Базовый случай (60%): профессия сходится к тому, что ключевыми компетенциями senior-инженера становятся «оценка» и «спецификация».
• Дескиллинг (25%): компании сокращают роль оценщика и выпускают продукт в любом случае; через 18–24 месяца следует волна инцидентов в продакшене.
• Новый инструментарий (15%): инструменты, близкие к формальным методам (property-тесты, семантические диффы), становятся новой точкой входа для junior-инженеров.

Выводы

Для лидера инженерной команды: нанимайте и обучайте оценке, а не скорости. Для CTO: ваши инвестиции в тестовые наборы теперь получили новое обоснование ROI. Для junior-инженера: читайте больше кода, чем пишете.