В 1985 году учёный Петер Наур будто зрил в будущее, написав свою работу под названием «Programming as Theory Building», которая сегодня стала весьма актуальной. Мы всё чаще видим, как начинающие разработчики бездумно принимают сгенерированный ИИ код, который толком не понимают, а кодовые базы разрастаются лишёнными теоретических основ реализациями. В свете всего этого чётко вырисовывается основная идея Наура: «программа — это не её исходный код».

Теория кода

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

Когда такие люди уходят, вся эта теория утрачивается. Код остаётся, но программа — живая, дышащая система со всеми её предпосылками и контекстом — исчезает.

Кризис из-за утраты теоретического фундамента

Современный мир разработки всё ближе к серьёзной катастрофе, и вина тому — создание кода, лишённого теоретических основ. В чём конкретно это выражается?

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

  • В генерации беспредметного кода. Здесь всё ещё печальней. Генерируемые моделями программы не просто лишены фундаментальной теории, но и вовсе являются безличными. Такой код строится на основе статистических паттернов без понимания области задачи, концептуальной модели системы или тонких компромиссов, которые эксперты заложили в её архитектуру. Этот код может пройти тесты, но существует он в теоретическом и предметном вакууме. Не имея возможности найти крайнего с помощью git blame, мы оказываемся сильно стеснены в своём стремлении понять «как?» работает тот или иной код, а самое главное «зачем?» он был написан.

  • В проблемах интеграции. Когда разработчики принимают сгенерированный ИИ код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения. В лучшем случае такой код будет: 1) работать и 2) не делать ничего опасного. Заложенные в нём решения могут противоречить модели предметной области, нарушать устоявшиеся паттерны или вносить едва уловимые несоответствия, которые обнаружатся, только когда система окажется под нагрузкой.

И что в результате? А в результате мы получаем кодовые базы, которые поначалу вроде работают, но по мере роста становятся всё менее согласованными. Системы, в которых код перестаёт отражать язык предметной области. Технический долг, который только накапливается, так как никто не понимает теоретических основ, когда-то придававших системе её целостность.

Хотя этот кризис далеко не новость. Помню того несчастного стажёра в предыдущей компании, где я работал, который авторизовался в продакшене и выполнил rm -rf /, так как на StackOverflow ему сказали, что это решит его проблемы с symlink.

Но сейчас мы наблюдаем всё это уже в других масштабах! Примерно каждые пять лет численность разработчиков удваивается. То есть в любой момент времени половина всех инженеров имеет меньше пяти лет опыта. (Если сюда прибавить ещё и рисковых вайб-кодеров, то эти числа станут куда более пугающими). А теперь вооружите этих неопытных программистов ИИ-инструментами, которые мгновенно генерируют целые функции, и вы получите катастрофу: невиданное число джуниоров, вооружённых мощнейшими инструментами копи-паста и минимальным пониманием процесса.

Упомянутому выше стажёру хотя бы нужно было найти, прочесть и вручную ввести свою деструктивную команду. А сегодняшние разработчики получают генерируемые ИИ функции по нажатию клавиши, импортируют важные решения, которые не проверяют (не говоря уже об откровенно опасном коде).

Почему опытные разработчики стали ценны как никогда

И всё это подводит нас к рассуждению о том, почему бывалые инженеры стали крайне важны для индустрии. Эти люди:

  • Разрабатывают теорию предметной области. Старшие разработчики не просто пишут код — они выстраивают и поддерживают теоретическую схему, которая соединяет бизнес-области с программной архитектурой. Они понимают не только то, что делает код, но и почему он существует, как моделирует бизнес-область и как должен развиваться с углублением понимания процесса. Это те люди, которые обеспечивают, чтобы код говорил на языке экспертов предметной области.

  • Следят за соблюдением заложенной в архитектуру теории. Когда джуниор или LLM создают код, старший разработчик выступает проводником между его сырой реализацией и согласованным дизайном системы. Он способен оценить, соответствует ли написанный код теоретическим основам архитектуры — причём не только технически, но и концептуально. Эти люди понимают разницу между кодом, который работает, и кодом, который подходит к общей структуре.

  • Сознательно используют ИИ. Старшие разработчики используют ИИ сознательно, а не рефлекторно. Они понимают всё, что в итоге интегрируют, ставят под сомнение предложения моделей и следят, чтобы сгенерированный код поддерживал теоретическую согласованность системы, а не подрывал её. Если они используют ИИ, то обычно для каких-то шаблонных задач, оставляя на самостоятельное решение те части, которые требуют здравого человеческого суждения. (Если вы застряли в ситуации, где вам нужно, скажем, написать двадцать с лишним фабричных методов, делающих одно и то же, но для разных сервисов или свойств, то это можно с чистой совестью поручить Claude Code или какой-то другой модели).

  • Учат теории и мастерству. Пожалуй, самая важная роль старших разработчиков в том, чтобы передавать теоретические знания и навыки другим. Они учат молодых специалистов не только использованию синтаксиса или паттернов, но и глубокому пониманию, которое позволяет превратить разрозненный код в согласованные программы. Эти люди обучают искусству решения задач, объясняют, в чём ценность когнитивных усилий, а также прививают дисциплину, чтобы реализации всегда предшествовал вдумчивый анализ и понимание.

Человек незаменим

Наур в своей работе также напоминает нам, что программирование по своей природе относится к интеллектуальной активности человека. Его реальным продуктом является не код, а теория, понимание и ментальная модель, которые придают системе согласованность. Да, LLM могут генерировать синтаксически корректный код, но они не могут создавать теории. Они не могут понять бизнес-контекст, осмыслить необходимые компромиссы или поддерживать концептуальную целостность, которая отделяет качественное ПО от просто рабочего кода.

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

Наибольшего успеха добьются те команды, которые осознают фундаментальную разницу. LLM могут быть полезны для конкретно механистических задач (генерации шаблонного кода, написания простых тестов, создания тех самых двадцати с лишним почти идентичных фабричных методов). Но сама суть программирования — выработка теории, которая преобразует бизнес-требования в согласованные программные модели — должна оставаться строго в руках человека.

Сохранение теории

Организации, ценящие качество своего ПО, должны вкладывать усилия в сохранение теоретической базы:

  • Создавать документацию, которая будет отражать сам смысл ПО, а не только его реализацию.

  • Вводить практики обмена знаниями, в ходе которых люди будут делиться ментальными моделями, а не просто знакомиться с голыми процессами.

  • Использовать код-ревью для оценки не только корректности программы, но и её соответствия теоретическим основам.

  • Развивать программы наставничества, чтобы вырабатывать у новичков навыки построения теорий.

Искусство создания теорий

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

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

Вопрос не в том, могут ли LLM писать код — очевидно, могут. Вопрос в том, можем ли мы сохранить создаваемые людьми теоретические структуры, которые превращают этот код в согласованные, предметно-ориентированные, долговечные программы.

В эпоху стремления к бездумному использованию ИИ, старшие разработчики, которые применяют ИИ сознательно (если вообще это делают) с сохранением всех необходимых принципов программирования, становятся хранителями качественного ПО. Они единственные, кто обеспечивает, чтобы наши системы оставались понятными для людей, соответствовали своим предметным областям и строились на основе твёрдой теории.

Когда пыль, поднявшаяся в суетливой погоне за «халявным кодом», осядет, спрос на старших разработчиков снова возрастёт.

Комментарии (94)


  1. Anton_Timofeev
    06.07.2025 09:55

    Программирование - это инженерная дисциплина. Единственное отличие, что инженеров-механиков в полёте фантазии ограничивает суровая реальность, т.к. нельзя протянуть сто рычагов через весь самолёт, а у программистов таких отрезвляющих рамок реальности нет - код всё стерпит.


    1. Farongy
      06.07.2025 09:55

      у программистов таких отрезвляющих рамок реальности нет - код всё стерпит

      Нет, не стерпит.


      1. Anton_Timofeev
        06.07.2025 09:55

        Читатель кода через некоторое время не стерпит, а коду всё равно


        1. Rive
          06.07.2025 09:55

          Процессор тоже читает код в некотором смысле.


          1. vkni
            06.07.2025 09:55

            Только он читает перевод перевода.


    1. apcs660
      06.07.2025 09:55

      бывает кодирование модели чипа, писать ядра на VHDL, Verilog - чип не стерпит и оптимизация на 10 процентов очень заметна, в том числе денежно.


      1. AlexanderS
        06.07.2025 09:55

        VHDL/Verilog - это всё же не "чистое" программирование наподобии софта для ПК. Если человек не понимает архитектуры FPGA, элементов аппаратной логики и не имеет представление о схеме тактирования, то ничего хорошего он не напрограммирует. Это всё же больше инженерия, нежели программирование.


        1. apcs660
          06.07.2025 09:55

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

          Но в enterprise программировании иногда не понимают что к примеру, на java изображения лучше не обрабатывать, для этого есть более эффективные языки или библиотеки - но нет, прут напролом и в итоге ставят 500 нодов вместо 100 в кластере и при этом с библиотекой на java, которую пересли с библиотеки на С! Потому что родная жрала памяти раз в 10 больше и медленнее раз в 5 чем клон сишной на жабе... На средних картинках. Вот тебе и эффективность.

          Несколько лет клиент жжет электричество используя заведомо неэффективное решение.

          В java даже определить хватит тебе памяти или нет чтобы развернуть изображение, нет нормальных способов. Вернее можно но очень ненадежно, с большим запасом. Ловят оом периодичеси., он кладет веб сервер...

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

          Код все стерпит, это точно, в enterprise так точно


    1. Kergan88
      06.07.2025 09:55

      Разница между программистами и другими инженерами принципиальная - программисты пишут тексты для людей


      1. Anton_Timofeev
        06.07.2025 09:55

        Исходный код - это конструкторская документация.
        Сборка исполняемого файла - это изготовление на заводе.
        Исполнение программы - это работа устройства.

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


        1. victor_1212
          06.07.2025 09:55

          не совсем, КД - описание алгоритма, программирование, отладка, сборка и пр. - скорее этапы исготовления, по опыту так было, хотя возможно есть новые госты, стоило бы проверить


          1. Anton_Timofeev
            06.07.2025 09:55

            Отладка - это скорее что-то типа опытного производства, когда по предварительной КД изготавливают опытные экземпляры, тестируют, вносят изменения в КД, и так по кругу, пока не получится что-то жизнеспособное.


            1. victor_1212
              06.07.2025 09:55

              отладка разная бывает, и дело не в том на что именно похоже, а как определен рабочий цикл - ТЗ, ЭП, ТП, КД, изготовление, по старому программирование и тд. это изготовление, этап КД это алгоритмы, которые тоже конечно не на пустом месте делаются


              1. Anton_Timofeev
                06.07.2025 09:55

                Если бы программирование было частью изготовления - разве его не надо было бы повторять для каждой сборки?


                1. victor_1212
                  06.07.2025 09:55

                  не совсем понимаю Вас, изготовление это процесс, но специфика sw в том, что делается один раз, типа sw сертификацию прошло - изготовление закончено, версия кода заморожена, без разницы сколько надо будет копий, и как именно они делаются, полной компиляцией, сборкой - линкованием, или нет без разницы, конечно по ТЗ могут быть дополнительные требования управления конфигурацией например скриптами и т.п., но это не изготовление, также могут быть особые требования по сопровождению, по памяти примерно так, новые госты могут отличаться


                  1. Anton_Timofeev
                    06.07.2025 09:55

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

                    А программирование - это процесс разработки того, из чего впоследствие исполняемые файлы будут изготавливаться. Типа как создание 3д моделей/чертежей деталей.

                    В этом смысле чертежи тоже один раз сертификацию проходят, так же как и код.


                    1. victor_1212
                      06.07.2025 09:55

                      размышлять можно конечно, но по практическому опыту это не совсем так, как Вы думаете


                      1. Anton_Timofeev
                        06.07.2025 09:55

                        А какое самое вопиющее отличие на Ваш взгляд? А то я в упор не вижу. "Си**ка - си**ка, фрукт - фрукт")


                      1. victor_1212
                        06.07.2025 09:55

                        про "вопиющие" мне судить трудно, но если хотите напишите в личку пару слов про Ваш опыт, станет более понятно, и постараюсь объяснить по мере сил


        1. test4354545
          06.07.2025 09:55

          Если исходный код это КД, то что такое тогда документация к коду?


          1. Areso
            06.07.2025 09:55

            Можно предположить, что и то, и другое - КД. Просто разные "слои" или "уровни".


            1. test4354545
              06.07.2025 09:55

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


              1. Areso
                06.07.2025 09:55

                А вы просто не подшивали исходные коды в папочки, а я подшивал. Каждая версия - распечатывалась, подшивалась, сдавалась в архив архивариусу под акт.
                А вот бинарь - нет.
                Что как бы намекает, что таки да, исходный код - это тоже часть документации.


                1. test4354545
                  06.07.2025 09:55

                  Да, оч крутой аргумент. Я могу и бинарь распечатать и подшить в папочке. Таким образом ВСЕ - документация. Поэтому этот термин бессмысленен если использовать его так как используете вы.


                  1. Areso
                    06.07.2025 09:55

                    Ну, хорошо, вы ВКР делали? Вы в приложениях прикладывали HEX'ы бинаря или исходников?
                    ГОСТ 19.401-78. Единая система программной документации. Текст программы. Требования к содержанию и оформлению. Статус: действует.


                    1. test4354545
                      06.07.2025 09:55

                      Аргументум от ГОСТум. Я вас понял. У нас кстати документация проекта не по госту, и без подшитых папочек. Получается это и не документация вовсе?


              1. PerroSalchicha
                06.07.2025 09:55

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

                Код в классическом понимании, это такая же документация. У конструктора есть техническое задание, которое объясняет, как должна работать его, кхм, разработка. Есть спецификации разных уровней, которые это уточняют уже более детально. И есть чертежи/схемы, которые уже описывают непосредственно всю разработку. Так же и с кодом. Есть техническое задание, есть спецификации на API, структуры данных, какие-то алгоритмы. А есть собственно код, который подробно описывает всё, что должна делать программа. Это тоже конструкторская документация, всё верно.


      1. VladimirFarshatov
        06.07.2025 09:55

        Точно. Люди читают код и исполняют его, а комтьютер - это такая коробчка, где они живут месяцами и бессменно лопатят код.. )


    1. ogost
      06.07.2025 09:55

      Код-то может и стерпит. А клиенты могут и не стерпеть.

      Утеря средств клиентов крипто-биржей из-за кривого кода. Упавший интернет-банк из-за кривых ручонок погромистов с тестерами и, как следствие, финансовые и репутационные убытки у достаточно крупного и зрелого банка. И это наблюдения только из моей практики. Есть и достаточно известные случаи. Например достаточно известен случай про облучение пациентов смертельной дозой медицинским аппаратом из-за кривого кода. Проблемы с MCAS у боинга связаны (в том числе) и с кривым кодом. У Тоёоты были отзывы из-за кривого софта в ABS и, емнип, с цифровой педалью газа, приводившей к неконтролируемому ускорению автомобиля.


      1. wl2776
        06.07.2025 09:55

        ... торговый робот, который за 45 минут спустил в трубу почти полмиллиарда

        И еще один


      1. DMGarikk
        06.07.2025 09:55

        Проблемы с MCAS у боинга связаны (в том числе) и с кривым кодом

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


        1. ogost
          06.07.2025 09:55

          Насколько я понимаю, там целая цепочка проблем. В боинге захотели новые движки, которые были по размеру больше, чем заложенные в проекте. Пришлось их повесить чуть-чуть вперёд и ниже, алтернатива - всё переделывать. Решили таки не переделывать. Что сместило центр тяги и задирало нос самолёта (кривая архитектура). Как костыль приделали (перепрошили?) MCAS, который опускал нос самолёта ниже, основываясь на датчиках. Боинг, посчитав, что в случае проблем с MCAS пилоты разпознают ситуацию как "runaway stabilizer" и отключат автотримминг (или как он там правильно называеся), который в свою очередь отключает MCAS, решило не оповещать об этом авиалинии для включения в тренировки пилотов. Потому что дополнительные тренировки - дополнительные деньги.

          Так вот, MCAS тоже не был должным образом протестирован, и заваливал нос самолёта тогда, когда этого не надо было делать. А пилоты тех злополучных рейсов не распознали ситуацию как "runaway stabilizer" и... в общем дальше вы знаете. Тогда как пилоты как минимум одного другого рейса смогли правильно распознать ситуацию и отключить MCAS.

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


          1. DMGarikk
            06.07.2025 09:55

            ну собственно основная причина именно в архитектуре всего решения в комплексе

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

            по этому я бы инженеров как таковых бы тут не особо и обвинял бы


    1. Fintank-ru
      06.07.2025 09:55

      Уволен нахер. Бугага. Стерпит у него.


    1. test4354545
      06.07.2025 09:55

      Исходя из вашего понимания термина, назовите пару не инженерных дисциплин


      1. Kanut
        06.07.2025 09:55

        А чем вас определение с википедии не устраивает: https://ru.wikipedia.org/wiki/Инженерное_дело ?


        1. test4354545
          06.07.2025 09:55

          Инжене́рное де́лоинжене́рия (от фр. ingénierie ← от лат. ingenium — «искусность» и лат. ingeniare — «изловчиться, разработать» — «изобретательность», «выдумка», «знания», «искусный»[1]) также инжене́рная де́ятельностьинжене́рно-техни́ческая де́ятельностьинжене́рное иску́сство — область технической деятельности, включающая в себя целый ряд специализированных областей и дисциплин, направленная на практическое приложение и применение научных, экономических, социальных и практических знаний с целью обращения природных ресурсов на пользу человека[2].

          исходя из него я могу программировать не "на пользу человека". И получается я не инженер.
          Мне просто нужен ответ на вопрос "что не является инженерной дисциплиной по мнению автора ориг. коммента?", пусть приведет пару примеров и я притяну их к инженерии так же как он пртягивает к ней все подряд включая программирование. Потому что то чем он занимается это софистика.


          1. Kanut
            06.07.2025 09:55

            исходя из него я могу программировать не "на пользу человека". И получается я не инженер.

            Получается. Вообще-то никто нигде и не утверждает что любое программирование это инженерное дело. Что в общем-то относится к любым "разновидностям" инженерного дела. Если кто-то что-то паяет, то он тоже совсем не обязательно инженер-электротехник :)

            Ну а вы вместо того чтобы демагогию разводить можете просто посмотреть перечисленные там отрасли. А точнее: https://ru.wikipedia.org/wiki/Программная_инженерия

            пусть приведет пару примеров и я притяну их к инженерии так же как он пртягивает к ней все подряд включая программирование

            Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято. Причём уже давно. Не особо понимаю что вас в этом не устраивает.


            1. test4354545
              06.07.2025 09:55

              Какйо смысл тогда в утверждении "инженер программист" это инженер?


              1. Kanut
                06.07.2025 09:55

                Не особо понимаю причём здесь это и откуда вы вообще взяли это "утверждение".


                1. test4354545
                  06.07.2025 09:55

                  Относить программирование(или точнее software engineering) к инженерному делу вполне себе общепринято

                  "software engineering это инжинерное дело" - тавтология


                  1. Kanut
                    06.07.2025 09:55

                    Ну так это у вас проблема с тем чтобы относить программирование/software engineering к инженерному делу. Не у меня.


                    1. test4354545
                      06.07.2025 09:55

                      Вы что то запутались в двух соснах. Так ВСЁ программирование это инженерное дело или только software engineering ?


                      1. Kanut
                        06.07.2025 09:55

                        Во первых я же уже выше написал:

                        Вообще-то никто нигде и не утверждает что любое программирование это инженерное дело. Что в общем-то относится к любым "разновидностям" инженерного дела. Если кто-то что-то паяет, то он тоже совсем не обязательно инженер-электротехник :)

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


                      1. test4354545
                        06.07.2025 09:55

                        механика это инженерная профессия, то по вашему это будет означать что все кто занимаются механикой автоматически инженеры

                        Да, это называется логика.


                      1. Kanut
                        06.07.2025 09:55

                        То есть если ребёнок в школе занимается механикой, то он сразу инженер?

                        Мне теперь очень интересно стало увидеть ваше определение инженерного дела :)


  1. samizdam
    06.07.2025 09:55

    Очень напоминает ситуацию с изобретением печатного станка. Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы опытных профессионалов.


    1. avost
      06.07.2025 09:55

      Тоже появилась возможность массово и бездумно воспроизводить то, что было результатом кропотливой (и ручной) интеллектуальной работы

      А в каком месте печатный станок избавил от интеллектуальной работы? Избавил от тупой работы. Интеллектуальной даже прибавил (ответственности) - там, где при ручном переписывании ошибка оказывалась в одном экземпляре, при печати тиражировалась на сотни-тысячи-миллионы.


      1. samizdam
        06.07.2025 09:55

        А в каком месте печатный станок избавил от интеллектуальной работы?

        При рукописном воспроизведении изданий, для каждой копии требовался образованный специалист ("сеньор", в нашей дискуссии). После Гутенберга один специально обученный человек (не обязательно со специальным (духовным) образованием), мог делать сотни копий. И мы по разному наделяем работу "интеллектуальность", возможно. В 15-ом веке, полагаю, переписывание священных текстов не считалось тупой работой, когда процент грамотности на уровне нескольких процентов. Продолжая экстраполировать аналогию на настоящее и будущее и тему статьи - да, сеньоров мало, они дорогие. Будет ли их труд восприниматься чем-то интеллектуальным и особенным будущими поколениями - вопрос. Компьютерная грамотность 10-20 лет назад была киллер-фичей на рынке труда. Сейчас сеньорский скил кажется дешевеет стремительно.

        Вот я сеньор, с 20 лет стажа, за качество и всё такое, и в скорее поддерживаю тезисы статьи, в той же лодке. Сын в 12 генерирует код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель.

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

        где при ручном переписывании ошибка оказывалась в одном экземпляре

        Про описки и опечатки. Как любое массовое производство, где точка контроля одна - литеры, технически, это более дешёвая возможность контроля качества - тираж переиздать при опечатке недорого, если условное ОТК забракует, это не сотни человеко-лет. А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок, из-за которых и повоевать можно)


        1. avost
          06.07.2025 09:55

          Полиграфист - не что-то супер интеллектуальное, обычный пролетарий на производстве

          Да, только образован он получше среднего средневекового монаха-переписчика :)

          Сейчас сеньорский скил кажется дешевеет стремительно.

          Да, только это ведь не уровень интеллектуальности данной деятельности снижается, а общая планка повышается.

          код играбельной игры - за дни. Мне на ту же функциональность нужны недели - тоже разброс в порядок - если не придираться к качеству-чистоте кода и тп, а смотреть на результат как пользователь, потребитель

          Если это одноразовый мусор, то да. В чуть более долгосрочной перспективе нагенерённый код, вероятно, и для пользователя окажется неприемлимым - найдутся и баги и дыры и нестабильности. Сейчас нет проблем без знаний как растирать минеральные пигменты для красок, сфоткать Лизу дель Джокондо и распечатать на струйном принтере. Займёт минуты. Через пару лет выцветет.

          А "легаси" которое веками повторялось из-за одной описки - библия прекрасный пример распространения таких ошибок

          Ну, что касается этих сказаний, то там и ошибок и описок и отсебятины - море (это к вопросу о квалификации переписчиков) просто канонизирован только один вариант. Вот, вам и "отзыв тиража" - анафема на остальные варианты ;).


  1. Fedorkov
    06.07.2025 09:55

    Автор неявно исходит из того, что нас не ждут никакие новые революции в ИИ.

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


    1. GarfieldX
      06.07.2025 09:55

      Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют. По сути это новый уровень поиска с агрегацией, анализом и генерацией ответа.

      Зато нас точно ждут проблемы из-за потери контроля над кодом. По сути в статье это и описано. Например, когда мой код косячит, то практически в 99% могу предсказать где этот косяк. Потому что код писал сам и знаю его структуру особенности, нюансы и вообще все о нем. А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.

      Но с предложением следить дальше полностью согласен. Тем более что нам ничего другого не остаётся. Лишь выбор откуда смотреть. Изнутри или снаружи.


      1. PerroSalchicha
        06.07.2025 09:55

        Именно в ИИ нас пока ничего не ждёт. Нынешние БЯМ к ИИ никакого отношения не имеют.

        Занудства ради, БЯМ - это и есть именно то, что мы называем термином искусственный интеллект, в соответствии с распространёнными его определениями. Просто некоторые люди ошибочно считают, что называться термином "искусственный интеллект" имеет право лишь нечто, как минимум, эквивалентное по возможностям интеллекту человеческому, но только сделанное из деталек. Но это не так, требования к ИИ куда более простые, он должен лишь имитировать некоторые аспекты интеллектуальной деятельности, с чем БЯМ прекрасно справляются.


        1. blind_oracle
          06.07.2025 09:55

          Нет.

          Интелле́кт (от лат. intellectus «восприятие»; «разуме́ние», «понимание»; «понятие», «рассу́док»[1]) или ум[2][3] — качество психики, состоящее из способности осознавать новые ситуации, способности к обучению и запоминанию на основе опыта, пониманию и применению абстрактных концепций, и использованию своих знаний для управления окружающей человека средой

          (Ц) википедия

          Почти ничем из этого LLM не обладают.


          1. VladimirFarshatov
            06.07.2025 09:55

            Это пока и те, которые уже публичны.. :)


          1. PerroSalchicha
            06.07.2025 09:55

            Да. Искусственный интеллект != интеллект.

            Искусственный интеллект - комплекс технологических решений, позволяющий имитировать когнитивные функции человека (включая самообучение и поиск решений без заранее заданного алгоритма) и получать при выполнении конкретных задач результаты, сопоставимые, как минимум, с результатами интеллектуальной деятельности

            Всем этим LLM обладают


          1. samizdam
            06.07.2025 09:55

            Вёл недавно разговор с "умной" колонкой и не смог получить ответ, как вяжется отсутствие психики у ИИ, с тем что интеллект её функция по определению)


      1. apcs660
        06.07.2025 09:55

        годика через два будет просадка по качеству.


      1. Areso
        06.07.2025 09:55

        А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.

        Что с БЯМ, что без БЯМ, бОльшая часть кода была написано до человека, и да, надо как-то прочесть и понять, что за код, что он делает, и где бага. Писать код, в общем случае, давно не является сложной задачей.


      1. Zerik
        06.07.2025 09:55

        >А поиски бага в коде, который писал не ты, да ещё и не человек превращаются в проблему.

        На самом деле нет. Тот же claude через cursor при достаточно чёткой постановке задачи может указать места потенциально приходящие к той или иной проблеме.

        Да и про понимание кода сгенеренного через LLM-тут ведь тоже зависит от того как именно пользоваться, и насколько подробно задачу ставить. Если просто впизтвать в ту или иную агенту систему текст таски и ждать что оно само как нибудь там накодит-да, будут проблемы. Если же рассказать модели что именно она должна сделать-всё намного более предсказуемо и читабелбно получается.


  1. dersoverflow
    06.07.2025 09:55

    1. Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система...

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

    Гмм... А ведь мы это видели!

    На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, продуктивнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать... https://ders.by/pp/ps/index.html

    Да, речь снова про Камень! Без понимания и люди и машины обречены вести себя как дураки:

    1. Все мы разделены Природой на два подмножества: понимальщики и запоминальщики.

    2. Ни понимальщики, ни запоминальщики даже не догадываются о существовании друг друга!


  1. sinerslb
    06.07.2025 09:55

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

    Это если целью является создание кода, подкреплëнного теоретическими основами, но ведь нет. Вокруг капитализм, и в 95+ процентах случаях целью является прибыль, и пока прибыль есть, заказчику пофиг, какой-там код. Катастрофой будет отсутствие прибыли, вот тогда забеспокоятся, и начнут искать новые подходы.


    1. arturdumchev
      06.07.2025 09:55

      Но если кодовую базу совсем запустить, то со временем начнут стрелять проблемы. Time to market (TTM) бизнесу всегда важен, а с плохой кодовой базой TTM будет проседать. Исправление проблем в одних местах будет создавать проблемы в других. Там, где хватило бы двух разработчиков, придется держать команду в 20.


      1. DMGarikk
        06.07.2025 09:55

        ну кстати это одна из причин почему часто корпорации переписывают некоторые продукты с нуля - так дешевле обеспечить ТТМ по фичам и не закапываться в рефакторинг того г-на который накропали в прошлой итерации

        ==

        ну не забывать надо то что писать качественный код сразу - это снижать ТТМ при первом выходе на рынок, когда конкурент на коленке собрал чтото и оно работает..а у вас еще архнадзор деплой не пропускает


  1. VladimirFarshatov
    06.07.2025 09:55


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

    :)


  1. LinkToOS
    06.07.2025 09:55

    Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта? Те же LLM-GPT - это больше предмет для скандалов и споров, чем требование современности. Даже эта статья, опять о проблемах использования ИИ в программировании.
    Не пришло ли время здорового soft-консерватизма? Законсервируем новые разработки, и перепишем винду на ассемблере. Вообще все на ассемблере перепишем.


    1. sic
      06.07.2025 09:55

      Ну а как "прекратить писать новый софт"? Сказать конкурентам - не пишите похожее, я сам допишу и будет все классно?

      Проблема не в коде, проблема в капитализме. Это нормально, когда все-что-угодно "а за деньги да", и что при этом создается тонна хлама, часть из которого чуть более, чем полностью вредна, и еще бесконечная масса однотипных и околоодноразовых поделий. То есть именно это и есть основная масса продуктов.

      Мне нередко снится один и тот же сон. Что мол прилетают пришельцы на планету Земля, и думают, чтобы такого тут сделать, чтобы люди никогда не стали им потенциально опасны. И дарят им идею Интернет. Вообще, чем он хорош, думаю понятно, но чем он плох тоже предельно очевидно, и вот интересно, как пошли дела у нашей планеты, в мультивселенной, где Интернет почему-то не эволюционировал/не прижился.


      1. vkni
        06.07.2025 09:55

        И дарят им идею Интернет.

        +

        Проблема не в коде, проблема в капитализме.

        Ну действительно же — Интернет и программирование — это же просто технологии следующего строя. Поэтому текущий их не может использовать нормально, и просто гадит.

        Если вы посмотрите локусы следующего строя — OSS, то там вполне хорошо и с программированием, и с Интернетом. Когда люди делают для себя, появляются прекрасные TUI интерфейсы, замечательные сайты с минимумом спама.

        Кстати, туда же, в технологии следующего строя, относятся всеобщее образование, всеобщее здравоохранение. Просто мы сейчас живём в эпоху Реставрации.


    1. VladimirFarshatov
      06.07.2025 09:55

      Вы упустили одну базовую лемму программирования: Главный недостаток любого кода - то что он написан не тобою. Следствие в бизнесе: главный недостаток любой программы - она не твоя, а конкурента.


    1. LeVoN_CCCP
      06.07.2025 09:55

      Может вообще уже прекратить писать новый софт? Все нужные программы уже есть. Мы же не умерли год-два назад, с тем набором софта который мы тогда имели. Почему нам этого набора не хватит в следующем-последующем году? Какая реальная польза от нового софта?

      Надо было сразу с козырей заходить - зачем нам столько дистрибутивов Linux?


    1. Kanut
      06.07.2025 09:55

      Мы же не умерли год-два назад, с тем набором софта который мы тогда имели.

      "Мы" и двести лет назад не умерли с тем набором технологий, который имели. И 2000 лет назад не умерли. Ну как вид. Так что теперь НТП не нужен?

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


  1. max-daniels
    06.07.2025 09:55

    Это где-то в мире розовых пони. Сейчас после 35 не берут на работу, всем подавай молодых рабов, авось разберутся вместе с нейросетями.


    1. blind_oracle
      06.07.2025 09:55

      У меня куча коллег-погромистов старше 45-50, со всякими PhD и подобным. Да и я уже не молод :)

      Так что нет, не везде так.


      1. anaxita
        06.07.2025 09:55

        А у нас много таких на хабре, которые с пеной у рта говорят, что 200к потолок))


    1. Ermit
      06.07.2025 09:55

      Тут очень многое от контекста зависит, где, куда, кем, итд. Но конкуренция на рынке труда серьезная, в связи с LLM. И тут еще неизвестно, кому проще, кому после 35 или кому до, поскольку они легче заменяются ИИ.


  1. OlegZH
    06.07.2025 09:55

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


    1. PerroSalchicha
      06.07.2025 09:55

      Что может быть интереснее построения теории кода?

      Быть начальником чуваков, которые занимаются построениями теории кода.


  1. pnmv
    06.07.2025 09:55

    разработчики, высшей квалификации, ну или хотя-бы "выше средней" (middle+), возможно, ещё и нужны, но далеко не все, а только те, кто умеет проходить hr-фильтры.

    если человек с опытом не умеет проходить фильтры (ну или случайно не смог, что равносильно отсутствию навыка), а новичок только и умеет, что понравиться hr, работу получит последний. особенно, если сильно подружится с hr.


    1. PerroSalchicha
      06.07.2025 09:55

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

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


      1. pnmv
        06.07.2025 09:55

        Вы правы. Именно эйчары и не берут. Не раз, слышал от руководителей про "заблокированных эйчарами" кандидатов.

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


  1. 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 и прототипов — в командах, где есть пулы джуниоров.

    Правда там прослеживается влияние на контекст предыдущего общения со мной, но в целом суть такая - нейронка мнение автора одобряет ))


    1. VladimirFarshatov
      06.07.2025 09:55

      Перплексити:

      Моё мнение: статья очень актуальна и глубока, она подчёркивает важность интеллектуальной составляющей в программировании, которая не сводится к механическому написанию кода. В эпоху массового внедрения ИИ и автоматизации именно опыт и понимание старших разработчиков обеспечивают сохранение качества и смысловой целостности ПО. Это важное напоминание индустрии о том, что технологии — лишь инструменты, а основа успешной разработки — человеческий интеллект и теория.


  1. LinkToOS
    06.07.2025 09:55

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

    Прям "Закон Мура" какой-то.
    Сразу можно проблему обозначить - количество разработчиков растет, а суммарный IQ остается постоянным.


  1. apevzner
    06.07.2025 09:55

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

    Я бы тут слегка поспорил. Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.

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


    1. Areso
      06.07.2025 09:55

      Все-таки, мы живем в мире письменной культуре и передаём знания от поколения к поколению через текст, а не от мастера к подмастерьем через поколения.

      Зачем нужны учителя, преподаватели, если есть книги?


      1. apevzner
        06.07.2025 09:55

        Чтобы не одичать


      1. Wesha
        06.07.2025 09:55

        Зачем нужны учителя, преподаватели, если есть книги?

        Затем же, зачем нужны комментарии, если есть код.

        Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».


        1. vkni
          06.07.2025 09:55

          Код (и книги) отвечают на вопрос «что [делать]». Комментарии (и учителя) отвечают на вопрос «почему [мы делаем именно так]».

          То есть, комментарии частично описывают программу на языке, отличном от языка реализации (поэтому неизбежно со слегка другой стороны). Как статические типы. :-) Такое частичное дублирование. :-)


  1. vyatsek
    06.07.2025 09:55

    Нур утверждает, что в своей основе программирование — это построение теории, то есть общей ментальной модели того, как работает система, почему она так работает, и как она должна развиваться

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

    И со своей стороны хочется доучить Си и С++ и уйти писать что-то системно продуманное, нежели, чем ломать голову об очередной модели в обычном продукте, где зачастую о дизайне никто не заморачивается.
    Когда проект загнивает, то тушат джунами и/или деньгами, перематывая изолентой хибернейт, спринг веб, JPA и прочие аббревиатуры.

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

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


  1. RedHead
    06.07.2025 09:55

    Современный мир разработки всё ближе к серьёзной катастрофе. В чём конкретно это выражается?

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

    • В генерации беспредметного кода. Здесь всё ещё печальней. Создаваемые джунами программы не просто лишены фундаментальной теории, но и вовсе являются безличными.

    • В проблемах интеграции. Когда разработчики принимают написанный джунами код без его глубинного понимания, они не просто копируют синтаксис — они импортируют в свою систему чужие архитектурные решения.


  1. zooh
    06.07.2025 09:55

    Если подумать, ИИ мало что изменил в процессе. До него был класс работников, занимавшихся копипастом со stackoverflow, теперь эта работа автоматизирована. Риски подхода сохранились и масштабировались вместе с самим подходом. Раньше бизнес игрался с заменой дорогих сеньоров на дешевых джунов из развивающихся стран и терял контроль над кодом; теперь потерять контроль над кодом можно еще быстрее и дешевле.

    С другой стороны, статья похожа на взаимное самоуспокоение сеньорствующих, которые несколько напуганы движухой. Если предыдущие серебряные пули в виде RAD, микросервисов, Scrum еще можно было принимать, закатив глаза, и ждать, пока труп очередной метододогии проплывет мимо, то в этот раз "оппонент" определенно силен.


    1. VladimirFarshatov
      06.07.2025 09:55

      Всегда говорил, с 80-х, что программисты пишущие ИИ пилят сук, на котором сидят сами. Не помогало ещё ни разу.. )


  1. Zalechi
    06.07.2025 09:55

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

    Жесткая регламентация на базе Институтов Стандартизации. Уровни, протоколы.


  1. Victorbkl
    06.07.2025 09:55

    В тему промт для veo3: Возможно что скорость развития моделей будет нарастать быстрее (или просто будет быстрее), чем рост проблемы, и мы можем не дождаться когда синьоры будут выпущены и очищены от пыли, из старого шкафа, захламленного подвала, заброшенного здания. Уверен синьоры серьёзные люди и сами выйдут на свет новых обстоятельств, накинув лассо на дикого робомустанга пролетающего по новому хайвею рядом с этим зданием.