ИИ не упростил программирование, а сделал его сложным иначе

Колонка Джереми Осборна в CACM за июль 2026 года (DOI 10.1145/3795534, CC-BY). От большинства публикаций на эту тему её отличает то, что автор опирается на эмпирические исследования когнитивных процессов в программировании, а не на личный рабочий процесс, и не занимает сторону в споре о том, полезен ли ИИ для программирования: его тезис в том, что сложность сместилась, а не уменьшилась.

Программирование требовало большой работы памяти

Отправная точка - десятилетия исследований, рассматривающих программирование как деятельность, ограниченную ресурсами памяти. Брукс (1977) описывал его как удержание множества взаимодействующих абстракций. Пеннингтон (1987) показала, что программисты полагаются на ментальные модели потоков управления и данных при проектировании, понимании и изменении кода. Солоуэй, Бонар и Эрлих (1983) выяснили, что корректность резко возрастала, когда конструкция цикла совпадала с собственным внутренним планом программиста: это доказательство того, что работа направляется когнитивными предпочтениями, извлекаемыми из долговременной памяти, а не просто знанием синтаксиса. Зигмунд и др. (2014) обследовали людей на фМРТ и обнаружили, что понимание кода активирует рабочую память, внимание и языковые зоны мозга.

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

ИИ как внешняя память

Осборн описывает ассистентов для написания кода как системы внешней памяти и опирается на три существующие теории, не изобретая собственных. Распределённое познание Хатчинса утверждает, что когнитивные системы регулярно выходят за пределы индивида в окружающую среду. Теория когнитивной нагрузки говорит, что инструменты снижают постороннюю нагрузку - воспоминание синтаксиса, шаблонный код, - освобождая рабочую память для непосредственного осмысления сути задачи. Гипотеза расширенного разума идёт дальше всех: ассистент, который всегда доступен, регулярно используется и заслуживает доверия, становится компонентом когнитивной архитектуры программиста, а не просто инструментом для консультаций.

Эмпирическая опора здесь - работа Барке, Джеймса и Поликарповой Grounded Copilot (2023), где выяснилось, что разработчики делегируют набор текста, детали API и незнакомый синтаксис, направляя свои усилия на проверку и интеграцию полученного результата. Трактовка Осборна: ассистент - это не ускоренная поисковая система, а отчасти расширение когнитивной архитектуры.

Что нельзя делегировать

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

Против излишнего оптимизма приводятся два исследования, и оба скорее противоречат общей картине статьи, чем подтверждают её:

Шихаб и др. (2025): студенты с Copilot выполняли задачи в существующей кодовой базе заметно быстрее и продвигались дальше в решении, но в итоговых интервью многие признавались, что не понимают, как и почему предложенный код работает.
Аланази и др. (2025), метаанализ контролируемых исследований ChatGPT и Copilot в обучении программированию: продуктивность и скорость выполнения задач растут, но прирост в обучении и лёгкости понимания невелик и статистически нестабилен.

Предупреждение, которое из этого следует, важно зафиксировать: устойчивые ментальные модели - это именно то, что позволяет программистам ориентироваться в кодовой базе и симулировать её выполнение в уме. Передача слишком большой части мышления на аутсорс ослабляет те самые модели, от которых зависит оставшаяся работа. Это skill-atrophy-supervision-paradox, к которому подошли со стороны когнитивных наук.

Основной тезис

Иными словами, сложная часть смещается от вспоминания ("Как это написать?") к суждению ("Имеет ли это смысл?").

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

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

Четыре сдвига

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

Место в общей картине

Это ближе всего в вики к тому самому "серьёзному техническому анализу условий, при которых разработка с помощью LLM могла бы работать хорошо", отсутствие которого в этом тематическом кластере отмечено на странице anti-llm-discourse. Статья рецензирована, ссылается на эмпирические данные (включая свидетельства против собственной позиции) и избегает как восторгов о росте продуктивности, так и полного отрицания технологии.

В описании механизма она сходится с reviewing-ai-code (стоимость верификации растёт по мере падения стоимости генерации), но отвергает вывод Депьера о том, что это ограничивает общий объём разработки. Она даёт когнитивно-научную базу для control-the-ideas-not-the-code и vibe-engineering - обе эти практики делают ставку на то, что после передачи вспоминания на аутсорс остаётся суждение о дизайне. При этом её предостережение "ментальные модели ослабевают, если делегировать слишком много" - ровно то, на что указывают их критики. По отношению к no-silver-bullet-llms позиция скорее дополняющая: Беннетт утверждает, что сущностную сложность нельзя автоматизировать, а Осборн описывает, что происходит с человеком, когда случайная сложность в основном уже снята.

Связанные страницы

recall-to-judgment - центральный сдвиг как самостоятельная концепция
skill-atrophy-supervision-paradox - риск эрозии ментальных моделей
programming-as-theory-building - версия того же тезиса от Наура о том, что на самом деле содержится в голове программиста
control-the-ideas-not-the-code, vibe-engineering - практики, предполагающие, что этот сдвиг уже произошёл
reviewing-ai-code, no-silver-bullet-llms - скептические взгляды
measuring-ai-coding-productivity - почему разрыв между эффективностью и обучением трудно измерить