Программирование как разработка теорий: почему senior-разработчики стали ценны как никогда?
- вторник, 8 июля 2025 г. в 00:00:08
В 1985 году учёный Петер Наур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Наура: «программа — это не её исходный код».
Наур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться. Исходный код же является лишь письменным представлением этой теории, и, подобно любому другому представлению, не может передать её полноценно. Важнейшая информация о замысле, дизайне, компромиссах и рассуждениях, лежащих в основе тех или иных архитектурных решений, существует лишь в умах создателей системы.
Когда такие люди уходят, вся эта теория утрачивается. Код остаётся, но программа — живая, дышащая система со всеми её предпосылками и контекстом — исчезает.
Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ. В чём конкретно это выражается?
В бездумном использовании ИИ, которое уже стало нормой. Разработчики инстинктивно обращаются к генерируемым LLM решениям, не прилагая никаких когнитивных усилий, без которых получить должное понимание невозможно. Как я уже писал, это «бездумное использование ИИ» лишает нас возможности роста — тех ситуаций, когда ты оказался в тупике, взглянул на ситуацию со стороны, поборолся с задачей и, наконец, достиг этого заветного момента «Ага!», став более опытным инженером.
В генерации беспредметного кода. Здесь всё ещё печальней. Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания области задачи, концептуальной модели системы или тонких компромиссов, которые эксперты заложили в её архитектуру. Этот код может пройти тесты, но существует он в теоретическом и предметном вакууме. Не имея возможности найти крайнего с помощью git blame
, мы оказываемся сильно стеснены в своём стремлении понять «как?» работает тот или иной код, а самое главное «зачем?» он был написан.
В проблемах интеграции. Когда разработчики принимают сгенерированный ИИ код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения. В лучшем случае такой код будет: 1) работать и 2) не делать ничего опасного. Заложенные в нём решения могут противоречить модели предметной области, нарушать устоявшиеся паттерны или вносить едва уловимые несоответствия, которые обнаружатся, только когда система окажется под нагрузкой.
И что в результате? А в результате мы получаем кодовые базы, которые поначалу вроде работают, но по мере роста становятся всё менее согласованными. Системы, в которых код перестаёт отражать язык предметной области. Технический долг, который только накапливается, так как никто не понимает теоретических основ, когда-то придававших системе её целостность.
Хотя этот кризис далеко не новость. Помню того несчастного стажёра в предыдущей компании, где я работал, который авторизовался в продакшене и выполнил rm -rf /
, так как на StackOverflow ему сказали, что это решит его проблемы с symlink
.
Но сейчас мы наблюдаем всё это уже в других масштабах! Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта. (Если сюда прибавить ещё и рисковых вайб-кодеров, то эти числа станут куда более пугающими). А теперь вооружите этих неопытных программистов ИИ-инструментами, которые мгновенно генерируют целые функции, и вы получите катастрофу: невиданное число джуниоров, вооружённых мощнейшими инструментами копи-паста и минимальным пониманием процесса.
Упомянутому выше стажёру хотя бы нужно было найти, прочесть и вручную ввести свою деструктивную команду. А сегодняшние разработчики получают генерируемые ИИ функции по нажатию клавиши, импортируют важные решения, которые не проверяют (не говоря уже об откровенно опасном коде).
И всё это подводит нас к рассуждению о том, почему бывалые инженеры стали крайне важны для индустрии. Эти люди:
Разрабатывают теорию предметной области. Старшие разработчики не просто пишут код — они выстраивают и поддерживают теоретическую схему, которая соединяет бизнес-области с программной архитектурой. Они понимают не только то, что делает код, но и почему он существует, как моделирует бизнес-область и как должен развиваться с углублением понимания процесса. Это те люди, которые обеспечивают, чтобы код говорил на языке экспертов предметной области.
Следят за соблюдением заложенной в архитектуру теории. Когда джуниор или LLM создают код, старший разработчик выступает проводником между его сырой реализацией и согласованным дизайном системы. Он способен оценить, соответствует ли написанный код теоретическим основам архитектуры — причём не только технически, но и концептуально. Эти люди понимают разницу между кодом, который работает, и кодом, который подходит к общей структуре.
Сознательно используют ИИ. Старшие разработчики используют ИИ сознательно, а не рефлекторно. Они понимают всё, что в итоге интегрируют, ставят под сомнение предложения моделей и следят, чтобы сгенерированный код поддерживал теоретическую согласованность системы, а не подрывал её. Если они используют ИИ, то обычно для каких-то шаблонных задач, оставляя на самостоятельное решение те части, которые требуют здравого человеческого суждения. (Если вы застряли в ситуации, где вам нужно, скажем, написать двадцать с лишним фабричных методов, делающих одно и то же, но для разных сервисов или свойств, то это можно с чистой совестью поручить Claude Code или какой-то другой модели).
Учат теории и мастерству. Пожалуй, самая важная роль старших разработчиков в том, чтобы передавать теоретические знания и навыки другим. Они учат молодых специалистов не только использованию синтаксиса или паттернов, но и глубокому пониманию, которое позволяет превратить разрозненный код в согласованные программы. Эти люди обучают искусству решения задач, объясняют, в чём ценность когнитивных усилий, а также прививают дисциплину, чтобы реализации всегда предшествовал вдумчивый анализ и понимание.
Наур в своей работе также напоминает нам, что программирование по своей природе относится к интеллектуальной активности человека. Его реальным продуктом является не код, а теория, понимание и ментальная модель, которые придают системе согласованность. Да, LLM могут генерировать синтаксически корректный код, но они не могут создавать теории. Они не могут понять бизнес-контекст, осмыслить необходимые компромиссы или поддерживать концептуальную целостность, которая отделяет качественное ПО от просто рабочего кода.
Несмотря на то, что хорошая документация, запись архитектурных решений и чистый, разборчивый код всегда кстати, всё это лишь слова, которые не могут полноценно отразить то, чем наши программы являются, что делают и какой смысл несут.
Наибольшего успеха добьются те команды, которые осознают фундаментальную разницу. LLM могут быть полезны для конкретно механистических задач (генерации шаблонного кода, написания простых тестов, создания тех самых двадцати с лишним почти идентичных фабричных методов). Но сама суть программирования — выработка теории, которая преобразует бизнес-требования в согласованные программные модели — должна оставаться строго в руках человека.
Организации, ценящие качество своего ПО, должны вкладывать усилия в сохранение теоретической базы:
Создавать документацию, которая будет отражать сам смысл ПО, а не только его реализацию.
Вводить практики обмена знаниями, в ходе которых люди будут делиться ментальными моделями, а не просто знакомиться с голыми процессами.
Использовать код-ревью для оценки не только корректности программы, но и её соответствия теоретическим основам.
Развивать программы наставничества, чтобы вырабатывать у новичков навыки построения теорий.
Петер Наур ещё в 1985 году понял то, что мы заново открываем для себя сегодня. Речь о том, что программы — это созданные человеком конструкты, для развития которых необходимо их глубокое понимание. По мере вхождения в эпоху безудержной генерации кода всё большую ценность начинают обретать разработчики, которые умеют выстраивать, сохранять и передавать теории, придающие коду его осмысленную и целостную форму.
И это не про отказ от ИИ или отстаивание каких-то устаревших практик. Это про сохранение важнейших аспектов разработки, присущих именно человеку: понимания предметной области, архитектурной согласованности и тонкостей создания систем, которые не просто работают, но и имеют смысл. Это про сохранение способности эффективно бороться с задачами, вникать в них прежде, чем реализовывать, и обеспечивать, чтобы код отражал богатые ментальные модели, которые делают программные системы по-настоящему обслуживаемыми.
Вопрос не в том, могут ли LLM писать код — очевидно, могут. Вопрос в том, можем ли мы сохранить создаваемые людьми теоретические структуры, которые превращают этот код в согласованные, предметно-ориентированные, долговечные программы.
В эпоху стремления к бездумному использованию ИИ, старшие разработчики, которые применяют ИИ сознательно (если вообще это делают) с сохранением всех необходимых принципов программирования, становятся хранителями качественного ПО. Они единственные, кто обеспечивает, чтобы наши системы оставались понятными для людей, соответствовали своим предметным областям и строились на основе твёрдой теории.
Когда пыль, поднявшаяся в суетливой погоне за «халявным кодом», осядет, спрос на старших разработчиков снова возрастёт.