В индустрии эффективность программиста часто оценивают по скорости написания кода или количеству закрытых задач. С появлением ИИ-агентов эти метрики выросли, но возникла новая проблема: код пишется быстрее, а понимание системы у разработчиков падает. В статье рассматривается, как концепция Питера Наура «программирование как построение теории» помогает понять риски использования LLM в разработке.

Код — только верхушка айсберга

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

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

По мнению Наура, если команда покидает проект, теория исчезает. Остается только код — «мертвый» артефакт. Новые разработчики могут его читать, но без внутренней модели их правки постепенно разрушают архитектурную целостность.

ИИ-агенты и разрыв ментальной модели

Современные ИИ-агенты работают на основе статистического предсказания следующего токена. Они не строят теорию. Когда разработчик делегирует задачу агенту, он пропускает ключевой этап — формирование понимания.

Процесс выглядит так:

1. Разработчик описывает задачу.
2. Агент генерирует код, который проходит тесты.
3. Разработчик делает быстрое ревью и сливает изменения.

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

Ограничения и риски автоматизации

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

Агенты часто предлагают локально корректные, но архитектурно чуждые решения. Без глубокой теории в голове разработчик может не заметить противоречия. Снаружи система работает, но внутри — фрагментированная логика, несогласованные подходы.

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

Когда ИИ-агенты действительно полезны

Проблема не в ИИ, а в способе его применения. Инструменты оправданы там, где построение теории минимально:

• Написание простых DTO, мапперов, базовых CRUD-операций с очевидной логикой.
• Генерация тестов, особенно для покрытия краевых случаев в уже понятном коде.
• Быстрое напоминание синтаксиса или работы методов библиотек.

Микро-анализ: компромисс между скоростью и знанием

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

Разработчики сталкиваются с выбором:

• Использовать ИИ «бездумно» — получить прирост скорости, но потерять контроль через несколько месяцев.
• Использовать ИИ как помощника — перепроверять каждое решение и интегрировать его в свою ментальную модель. Этот путь медленнее, но сохраняет теорию программы.

Практический итог

Программирование — это в первую очередь когнитивная деятельность. Если инструмент устраняет необходимость думать и анализировать структуру, он лишает вас понимания продукта.

Используйте агентов для ускорения рутины. Критическую логику и архитектурные решения лучше прорабатывать вручную.

В индустрии принято оценивать эффективность программиста по скорости написания кода или количеству закрытых тикетов. С появлением ИИ-агентов эти метрики выросли, но возникла проблема: код пишется, а понимание системы у разработчиков падает. В этой статье разберем, как концепция Питера Наура «программирование как построение теории» объясняет скрытые риски использования LLM в разработке.

Код — только верхушка айсберга

В 1985 году Питер Наур опубликовал работу, где утверждал, что программирование — это не процесс создания текста, а процесс формирования теории в голове человека. Это ментальная модель, которая включает:

• Понимание того, как части системы связаны между собой.

• Знание причин, по которым были выбраны конкретные решения и почему были отвергнуты другие.

• Способность предсказать, как изменение в одном модуле отразится на всей системе.

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

ИИ-агенты и разрыв ментальной модели

Современные ИИ-агенты  работают по принципу статистического предсказания следующего токена. Они не строят теорию. Когда разработчик делегирует написание функции или исправление бага агенту, он пропускает этап построения теории.Как это работает?

1) Разработчик описывает задачу2) Агент выдает кусок кода, который проходит тесты.3) Разработчик делает быстрый ревью и мержит код.

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

Ограничения и риски автоматизации

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

Когда ИИ-агенты действительно полезны

Проблема не в самих инструментах, а в способе их применения. ИИ оправдан там, где построение теории минимально:• Написание простых DTO, мапперов или базовых CRUD-операций, где логика очевидна.• Написание тестов, особенно если нужно покрыть краевые случаи в уже понятном коде.• Когда нужно быстро вспомнить, как работает конкретный метод библиотеки.

Микро-анализ: компромисс между скоростью и знанием

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

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

Практический итог

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

В своем телеграм канале "ДругОпенсурса" можно в числе первых узнать о свежих новостях в мире ИИ, ИИ-агентах и не только.