«Код != не программа»: почему опытные разработчики важнее, чем когда-либо

от admin

И не только джунам для перенятия опыта

В 1985 году ученый Петер Наур написал: программа — это не код, а теория.

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

Код ≠ программа

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

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

Как мы теряем смысл

Экрем поделился мнением, что мы сегодня пришли к кризису теории. Причины очевидны:

  • ИИ-помощники генерируют код без контекста.
  • Молодые разработчики используют его рефлекторно, без анализа.
  • Бизнес подталкивает к скорости, а не к качеству.

Код растет, архитектура рушится. Никто не знает, как и почему что-то работает. И что будет, если это изменить.

Читать также:
Обучавший ChatGPT разработчик обвинил OpenAI в нарушении авторских прав

Проблема не нова, но масштаб — новый

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

Исследовательница изучила 900 open source ИИ-проектов. Вот какие выводы она сделалаtproger.ru

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

Зачем нужны синьоры

В свою очередь старшие разработчики не просто пишут код. Они:

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

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

Как избежать надвигающейся проблемы

Автор оригинальной статьи подытожил, что если бизнес хочет не просто «работающий» продукт, а поддерживаемый, нужно:

  • Документировать не только что, но и зачем.
  • Проводить ревью с упором на идейную целостность.
  • Передавать знания через наставничество.
  • Не допускать, чтобы ИИ заменял мышление.

Верим в позицию Экрема?Да, в его словах явно есть смыслНет, копиум какой-то

Похожие статьи