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

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

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

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

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

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

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

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

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

Как это работает?

1) Разработчик описывает задачу

2) Агент выдает кусок кода, который проходит тесты.

3) Разработчик делает быстрый ревью и мержит код.

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

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

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

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

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

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

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

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

• Когда нужно быстро вспомнить, как работает конкретный метод библиотеки.

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

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

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

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

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

Если вам интересна тема AI-агентов и нейросетей, заглядывайте в мой Telegram-канал "ДругОпенсурса". Там я публикую свежие новости и разборы инструментов в числе первых.