Код во второй четверти XXI века. Часть 1

2025-й год завершил эпоху классической разработки ПО. Эта эпоха началась крахом «пузыря доткомов» 10 марта 2000, но привела к распространению сети Интернет по всей планете, в том числе с применением низкоорбитальных спутниковых сетей. Сейчас мы не мыслим экономику без коммуникаций в сети, но 25 лет назад интернет стал одним из немногих, если не единственно возможным, «социальным лифтом» для множества людей. В том числе и для меня. Я полагаю, что что-то подобное ждет нас и в 2026-м. Инструменты разработки изменились радикально, но «новой экономики», где неосязаемые активы преобладают над ресурсными, снова не случится, несмотря на обещания AI-визионеров. В пользу такого вывода у меня есть ряд соображений.

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

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

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

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

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

Однако с использованием этого инструмента можно многократно повысить эффективность «традиционного» бизнеса или реализовать новую бизнес-идею (невозможную или неэффективную без интернета).

Мы активно пользовались Википедией и подобными ей ресурсами, спокойно осознавая, что информация в вики-статьях может быть недостоверной или искаженной, но… все равно пользовались, потому что она позволяла найти информацию быстро. Объем семантических связей, сформированный децентрализованным сообществом авторов, компенсировал неполноту или неточность. Спустя некоторое время способ поиска информации трансформировался из «нагуглил» в «нагуглил на стековерфлоу». Здесь уже в ответ на запрос предлагалось несколько вариантов ответа, причем вместе с ответом отображалась популярность (рейтинг) ответа. Благодаря интенсивному взаимодействию людей через интернет мы получили статистическое распределение «весов» ответов. Начиная с 2022-го способ поиска информации трансформировалося из «нагуглил в стековерфлоу» в «нашел ответ через гугление и эйай». Теперь поиск ответа и вероятность ответа совмещены в единой системе (LLM). Вместе с тем как бы не менялся инструментарий, навык чтения документации (т.е. поиска в первоисточниках) остается в профессии разработчика неизменно важным, а в ряде случаев необходимым. Символично, что на момент подготовки этой статьи в апогее AI-пузыря Википедии тоже исполняется ровно 25 лет.

Человеческий разум эволюционирует медленнее технологий, если эволюционирует вообще, поэтому оба пузыря протекают также в условиях одинаковых когнитивных искажений, присущих людям. В программировании одно из таких искажений выглядит так: «Если я знаю, как это сделать, то считаю, что уже сделал это». Такое искажение обусловлено самой средой: в программировании мы либо решаем задачу самостоятельно в течение неопределенного времени, либо переиспользуем готовое решение, но уже мгновенно. В этих условиях «знать, как делать» приравнивается к «сделано», поскольку чтобы понять, как решать задачу, ее… нужно решить! Даже в тех случаях, когда уверенность «точно знаю, как делать» приводила к срыву сроков, программист всегда мог сослаться на неполную постановку задачи или недостаточную проработку граничных условий. Дескать, именно ошибка в постановке привела к неправильной оценке. Более того, в профильных ВУЗ-ах студенты с первых курсов усваивают «базу»: «Ошибка, выявленная на этапе проектирования, обходится в сотни раз дешевле, чем ошибка, выявленная на этапе тестирования». Очень удобно, если за проектирование отвечает кто-то другой.

Пока программист отвечал только за кодовую базу, положение дел сохранялось. Программиста оценивали (и соответствующе ему платили) исключительно за его знания кодирования и способность эти знания применять. Да, в сфере разработки всегда было много баталий про значимость «софт-скиллз», но факт оставался фактом: без «хардов» программист — не программист на любом собеседовании. С приходом LLM оказалось, что есть нечто, что кодирует лучше любого среднестатистического программиста просто потому, что это нечто знает все популярные языки программирования и все модные фреймворки. В связке с когнитивным искажением «знаю == сделано» это AI-нечто привело к упадническим настроениям «моя профессия больше не нужна» с одной стороны и необоснованно оптимистичным ожиданиям «вот теперь-то код будет готовиться быстро и дешево» с другой. Пузырь, хайп и кризис как он есть. Из истории мы знаем, что кризис обязательно заканчивается созданием чего-то нового. Но как это новое ощутить или даже предвидеть, с учетом того, что предвидеть будущее невозможно?

Уже много лет, чтобы сохранить ментальное здоровье в постоянно меняющемся и неосязаемом IT-мире, я практикую столярное дело. Программирование максимально удалено от прикладной столярки, однако в этом случае стратегия штанги по Талебу дала свои плоды. Высшее образование в области физики и информационных технологий я дополнил полугодовыми курсами в профессиональной столярной школе, однако именно эти практические курсы (т.е. «база» в связке с обязательной практикой) помогли мне спокойно «приземлить» бушующий в интернете AI-хайп на мой практический опыт разработчика.

Столярное дело по своей сути мало изменилось за последние несколько тысяч лет, равно как и человеческий разум, поскольку древесина осталась древесиной, а человек — человеком. В XX-м веке мы массово начали применять плитные материалы (фанера, МДФ, ДСП, ОСП), которые на порядок удешевили производство мебели, но так и не заменили древесину полностью. «Настоящее» дерево приятнее на ощупь, эстетичнее визуально и гораздо более ремонтопригодно. Появился дешевый и надеждый клей ПВА и возможность использовать склеенные щиты, однако клей не отменил «базу», выраженную в анизотропии древесины и ее реакции на перепады влажности воздуха. Дверь из массива должна быть именно каркасной и филенчатой, если мы хотим без усилий закрывать ее летом и не хотим щелей зимой.

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

В столярном деле искажение «знаю == сделано» проявляется гораздо быстрее и нагляднее, чем в IT. Тот факт, что я знаю, как сделать табурет, вовсе не означает, что я сделаю табурет мгновенно. Более того, первый табурет некоторой выбранной конструкции я делаю неделю, даже с учетом всего парка инструментов. Ручной инструмент нужно наточить, а для станков нужно сделать множество вспомогательных приспособлений (прижимы, разметочные кондукторы и др.). Следующий табурет уже можно будет сделать за день, а через несколько месяцев ежедневных оптимизаций с целью побить рекорд — уже (возможно, но не факт) за 4 часа. Но не меньше! Если же делать табурет полностью «в рукопашную» без станков, то процесс займет все ту же неделю. И тому есть ряд наглядных причин.

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

Во-вторых, станок – это все тот же инструмент, только высокоуровненевый. Цепочка специализированных ручных инструментов всегда даст лучший результат, чем один универсальный «комбайн». Пилой удобно пилить, а молотком удобно стучать.

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

Проще говоря, нужны навыки столярной «базы» и понимание, как устроена древесина. Разумеется, всегда можно купить дополнительные станки: «волну» можно убрать барабанно-шлифовальным станком, а пазы делать фрезером. Далее выяснится, что для барабанника потребуется мощная аспирационная система, если мы не хотим заработать силикоз. Фрезер делает пазы быстро и ровно, но со скругленными краями, поэтому ответные шипы тоже нужно скруглять вручную (!) либо купить готовые либо перенастраивать фрезер для изготовления шипов. Окупить такие затраты можно только на массовом производстве, т.е. снова придется думать о рынке сбыта. Альтернатива — изучить базу, т.е. научиться вручную, на практике применять рубанки и стамески. На курсах столярного дела преподаватель четко обозначил, что самый лучший результат можно получить, если объединить машины и ручной инструмент, причем сделать это надо в условиях конкретной мастерской, заточенной под конкретного мастера и находящейся в конкретной местности. Ровно то же самый подход можно применять в IT, а именно — практиковаться.

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

LLM общего назначения — это универсальный комбайн, который:

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

Таким образом, индустрия программирования не исчезла, но сместилась из кодирования на языках высокого уровня в кодирование на языках системного и бизнес-анализа. Подобное уже происходило в истории: когда-то SQL позиционировался как язык для бухгалтеров. Сейчас SQL входит в TOP-10 языков программирования вообще, а для мобильных разработчиков по результатом техрадара на конференции Mobius 2025 Autumn это вообще «первый второй язык». В бущем можно ожидать взрыв видового разнообразия языков, предназначенных для описания бизнес-процессов. Единственный способ выяснить это — «сделать табурет» на практике. Для программиста самая доступная практика — это pet-проекты. Если ранее полноценный сервис, включающий в себя бекенд, фронтенд, дизайн, тестирование, администрирование и непосредственно технологическую или бизнес-идею требовал полноценной команды, то в текущих реалиях доступа к LLM-агентам все это можно сделать самостоятельно. Не имеет значения, каким получится табурет — важно, что он создан на практике. Именно эта практика позволяет отделить хайп от инструментов и возможностей будущего.

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

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