В 1985 году учёный Петер Наур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Наура: «программа — это не её исходный код».
Теория кода
Наур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться. Исходный код же является лишь письменным представлением этой теории, и, подобно любому другому представлению, не может передать её полноценно. Важнейшая информация о замысле, дизайне, компромиссах и рассуждениях, лежащих в основе тех или иных архитектурных решений, существует лишь в умах создателей системы.
Когда такие люди уходят, вся эта теория утрачивается. Код остаётся, но программа — живая, дышащая система со всеми её предпосылками и контекстом — исчезает.
Кризис из-за утраты теоретического фундамента
Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ. В чём конкретно это выражается?
В бездумном использовании ИИ, которое уже стало нормой. Разработчики инстинктивно обращаются к генерируемым LLM решениям, не прилагая никаких когнитивных усилий, без которых получить должное понимание невозможно. Как я уже писал, это «бездумное использование ИИ» лишает нас возможности роста — тех ситуаций, когда ты оказался в тупике, взглянул на ситуацию со стороны, поборолся с задачей и, наконец, достиг этого заветного момента «Ага!», став более опытным инженером.
В генерации беспредметного кода. Здесь всё ещё печальней. Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания области задачи, концептуальной модели системы или тонких компромиссов, которые эксперты заложили в её архитектуру. Этот код может пройти тесты, но существует он в теоретическом и предметном вакууме. Не имея возможности найти крайнего с помощью
git blame, мы оказываемся сильно стеснены в своём стремлении понять «как?» работает тот или иной код, а самое главное «зачем?» он был написан.В проблемах интеграции. Когда разработчики принимают сгенерированный ИИ код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения. В лучшем случае такой код будет: 1) работать и 2) не делать ничего опасного. Заложенные в нём решения могут противоречить модели предметной области, нарушать устоявшиеся паттерны или вносить едва уловимые несоответствия, которые обнаружатся, только когда система окажется под нагрузкой.
И что в результате? А в результате мы получаем кодовые базы, которые поначалу вроде работают, но по мере роста становятся всё менее согласованными. Системы, в которых код перестаёт отражать язык предметной области. Технический долг, который только накапливается, так как никто не понимает теоретических основ, когда-то придававших системе её целостность.
Хотя этот кризис далеко не новость. Помню того несчастного стажёра в предыдущей компании, где я работал, который авторизовался в продакшене и выполнил rm -rf /, так как на StackOverflow ему сказали, что это решит его проблемы с symlink.
Но сейчас мы наблюдаем всё это уже в других масштабах! Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта. (Если сюда прибавить ещё и рисковых вайб-кодеров, то эти числа станут куда более пугающими). А теперь вооружите этих неопытных программистов ИИ-инструментами, которые мгновенно генерируют целые функции, и вы получите катастрофу: невиданное число джуниоров, вооружённых мощнейшими инструментами копи-паста и минимальным пониманием процесса.
Упомянутому выше стажёру хотя бы нужно было найти, прочесть и вручную ввести свою деструктивную команду. А сегодняшние разработчики получают генерируемые ИИ функции по нажатию клавиши, импортируют важные решения, которые не проверяют (не говоря уже об откровенно опасном коде).
Почему опытные разработчики стали ценны как никогда
И всё это подводит нас к рассуждению о том, почему бывалые инженеры стали крайне важны для индустрии. Эти люди:
Разрабатывают теорию предметной области. Старшие разработчики не просто пишут код — они выстраивают и поддерживают теоретическую схему, которая соединяет бизнес-области с программной архитектурой. Они понимают не только то, что делает код, но и почему он существует, как моделирует бизнес-область и как должен развиваться с углублением понимания процесса. Это те люди, которые обеспечивают, чтобы код говорил на языке экспертов предметной области.
Следят за соблюдением заложенной в архитектуру теории. Когда джуниор или LLM создают код, старший разработчик выступает проводником между его сырой реализацией и согласованным дизайном системы. Он способен оценить, соответствует ли написанный код теоретическим основам архитектуры — причём не только технически, но и концептуально. Эти люди понимают разницу между кодом, который работает, и кодом, который подходит к общей структуре.
Сознательно используют ИИ. Старшие разработчики используют ИИ сознательно, а не рефлекторно. Они понимают всё, что в итоге интегрируют, ставят под сомнение предложения моделей и следят, чтобы сгенерированный код поддерживал теоретическую согласованность системы, а не подрывал её. Если они используют ИИ, то обычно для каких-то шаблонных задач, оставляя на самостоятельное решение те части, которые требуют здравого человеческого суждения. (Если вы застряли в ситуации, где вам нужно, скажем, написать двадцать с лишним фабричных методов, делающих одно и то же, но для разных сервисов или свойств, то это можно с чистой совестью поручить Claude Code или какой-то другой модели).
Учат теории и мастерству. Пожалуй, самая важная роль старших разработчиков в том, чтобы передавать теоретические знания и навыки другим. Они учат молодых специалистов не только использованию синтаксиса или паттернов, но и глубокому пониманию, которое позволяет превратить разрозненный код в согласованные программы. Эти люди обучают искусству решения задач, объясняют, в чём ценность когнитивных усилий, а также прививают дисциплину, чтобы реализации всегда предшествовал вдумчивый анализ и понимание.
Человек незаменим
Наур в своей работе также напоминает нам, что программирование по своей природе относится к интеллектуальной активности человека. Его реальным продуктом является не код, а теория, понимание и ментальная модель, которые придают системе согласованность. Да, LLM могут генерировать синтаксически корректный код, но они не могут создавать теории. Они не могут понять бизнес-контекст, осмыслить необходимые компромиссы или поддерживать концептуальную целостность, которая отделяет качественное ПО от просто рабочего кода.
Несмотря на то, что хорошая документация, запись архитектурных решений и чистый, разборчивый код всегда кстати, всё это лишь слова, которые не могут полноценно отразить то, чем наши программы являются, что делают и какой смысл несут.
Наибольшего успеха добьются те команды, которые осознают фундаментальную разницу. LLM могут быть полезны для конкретно механистических задач (генерации шаблонного кода, написания простых тестов, создания тех самых двадцати с лишним почти идентичных фабричных методов). Но сама суть программирования — выработка теории, которая преобразует бизнес-требования в согласованные программные модели — должна оставаться строго в руках человека.
Сохранение теории
Организации, ценящие качество своего ПО, должны вкладывать усилия в сохранение теоретической базы:
Создавать документацию, которая будет отражать сам смысл ПО, а не только его реализацию.
Вводить практики обмена знаниями, в ходе которых люди будут делиться ментальными моделями, а не просто знакомиться с голыми процессами.
Использовать код-ревью для оценки не только корректности программы, но и её соответствия теоретическим основам.
Развивать программы наставничества, чтобы вырабатывать у новичков навыки построения теорий.
Искусство создания теорий
Петер Наур ещё в 1985 году понял то, что мы заново открываем для себя сегодня. Речь о том, что программы — это созданные человеком конструкты, для развития которых необходимо их глубокое понимание. По мере вхождения в эпоху безудержной генерации кода всё большую ценность начинают обретать разработчики, которые умеют выстраивать, сохранять и передавать теории, придающие коду его осмысленную и целостную форму.
И это не про отказ от ИИ или отстаивание каких-то устаревших практик. Это про сохранение важнейших аспектов разработки, присущих именно человеку: понимания предметной области, архитектурной согласованности и тонкостей создания систем, которые не просто работают, но и имеют смысл. Это про сохранение способности эффективно бороться с задачами, вникать в них прежде, чем реализовывать, и обеспечивать, чтобы код отражал богатые ментальные модели, которые делают программные системы по-настоящему обслуживаемыми.
Вопрос не в том, могут ли LLM писать код — очевидно, могут. Вопрос в том, можем ли мы сохранить создаваемые людьми теоретические структуры, которые превращают этот код в согласованные, предметно-ориентированные, долговечные программы.
В эпоху стремления к бездумному использованию ИИ, старшие разработчики, которые применяют ИИ сознательно (если вообще это делают) с сохранением всех необходимых принципов программирования, становятся хранителями качественного ПО. Они единственные, кто обеспечивает, чтобы наши системы оставались понятными для людей, соответствовали своим предметным областям и строились на основе твёрдой теории.
Когда пыль, поднявшаяся в суетливой погоне за «халявным кодом», осядет, спрос на старших разработчиков снова возрастёт.
Комментарии (94)
samizdam
06.07.2025 09:55Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.
avost
06.07.2025 09:55Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы
А в каком месте печатный станок избавил от интеллектуальной работы? Избавил от тупой работы. Интеллектуальной даже прибавил (ответственности) - там, где при ручном переписывании ошибка оказывалась в одном экземпляре, при печати тиражировалась на сотни-тысячи-миллионы.
samizdam
06.07.2025 09:55А в каком месте печатный станок избавил от интеллектуальной работы?
При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.
Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.
Печатный станок дал возможность большему кол-ву мнений (и авторам-интеллектуалам) доходить до широкой аудитории (Реформация, просвещение, национальные революции и т.д.). И как любое массовое производство снизил стоимость и требуемую квалификацию. Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве, говорю как специалист издательского дела))
где при ручном переписывании ошибка оказывалась в одном экземпляре
Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)
avost
06.07.2025 09:55Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве
Да, только образован он получше среднего средневекового монаха-переписчика :)
Сейчас сеньорский скил кажется дешевеет стремительно.
Да, только это ведь не уровень интеллектуальности данной деятельности снижается, а общая планка повышается.
код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель
Если это одноразовый мусор, то да. В чуть более долгосрочной перспективе нагенерённый код, вероятно, и для пользователя окажется неприемлимым - найдутся и баги и дыры и нестабильности. Сейчас нет проблем без знаний как растирать минеральные пигменты для красок, сфоткать Лизу дель Джокондо и распечатать на струйном принтере. Займёт минуты. Через пару лет выцветет.
А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок
Ну, что касается этих сказаний, то там и ошибок и описок и отсебятины - море (это к вопросу о квалификации переписчиков) просто канонизирован только один вариант. Вот, вам и "отзыв тиража" - анафема на остальные варианты ;).
Fedorkov
06.07.2025 09:55Автор неявно исходит из того, что нас не ждут никакие новые революции в ИИ.
Я бы просто посоветовал пропустить нынешний раунд хайпа и продолжить следить за появлением новых технологий.
GarfieldX
06.07.2025 09:55Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют. По сути это новый уровень поиска с агрегацией, анализом и генерацией ответа.
Зато нас точно ждут проблемы из-за потери контроля над кодом. По сути в статье это и описано. Например, когда мой код косячит, то практически в 99% могу предсказать где этот косяк. Потому что код писал сам и знаю его структуру особенности, нюансы и вообще все о нем. А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Но с предложением следить дальше полностью согласен. Тем более что нам ничего другого не остаётся. Лишь выбор откуда смотреть. Изнутри или снаружи.
PerroSalchicha
06.07.2025 09:55Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют.
Занудства ради, БЯМ - это и есть именно то, что мы называем термином искусственный интеллект, в соответствии с распространёнными его определениями. Просто некоторые люди ошибочно считают, что называться термином "искусственный интеллект" имеет право лишь нечто, как минимум, эквивалентное по возможностям интеллекту человеческому, но только сделанное из деталек. Но это не так, требования к ИИ куда более простые, он должен лишь имитировать некоторые аспекты интеллектуальной деятельности, с чем БЯМ прекрасно справляются.
blind_oracle
06.07.2025 09:55Нет.
Интелле́кт (от лат. intellectus «восприятие»; «разуме́ние», «понимание»; «понятие», «рассу́док»[1]) или ум[2][3] — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой
(Ц) википедия
Почти ничем из этого LLM не обладают.
PerroSalchicha
06.07.2025 09:55Да. Искусственный интеллект != интеллект.
Искусственный интеллект - комплекс технологических решений, позволяющий имитировать когнитивные функции человека (включая самообучение и поиск решений без заранее заданного алгоритма) и получать при выполнении конкретных задач результаты, сопоставимые, как минимум, с результатами интеллектуальной деятельности
Всем этим LLM обладают
samizdam
06.07.2025 09:55Вёл недавно разговор с "умной" колонкой и не смог получить ответ, как вяжется отсутствие психики у ИИ, с тем что интеллект её функция по определению)
Areso
06.07.2025 09:55А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
Что с БЯМ, что без БЯМ, бОльшая часть кода была написано до человека, и да, надо как-то прочесть и понять, что за код, что он делает, и где бага. Писать код, в общем случае, давно не является сложной задачей.
Zerik
06.07.2025 09:55>А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.
На самом деле нет. Тот же claude через cursor при достаточно чёткой постановке задачи может указать места потенциально приходящие к той или иной проблеме.
Да и про понимание кода сгенеренного через LLM-тут ведь тоже зависит от того как именно пользоваться, и насколько подробно задачу ставить. Если просто впизтвать в ту или иную агенту систему текст таски и ждать что оно само как нибудь там накодит-да, будут проблемы. Если же рассказать модели что именно она должна сделать-всё намного более предсказуемо и читабелбно получается.
dersoverflow
06.07.2025 09:55Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система...
Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания...
Гмм... А ведь мы это видели!
На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, продуктивнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать... https://ders.by/pp/ps/index.html
Да, речь снова про Камень! Без понимания и люди и машины обречены вести себя как дураки:
Все мы разделены Природой на два подмножества: понимальщики и запоминальщики.
Ни понимальщики, ни запоминальщики даже не догадываются о существовании друг друга!
sinerslb
06.07.2025 09:55Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ
Это если целью является создание кода, подкреплëнного теоретическими основами, но ведь нет. Вокруг капитализм, и в 95+ процентах случаях целью является прибыль, и пока прибыль есть, заказчику пофиг, какой-там код. Катастрофой будет отсутствие прибыли, вот тогда забеспокоятся, и начнут искать новые подходы.
arturdumchev
06.07.2025 09:55Но если кодовую базу совсем запустить, то со временем начнут стрелять проблемы. Time to market (TTM) бизнесу всегда важен, а с плохой кодовой базой TTM будет проседать. Исправление проблем в одних местах будет создавать проблемы в других. Там, где хватило бы двух разработчиков, придется держать команду в 20.
DMGarikk
06.07.2025 09:55ну кстати это одна из причин почему часто корпорации переписывают некоторые продукты с нуля - так дешевле обеспечить ТТМ по фичам и не закапываться в рефакторинг того г-на который накропали в прошлой итерации
==
ну не забывать надо то что писать качественный код сразу - это снижать ТТМ при первом выходе на рынок, когда конкурент на коленке собрал чтото и оно работает..а у вас еще архнадзор деплой не пропускает
VladimirFarshatov
06.07.2025 09:55
Никогда такого не было, и вот опять снова.. на память Стругацкие "Понедельник начинается в субботу":
-"Нам нужен программист". Внезапно сказал тот, что сидел справа.
-"Программисты сейчас всем нужны". Ответил я.
-"Вы не поняли. Нам нужен отличный программист". Поддержал разговор сзади.
-"Ну .. это вообще дефицит". Парировал я.:)
LinkToOS
06.07.2025 09:55Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта? Те же LLM-GPT - это больше предмет для скандалов и споров, чем требование современности. Даже эта статья, опять о проблемах использования ИИ в программировании.
Не пришло ли время здорового soft-консерватизма? Законсервируем новые разработки, и перепишем винду на ассемблере. Вообще все на ассемблере перепишем.
sic
06.07.2025 09:55Ну а как "прекратить писать новый софт"? Сказать конкурентам - не пишите похожее, я сам допишу и будет все классно?
Проблема не в коде, проблема в капитализме. Это нормально, когда все-что-угодно "а за деньги да", и что при этом создается тонна хлама, часть из которого чуть более, чем полностью вредна, и еще бесконечная масса однотипных и околоодноразовых поделий. То есть именно это и есть основная масса продуктов.
Мне нередко снится один и тот же сон. Что мол прилетают пришельцы на планету Земля, и думают, чтобы такого тут сделать, чтобы люди никогда не стали им потенциально опасны. И дарят им идею Интернет. Вообще, чем он хорош, думаю понятно, но чем он плох тоже предельно очевидно, и вот интересно, как пошли дела у нашей планеты, в мультивселенной, где Интернет почему-то не эволюционировал/не прижился.
vkni
06.07.2025 09:55И дарят им идею Интернет.
+
Проблема не в коде, проблема в капитализме.
Ну действительно же — Интернет и программирование — это же просто технологии следующего строя. Поэтому текущий их не может использовать нормально, и просто гадит.
Если вы посмотрите локусы следующего строя — OSS, то там вполне хорошо и с программированием, и с Интернетом. Когда люди делают для себя, появляются прекрасные TUI интерфейсы, замечательные сайты с минимумом спама.
Кстати, туда же, в технологии следующего строя, относятся всеобщее образование, всеобщее здравоохранение. Просто мы сейчас живём в эпоху Реставрации.
VladimirFarshatov
06.07.2025 09:55Вы упустили одну базовую лемму программирования: Главный недостаток любого кода - то что он написан не тобою. Следствие в бизнесе: главный недостаток любой программы - она не твоя, а конкурента.
LeVoN_CCCP
06.07.2025 09:55Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта?
Надо было сразу с козырей заходить - зачем нам столько дистрибутивов Linux?
Kanut
06.07.2025 09:55Мы же не умерли год-два назад, с тем набором софта который мы тогда имели.
"Мы" и двести лет назад не умерли с тем набором технологий, который имели. И 2000 лет назад не умерли. Ну как вид. Так что теперь НТП не нужен?
И кстати точно так же "год-два" назад люди вполне себе умирали потому что современные технологии не позволяли их спасти. А завтра кто-то напишет код, который мог бы кого-то из них спасти.
max-daniels
06.07.2025 09:55Это где-то в мире розовых пони. Сейчас после 35 не берут на работу, всем подавай молодых рабов, авось разберутся вместе с нейросетями.
blind_oracle
06.07.2025 09:55У меня куча коллег-погромистов старше 45-50, со всякими PhD и подобным. Да и я уже не молод :)
Так что нет, не везде так.
anaxita
06.07.2025 09:55А у нас много таких на хабре, которые с пеной у рта говорят, что 200к потолок))
Ermit
06.07.2025 09:55Тут очень многое от контекста зависит, где, куда, кем, итд. Но конкуренция на рынке труда серьезная, в связи с LLM. И тут еще неизвестно, кому проще, кому после 35 или кому до, поскольку они легче заменяются ИИ.
OlegZH
06.07.2025 09:55Почитаешь, сразу захочется в сеньоры. Жалко, что никто не возьмёт. Надо медленно пройти все уровни. А... так.. теория... Что может быть интереснее построения теории кода?
PerroSalchicha
06.07.2025 09:55Что может быть интереснее построения теории кода?
Быть начальником чуваков, которые занимаются построениями теории кода.
pnmv
06.07.2025 09:55разработчики, высшей квалификации, ну или хотя-бы "выше средней" (middle+), возможно, ещё и нужны, но далеко не все, а только те, кто умеет проходить hr-фильтры.
если человек с опытом не умеет проходить фильтры (ну или случайно не смог, что равносильно отсутствию навыка), а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr.
PerroSalchicha
06.07.2025 09:55а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr
Эйчары людей на работу не берут. Эйчары, это просто первичный фильтр, понравиться которому, конечно, полезно просто для того, чтобы не улететь в корзину на самом первом этапе. Но вот поспособствовать трудоустройству эйчар не в состоянии.
pnmv
06.07.2025 09:55Вы правы. Именно эйчары и не берут. Не раз, слышал от руководителей про "заблокированных эйчарами" кандидатов.
Как им это удается, чисто технически, я не знаю, но если "отдел кадров против", работать в этой организации вы не будете.
anarchomeritocrat
06.07.2025 09:55Промпт в ChatGPT:
"прочитай статью по ссылкеhttps://habr.com/ru/companies/ruvds/articles/924616/и предложи свой комментарий"Ответ:
Мои мысли1. Полностью согласен с подходомВы, как крипто‑энтузиаст и поклонник минималистичных архитектур, точно подметили бы: без чётких ментальных моделей быстро возникающие компоненты (особенно сгенерированный ИИ‑код) ведут кархитектурным пузырям— видно снаружи, но непонятно, как это устроено внутри.2. Уместное использование ИИИспользовать LLM можно, но только какассистента для шаблонов— бэкенд‑скелет, boilerplate, тесты. При этом senior должен:Разобраться в сгенерированном коде,Адаптировать его под свою доменную логику,Убедиться, что он сочетается с остальной системой.
Это прямо перекликается с вашими принципами: функциональный, ясный, минимальный код управляется человеком, а не ИИ.3. Практики для поддержки теорииАвтор предлагает:Документировать не реализацию, асмысл: зачем этот компонент, какие компромиссы были.Через code review обсуждать не просто «исправь стиль», а «как это отражает модель?».Наставничество — именно как вы делаете: делиться пониманием, не только синтаксисом.
Эти практики стоит применять регулярно — в виде архитектурных сессий, обсуждений trade‑off и прототипов — в командах, где есть пулы джуниоров.Правда там прослеживается влияние на контекст предыдущего общения со мной, но в целом суть такая - нейронка мнение автора одобряет ))
VladimirFarshatov
06.07.2025 09:55Перплексити:
Моё мнение: статья очень актуальна и глубока, она подчёркивает важность интеллектуальной составляющей в программировании, которая не сводится к механическому написанию кода. В эпоху массового внедрения ИИ и автоматизации именно опыт и понимание старших разработчиков обеспечивают сохранение качества и смысловой целостности ПО. Это важное напоминание индустрии о том, что технологии — лишь инструменты, а основа успешной разработки — человеческий интеллект и теория.
LinkToOS
06.07.2025 09:55Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта.
Прям "Закон Мура" какой-то.
Сразу можно проблему обозначить - количество разработчиков растет, а суммарный IQ остается постоянным.
apevzner
06.07.2025 09:55Несмотря на то, что хорошая документация, запись архитектурных решений и чистый, разборчивый код всегда кстати, всё это лишь слова, которые не могут полноценно отразить то, чем наши программы являются, что делают и какой смысл несут.
Я бы тут слегка поспорил. Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.
Да, текст ограничен и не тождественен заложенным в него мыслям. Но в этом есть и положительный момент: необходимость выразить неограниченный полёт своей фантазии сухим языком технического текста (или кода) дисциплинирует и ограняет мысли. Не можете оформить свою мысль кодом или объяснить, что ваш код делает, значит, сами до конца не понимаете, есть смысл остановиться и подумать, а не подгонять по месту напильником.
Areso
06.07.2025 09:55Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.
Зачем нужны учителя, преподаватели, если есть книги?
Wesha
06.07.2025 09:55Зачем нужны учителя, преподаватели, если есть книги?
Затем же, зачем нужны комментарии, если есть код.
Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».
vkni
06.07.2025 09:55Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».
То есть, комментарии частично описывают программу на языке, отличном от языка реализации (поэтому неизбежно со слегка другой стороны). Как статические типы. :-) Такое частичное дублирование. :-)
vyatsek
06.07.2025 09:55Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться
Зачастую, текущее поколение крудошлепов и рестоделов, поражденное успешным прохождением литкода, о модели и теории банально не задумывается, а пока эффективные менеджеры дойдут до старика брукса, которые выросли из этих же растоделов и крудошлепов сократят не одну сотню сеньеров.
И со своей стороны хочется доучить Си и С++ и уйти писать что-то системно продуманное, нежели, чем ломать голову об очередной модели в обычном продукте, где зачастую о дизайне никто не заморачивается.
Когда проект загнивает, то тушат джунами и/или деньгами, перематывая изолентой хибернейт, спринг веб, JPA и прочие аббревиатуры.Безусловно есть оч. крутые спецы с богатым опытом, обширными знаниями и умением создавать продукты как с бизнесовой стороны, так и с технической, но на фоне общей массы они незаметны.
P.S. я не против фреймворков и тулов - это прекрасные инструменты в своих нишах, но если кругозор ограничен исключительно фреймворками, то точного технического решения не получить, т.к. где-то да и придется сделать свой велосипед.
Также я считаю полезным решать литкод, но это всего лишь небольшая часть из разработки.
RedHead
06.07.2025 09:55Современный мир разработки всё ближе к серьёзной катастрофе. В чём конкретно это выражается?
В бездумном использовании джунов, которое уже стало нормой. Разработчики инстинктивно обращаются к написанным студентами-джунами решениям, не прилагая никаких когнитивных усилий, без которых получить должное понимание невозможно. Как я уже писал, это «бездумное использование джунов» лишает нас возможности роста.
В генерации беспредметного кода. Здесь всё ещё печальней. Создаваемые джунами программы не просто лишены фундаментальной теории, но и вовсе являются безличными.
В проблемах интеграции. Когда разработчики принимают написанный джунами код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения.
zooh
06.07.2025 09:55Если подумать, ИИ мало что изменил в процессе. До него был класс работников, занимавшихся копипастом со stackoverflow, теперь эта работа автоматизирована. Риски подхода сохранились и масштабировались вместе с самим подходом. Раньше бизнес игрался с заменой дорогих сеньоров на дешевых джунов из развивающихся стран и терял контроль над кодом; теперь потерять контроль над кодом можно еще быстрее и дешевле.
С другой стороны, статья похожа на взаимное самоуспокоение сеньорствующих, которые несколько напуганы движухой. Если предыдущие серебряные пули в виде RAD, микросервисов, Scrum еще можно было принимать, закатив глаза, и ждать, пока труп очередной метододогии проплывет мимо, то в этот раз "оппонент" определенно силен.
VladimirFarshatov
06.07.2025 09:55Всегда говорил, с 80-х, что программисты пишущие ИИ пилят сук, на котором сидят сами. Не помогало ещё ни разу.. )
Zalechi
06.07.2025 09:55Ну вот автор затронул очень важную деталь, но никто не собирается ее обсуждать, точнее предлагает системный выход.
Жесткая регламентация на базе Институтов Стандартизации. Уровни, протоколы.
Victorbkl
06.07.2025 09:55В тему промт для veo3: Возможно что скорость развития моделей будет нарастать быстрее (или просто будет быстрее), чем рост проблемы, и мы можем не дождаться когда синьоры будут выпущены и очищены от пыли, из старого шкафа, захламленного подвала, заброшенного здания. Уверен синьоры серьёзные люди и сами выйдут на свет новых обстоятельств, накинув лассо на дикого робомустанга пролетающего по новому хайвею рядом с этим зданием.
Anton_Timofeev
Программирование - это инженерная дисциплина. Единственное отличие, что инженеров-механиков в полёте фантазии ограничивает суровая реальность, т.к. нельзя протянуть сто рычагов через весь самолёт, а у программистов таких отрезвляющих рамок реальности нет - код всё стерпит.
Farongy
Нет, не стерпит.
Anton_Timofeev
Читатель кода через некоторое время не стерпит, а коду всё равно
Rive
Процессор тоже читает код в некотором смысле.
vkni
Только он читает перевод перевода.
apcs660
бывает кодирование модели чипа, писать ядра на VHDL, Verilog - чип не стерпит и оптимизация на 10 процентов очень заметна, в том числе денежно.
AlexanderS
VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.
apcs660
Да, это сравнение на другой стороне глобуса, просто железо ошибок не прощает - как правило, либо работает код модели, либо нет. И не факт что в реальном чипе будет работать после фпга, и как вы заметили, запустится на фпга не любой код который формально работает в симуляторе.
Но в enterprise программировании иногда не понимают что к примеру, на java изображения лучше не обрабатывать, для этого есть более эффективные языки или библиотеки - но нет, прут напролом и в итоге ставят 500 нодов вместо 100 в кластере и при этом с библиотекой на java, которую пересли с библиотеки на С! Потому что родная жрала памяти раз в 10 больше и медленнее раз в 5 чем клон сишной на жабе... На средних картинках. Вот тебе и эффективность.
Несколько лет клиент жжет электричество используя заведомо неэффективное решение.
В java даже определить хватит тебе памяти или нет чтобы развернуть изображение, нет нормальных способов. Вернее можно но очень ненадежно, с большим запасом. Ловят оом периодичеси., он кладет веб сервер...
Почему вспомнил - попал на поддержку такого чуда. Там бы архитектуру поменять а не заплатки лепить...
Код все стерпит, это точно, в enterprise так точно
Kergan88
Разница между программистами и другими инженерами принципиальная - программисты пишут тексты для людей
Anton_Timofeev
Исходный код - это конструкторская документация.
Сборка исполняемого файла - это изготовление на заводе.
Исполнение программы - это работа устройства.
Так что принципиальной разницы не вижу. КД тоже люди читают и правят при необходимости.
victor_1212
не совсем, КД - описание алгоритма, программирование, отладка, сборка и пр. - скорее этапы исготовления, по опыту так было, хотя возможно есть новые госты, стоило бы проверить
Anton_Timofeev
Отладка - это скорее что-то типа опытного производства, когда по предварительной КД изготавливают опытные экземпляры, тестируют, вносят изменения в КД, и так по кругу, пока не получится что-то жизнеспособное.
victor_1212
отладка разная бывает, и дело не в том на что именно похоже, а как определен рабочий цикл - ТЗ, ЭП, ТП, КД, изготовление, по старому программирование и тд. это изготовление, этап КД это алгоритмы, которые тоже конечно не на пустом месте делаются
Anton_Timofeev
Если бы программирование было частью изготовления - разве его не надо было бы повторять для каждой сборки?
victor_1212
не совсем понимаю Вас, изготовление это процесс, но специфика sw в том, что делается один раз, типа sw сертификацию прошло - изготовление закончено, версия кода заморожена, без разницы сколько надо будет копий, и как именно они делаются, полной компиляцией, сборкой - линкованием, или нет без разницы, конечно по ТЗ могут быть дополнительные требования управления конфигурацией например скриптами и т.п., но это не изготовление, также могут быть особые требования по сопровождению, по памяти примерно так, новые госты могут отличаться
Anton_Timofeev
Я в контексте физического производства размышляю, где изготовление - это изготовление каждой отдельной копии исполняемого файла, и оно может вестись методом сборки из исходников, либо простым копированием уже готовых бинарей.
А программирование - это процесс разработки того, из чего впоследствие исполняемые файлы будут изготавливаться. Типа как создание 3д моделей/чертежей деталей.
В этом смысле чертежи тоже один раз сертификацию проходят, так же как и код.
victor_1212
размышлять можно конечно, но по практическому опыту это не совсем так, как Вы думаете
Anton_Timofeev
А какое самое вопиющее отличие на Ваш взгляд? А то я в упор не вижу. "Си**ка - си**ка, фрукт - фрукт")
victor_1212
про "вопиющие" мне судить трудно, но если хотите напишите в личку пару слов про Ваш опыт, станет более понятно, и постараюсь объяснить по мере сил
test4354545
Если исходный код это КД, то что такое тогда документация к коду?
Areso
Можно предположить, что и то, и другое - КД. Просто разные "слои" или "уровни".
test4354545
А давайте нельзя предположить и будем называть вещи своими именами. Код это код, а документация это то что описывает то как этот код работает. Потому что иначе у вас вообще все на свете это слои или уровни документации.
Areso
А вы просто не подшивали исходные коды в папочки, а я подшивал. Каждая версия - распечатывалась, подшивалась, сдавалась в архив архивариусу под акт.
А вот бинарь - нет.
Что как бы намекает, что таки да, исходный код - это тоже часть документации.
test4354545
Да, оч крутой аргумент. Я могу и бинарь распечатать и подшить в папочке. Таким образом ВСЕ - документация. Поэтому этот термин бессмысленен если использовать его так как используете вы.
Areso
Ну, хорошо, вы ВКР делали? Вы в приложениях прикладывали HEX'ы бинаря или исходников?
ГОСТ 19.401-78. Единая система программной документации. Текст программы. Требования к содержанию и оформлению. Статус: действует.
test4354545
Аргументум от ГОСТум. Я вас понял. У нас кстати документация проекта не по госту, и без подшитых папочек. Получается это и не документация вовсе?
PerroSalchicha
Код в классическом понимании, это такая же документация. У конструктора есть техническое задание, которое объясняет, как должна работать его, кхм, разработка. Есть спецификации разных уровней, которые это уточняют уже более детально. И есть чертежи/схемы, которые уже описывают непосредственно всю разработку. Так же и с кодом. Есть техническое задание, есть спецификации на API, структуры данных, какие-то алгоритмы. А есть собственно код, который подробно описывает всё, что должна делать программа. Это тоже конструкторская документация, всё верно.
VladimirFarshatov
Точно. Люди читают код и исполняют его, а комтьютер - это такая коробчка, где они живут месяцами и бессменно лопатят код.. )
ogost
Код-то может и стерпит. А клиенты могут и не стерпеть.
Утеря средств клиентов крипто-биржей из-за кривого кода. Упавший интернет-банк из-за кривых ручонок погромистов с тестерами и, как следствие, финансовые и репутационные убытки у достаточно крупного и зрелого банка. И это наблюдения только из моей практики. Есть и достаточно известные случаи. Например достаточно известен случай про облучение пациентов смертельной дозой медицинским аппаратом из-за кривого кода. Проблемы с MCAS у боинга связаны (в том числе) и с кривым кодом. У Тоёоты были отзывы из-за кривого софта в ABS и, емнип, с цифровой педалью газа, приводившей к неконтролируемому ускорению автомобиля.
wl2776
... торговый робот, который за 45 минут спустил в трубу почти полмиллиарда
И еще один
DMGarikk
если я не ошибаюсь, проблемы там с архитектурой и концептом самой подсистемы, а не конечным программным кодом
ogost
Насколько я понимаю, там целая цепочка проблем. В боинге захотели новые движки, которые были по размеру больше, чем заложенные в проекте. Пришлось их повесить чуть-чуть вперёд и ниже, алтернатива - всё переделывать. Решили таки не переделывать. Что сместило центр тяги и задирало нос самолёта (кривая архитектура). Как костыль приделали (перепрошили?) MCAS, который опускал нос самолёта ниже, основываясь на датчиках. Боинг, посчитав, что в случае проблем с MCAS пилоты разпознают ситуацию как "runaway stabilizer" и отключат автотримминг (или как он там правильно называеся), который в свою очередь отключает MCAS, решило не оповещать об этом авиалинии для включения в тренировки пилотов. Потому что дополнительные тренировки - дополнительные деньги.
Так вот, MCAS тоже не был должным образом протестирован, и заваливал нос самолёта тогда, когда этого не надо было делать. А пилоты тех злополучных рейсов не распознали ситуацию как "runaway stabilizer" и... в общем дальше вы знаете. Тогда как пилоты как минимум одного другого рейса смогли правильно распознать ситуацию и отключить MCAS.
Вследствие всего этого в интернете одни винят "эффективных" менеджеров боинга за неправильные решения, другие инженеров-проектировщиков за кривую архитектуру, третьи недостаточную квалификацию пилотов.
DMGarikk
ну собственно основная причина именно в архитектуре всего решения в комплексе
то что было принято решение "пусть пилоты не делают так что будет плохо" вместо того чтобы сделать всё полностью автоматически, причем еще умудрились повесить сюда маркетинговую фишку - продавая индикацию работы системы за отдельное бабло...чтобы пилоты еще и в угадайку поиграли - чёващепроисходит.
по этому я бы инженеров как таковых бы тут не особо и обвинял бы
Fintank-ru
Уволен нахер. Бугага. Стерпит у него.
test4354545
Исходя из вашего понимания термина, назовите пару не инженерных дисциплин
Kanut
А чем вас определение с википедии не устраивает: https://ru.wikipedia.org/wiki/Инженерное_дело ?
test4354545
исходя из него я могу программировать не "на пользу человека". И получается я не инженер.
Мне просто нужен ответ на вопрос "что не является инженерной дисциплиной по мнению автора ориг. коммента?", пусть приведет пару примеров и я притяну их к инженерии так же как он пртягивает к ней все подряд включая программирование. Потому что то чем он занимается это софистика.
Kanut
Получается. Вообще-то никто нигде и не утверждает что любое программирование это инженерное дело. Что в общем-то относится к любым "разновидностям" инженерного дела. Если кто-то что-то паяет, то он тоже совсем не обязательно инженер-электротехник :)
Ну а вы вместо того чтобы демагогию разводить можете просто посмотреть перечисленные там отрасли. А точнее: https://ru.wikipedia.org/wiki/Программная_инженерия
Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято. Причём уже давно. Не особо понимаю что вас в этом не устраивает.
test4354545
Какйо смысл тогда в утверждении "инженер программист" это инженер?
Kanut
Не особо понимаю причём здесь это и откуда вы вообще взяли это "утверждение".
test4354545
Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято
"software engineering это инжинерное дело" - тавтология
Kanut
Ну так это у вас проблема с тем чтобы относить программирование/software engineering к инженерному делу. Не у меня.
test4354545
Вы что то запутались в двух соснах. Так ВСЁ программирование это инженерное дело или только software engineering ?
Kanut
Во первых я же уже выше написал:
Кроме того если кто-то где-то скажет что условная механика это инженерная профессия, то по вашему это будет означать что все кто занимаются механикой автоматически инженеры?
test4354545
Да, это называется логика.
Kanut
То есть если ребёнок в школе занимается механикой, то он сразу инженер?
Мне теперь очень интересно стало увидеть ваше определение инженерного дела :)