Целая отрасль замерла в ожидании. Заменит ли LLM программистов? Выпускники школ прямо говорят — зачем поступать на программистов, придёт ИИ и я останусь без работы. В новостях регулярно сообщается о массовых сокращениях в ИТ компаниях. Работодатели пытаются внедрить ИИ и если не уволить, то снизить зарплаты айтишников.

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

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

❯ Корпоративные нюансы

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

Как принимается принципиальное решение о внедрении? Вполне очевидно, что первое побуждение происходит не после глубокого анализа и оценки эффективности, конечно нет. Сначала топы читают в новостях и твитах интервью о новой фиче, за которой будущее. Что наличие этой фичи — это гарантированный успех и признак современной и эффективной корпорации. Стоит отметить, что руководство часто следует из романтических побуждений, поскольку реальных данных или алгоритмов внедрения особо и нет, а есть лишь по сути громкие анонсы, что ИИ круто, за ИИ будущее. Так вот, лицо, пожелавшее романтики, далее ЛПР, ставит задачу — рассмотрите внедрение ИИ в производственный процесс. При этом контекст поставленной задачи подразумевает, что внедрение ИИ это хорошо, это современно, противники внедрения ретрограды. В этом контексте любой эффективный менеджер сделает именно то, что от него требует его природа — нарисует концепцию внедрения, на основании концепции план внедрения и, обязательная часть, бюджет внедрения.  К сожалению, корпоративная этика требует показать не только затраты, но и экономический эффект. И перед защитой проекта в раздел экономической эффективности судорожно вносятся ускорение выполнения задач, снижение ошибок, и, вынужденно, под давлением ничего не понимающих в эффективном бизнесе финансово-экономических служб, включается сокращение штата. Процент сокращения определяется исходя из недостающей суммы до требуемого экономического эффекта.

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

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

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

Но, в конце-концов, проект реализован, всё работает. Время отчётов. Я не верю в правдивость отчётов ни по одному проекту сложнее замены картриджа в принтере (в котором тоже есть нюансы). Если проект реально выполнен хотя бы на 80% от изначально планируемого, это уже успешный успех. Даже здесь на Хабре, когда читаю отчёты об успешном внедрении LLM, я вижу слабые места, о которых старательно умалчивают авторы, и неизвестно как посчитанные метрики, которые в реальной жизни никому не нужны. Ну да ладно. Например классический проект внедрения LLM в документооборот — поиск шаблонов документов. Если смотреть вглубь, то наведение порядка на сетевом диске решит большую часть гипотетических проблем, не создавая новые. Впрочем, так решают проблему 100% предприятий, которые еще не задумались о том, что с LLM это будет гораздо интереснее и неожиданнее.   

Итак, проект реализован, и неромантичная служба аудита спрашивает результат. Их не интересуют качественные показатели, которые хорошо смотрятся в презентациях, им нужен эффект в подтвержденных деньгах. Если эффективный менеджер недостаточно подстраховался, то производится оценка штата и готовятся уведомления на сокращение 20%. Стоны о том, что работа встанет, во внимание приниматься не будут. Менеджер читал Парето и понимает: не все 20% равноценны. Совместно с руководителями подразделений он выберет тех, кто даёт минимум результата. Их сокращение снизит производительность процентов на 5, не больше. Более того, менеджер помнит второй закон Паркинсона: чиновники создают работу друг для друга. В любой корпорации есть те, чья функция — генерировать активность: бесконечные согласования, встречи, отчёты о отчётах. Их увольнение парадоксально облегчит жизнь оставшимся. Да и, в конце-концов, жизнь не кончилась, будут и другие проекты, и другие задачи, под которые снова будет набран штат.

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

❯ Почему LLM не программирует

Принципиальные ограничения LLM:

• Отсутствие ретроспекции (автогрессивная генерация);

• Нарративность вместо логики (природа трансформера);

• Декогеренция в длинных контекстах (фундаментальная проблема).

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

Если человек понимает, что из модуля А однозначно следует модуль Б со всеми его переменными, вводом и выводом, то для LLM это просто токены. Если паттерн сортировки пузырьком будет чуть более вероятен (предположим за счёт использования переменной с названием Bubble), то вполне не исключено использование этого алгоритма на тяжелой базе данных. В огромном поле смыслов, которым является модель, паттерн «сортировки пузырьком» — один из самых сильных и часто встречающихся, особенно в учебных примерах. Когда промпт создаёт «возмущение» в этом поле, этот паттерн начинает резонировать сильнее, чем более сложные, но менее представленные в данных алгоритмы. Модель не выбирает алгоритм на основе анализа сложности O(n²) без особого на то требования. Она просто выбирает наиболее вероятный паттерн именно в этом контексте. Если в промпте есть слово «bubble» или задача напоминает типичную учебную, модель с высокой вероятностью пойдет по траектории этого знакомого нарратива, игнорируя контекст производительности.

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

А для LLM не существует абсолютных законов — есть только более или менее сильные паттерны. У неё нет механизма для проверки инвариантов. Любой «закон» для неё — лишь один из многих нарративов, который может быть «перебит» другим, более сильным резонансом в данный момент. Она не может гарантировать сохранение связности, потому что в её мире связность — это свойство нарратива, а не логики. Рыцарь побеждает дракона, а LLM добавляет переменные rightdecision, finalrightdecision и surefinalrightdecision, потому что с ними код выглядит более связным.

Если программиста попросить доработать код, он его изучит, найдёт слабые или узкие места и точечно их исправит, проконтролировав (ну или постараясь проконтролировать) все взаимосвязи и взаимодействия в программе в целом. Фактически, когда программист делает рефакторинг, он производит точечную хирургическую операцию, сохраняя жизнеспособность всего организма. Когда LLM просят исправить код, она не оперирует. Она пытается регенерировать весь фрагмент заново на основе нового промпта. Это как если бы для лечения сломанного пальца врач предлагал отрастить всю руку заново. Иногда это выглядит похоже, но почти всегда с потерей важных связей со старым кодом

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

Простое увеличение контекстного окна модели не решает проблему: с ростом длины кода количество возможных вариантов «похожих на правильных ответов» растёт быстрее, чем модель успевает их разрешать. А количество действительно правильных ответов для любого кода категорически мало. Чем длиннее код в контексте, тем больше шансов, что модель соскользнет на траекторию, которая будет внутренне логичной, последовательной, но абсолютно неверной в смысле достижения цели кода.

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

На Хабре была статья, где автор предлагал вставлять весь модуль в чат LLM, например, Gemini, у которой контекст 1 миллион токенов, чтобы модель работала со всем кодом. Да, это будет работать на относительно небольших модулях. Но во-первых, остается проблема с ограниченным вниманием, то есть LLM может просто пропустить важные зависимости, и во-вторых, я уверен, что Google не обошел проблему экспоненциального роста вычислений при росте контекста, а просто сжимает контекст после 200 тысяч токенов в основные паттерны, при необходимости разворачивая их, по сути, генерируя заново, или, в лучшем случае, воспроизводя информацию по отдельному запросу, при этом ошибка в 1%, незначимая для гуманитариев, будет фатальна для кода. 

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

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

❯ Предварительные выводы

Текущие костыли, работают где-то лучше, где то хуже:

• Обучение на правильных примерах правильными датасетами

• Проверки через внешние инструменты.

• Техники промптинга CoT, Few-Shot Prompting, RAG и так далее

• Гибридные системы (надстройки контролёры над LLM)

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

Поэтому сегодня LLM может быть ассистентом у человека. Шаблонные модули, шаблонные тесты, автокомплит… По сути LLM становится интерактивным справочником для специалиста. Что, как вы понимаете, не приводит к его увольнению.

Скажут, но повысилась производительность, сократим лишних. А вот здесь важный момент. Если человек контролирует связность проекта и проверяет работу LLM, как много он может удержать в голове? Гениев не очень много, поэтому максимум несколько небольших проектов. Необходимо постоянно ставить новую задачу, а эта работа сопоставима по когнитивным затратам с самим программированием. Если задача чуть больше и сложнее, всё начнет сыпаться. Программист вынужден переключаться и разбираться заново, тратя всё время, сэкономленное ИИ. Это как сшить семь шапок. Задачу выполнить можно, но будет ли это работать неизвестно.

Так что я бы пока сказал выпускникам: программирование остаётся востребованным, меняется природа работы — меньше кода, больше архитектуры и понимания, надо уметь работать с LLM.

Уверен, работодатели это поймут, на своих проблемах или на чужих, но поймут. 

❯ Почему «пока»?

Почему в названии статьи есть слово «пока»? Автор не уверен, что описанные им проблемы LLM существуют? Нет. Я уверен, что текущие LLM меняют подход к программированию, но не заменяют программистов. Проблема в том, что я не уверен в том, как ситуация будет выглядеть через несколько лет. Помните CoT? Когда выяснилось, что по мере роста размера и сложности нейросетей, Chain-of-Thought вдруг стал поддерживаться внутри нейросети? Такое внезапно возникшее эмерджентное свойство. Если экстраполировать, то по мере усложнения моделей мы будем ждать следующие фазовые переходы: 

Meta-reasoning (рассуждение о рассуждении). Признаки: Самокритика во время генерации. Изменение стратегии на лету. Новые идеи, меняющие рассуждение. Требует способность «отменить» предыдущий шаг

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

Альтернативное мышление. Признаки: Симуляция альтернатив. «What if» вопросы. Контрфактуальное воображение. Требует: Способность отменить допущение и пересчитать

Я предполагал, что появление, например, первого пункта, потребует изменения архитектуры LLM, внедрение инструмента, способного отменить ход модели и переиграть его, но фактически предпосылки meta-reasoning уже сейчас можно наблюдать на той же Gemini 2.5 Pro. При генерации длинных стихов с различными промптами модель использовала метод: 

1. Генерация идеи.

2. Рассуждение о рассуждении (Meta-level): Оценка идеи, критика вариантов.

3. Коррекция: На основе этой мета-оценки изменение стратегии и выбор лучшего решения.

Речь не об архитектурной возможности отменить токен. Речь о мета-паттернах самой нейросети — когда внутреннее представление становится настолько богатым, что имплицитно содержит информацию о множественных траекториях и их оценках. То есть при усложнении нейросети появляется метапаттерн ошибочности паттернов, самокоррекции, глобальной связности. Модель не думает «а что, если попробовать по-другому?» — она уже содержит это «по-другому» в своих весах. Фазовый переход может произойти без изменения архитектуры. Просто через масштабирование, лучшие данные, мета-обучение. 

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

И это может случиться раньше, чем мы думаем.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud - в нашем Telegram-канале ↩