Целая отрасль замерла в ожидании. Заменит ли 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. При генерации длинных стихов с различными промптами модель использовала метод:
Генерация идеи.
Рассуждение о рассуждении (Meta-level): Оценка идеи, критика вариантов.
Коррекция: На основе этой мета-оценки изменение стратегии и выбор лучшего решения.
Речь не об архитектурной возможности отменить токен. Речь о мета-паттернах самой нейросети — когда внутреннее представление становится настолько богатым, что имплицитно содержит информацию о множественных траекториях и их оценках. То есть при усложнении нейросети появляется метапаттерн ошибочности паттернов, самокоррекции, глобальной связности. Модель не думает «а что, если попробовать по-другому?» — она уже содержит это «по-другому» в своих весах. Фазовый переход может произойти без изменения архитектуры. Просто через масштабирование, лучшие данные, мета-обучение.
Когда метапаттерны самокоррекции станут достаточно сильными, модель перестанет галлюцинировать, ломать инварианты в коде, начнёт делать хирургический рефакторинг вместо переписывания заново.
И это может случиться раньше, чем мы думаем.
Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud - в нашем Telegram-канале ↩
Комментарии (55)
Dukeru
10.11.2025 14:12Цитата "Это значит, что ИИ не пишет код, который бы работал. Он пишет код, который выглядит как работающий код."
Полностью согласен.
AdrianoVisoccini
10.11.2025 14:12чаще скорее наоборот
Код работает
а вот как он написан....
2medic
10.11.2025 14:12На мой взгляд, код от ИИ очень хрупкий. Уже неоднократно ловил его поделки на том, что он будет работать, но при некоторых кейсах — не будет. И вот когда эти некоторые кейсы будут происходить, разработчики заколебутся осознавать, что не так в системе, и почему вчера всё упало, а теперь вновь работает и ошибка не воспроизводится.
Из недавнего: модели было поручено найти первый день месяца на основании периода. Числа, закодированного в формате yyyymm.
$yyyymm = 202509; $firstDay = Carbon::createFromFormat('Ym', $yyyymm)->firstOfMonth();Этот код будет прекрасно работать практически всегда и выдавать объект с датой: 01.09.2025.
Но 31.10.2025 он выдаст 01.10.2025.
При этом сам ИИ ошибки в коде не видит, и когда выдаёшь ему промт: найди что здесь не так, что приводит к ошибке, отвечает: всё так, мамой клянусь!
user-book
10.11.2025 14:12выглядит как что то из мира JS
а как правильно? чисто любопытно, ведь по логике все ок и ваш пример валиден - первый день месяца, что еще надо?
2medic
10.11.2025 14:12Это PHP и Carbon — удобное расширение стандартного DateTime, фактически ставшее стандартом для работы с датами.
Carbon под капотом хранит число секунд от начала эпохи Unix с привязкой к таймзоне.
Поэтому когда не видит дня месяца, берёт текущий.
В результате, если вызывать этот код 31 октября получим 31.09.2025. Но 31 сентября нет, поэтому Carbon перескакивает на следующий день.
Итого, то, что вроде бы работает отлично, в последние дни некоторых месяцев будет превращаться в тыкву.user-book
10.11.2025 14:12интересно. но как по мне в рамках нейронки это лечится промтом "не используй сторонние библиотеки". Причем задача простецкая, они тут и не нужны, максимум хватит стандартного вшитого
и это правильная практика, в простых но важных задачах точно очерчивать предметную область. Известная проблема что с либами неронки работают как бог пошлет.
кстати проблема такая что тут и человек бы споткнулся, отличная проверка на знание конкретной либы. И проблема возникает из-за кривизны либы в первую очередь (показатель стандарта наглядно)
UPD
у вас в сообщении выше пример неправильный, должно быть 31.09.2025 если я правильно понял как оно "ошибается"
Собственно почему и написал что вам не понравилось, потому как по примеру все ОК
2medic
10.11.2025 14:12это лечится промтом "не используй сторонние библиотеки"
Нативный класс в PHP это DateTime. И в нём будет воспроизведена та же самая проблема. Carbon просто расширяет поведение DateTime.
И, опять же, сильно зависит от того, что требуется получить. Если просто строку вида '2025-09-01' из числа 202509 это одна ситуация.
Но на выходе может ожидаться именно Carbon с нужной датой, потому что его ожидают другие части системы.в простых но важных задачах точно очерчивать предметную область
В простых задачах быстрее написать код самому, чем очерчивать предметную область. Казалось бы, выгода от нейронки там, где нужно писать много кода.
Но потом ревьюить и вот такие вот баги выискивать - облезешь.
у вас в сообщении выше пример неправильный, должно быть 31.09.2025 если я правильно понял как оно "ошибается"
Можно подробнее? Вроде бы у меня так и написано. Ошибается оно так: верно вытаскивает из числа 202509 месяц (09) и год (2025). А день берёт текущий. Поэтому по 31-м числам будет перескок на следующий месяц.
user-book
10.11.2025 14:12Но 31.10.2025 он выдаст 01.10.2025.
тут все верно, никаких ошибок
а должно быть так: `Но 31.09.2025 он выдаст 01.10.2025.`по поводу нейронок вы в корне не правы. Нельзя им давать писать много сложного. Максимум как MVP идеи, все остальное или очень простое иди четко очерчивать задачи.
Даже в мелких задачах могут быть мелочи про которые ты не вспомнишь или реализация по иному, не факт, что ты ее используешь, но это натолкнет тебя на мысли дальше
в рамках вашей задачи я бы просто расписал что именно делать: определяем что строка валидна, режем на две строки года и месяца, подставляем в конструктор date_create и обрабатываем ошибку на всякий случай
хотя если это у вас узкое место то лучше по сопоставлению, забить 12 комбинаций в разы проще чем куча алгебры и трансформаций и такую рутину неронка опишет с полпинка
2medic
10.11.2025 14:12тут все верно, никаких ошибока должно быть так:
Но 31.09.2025 он выдаст 01.10.2025.Нет-нет, всё верно. Если код выполняется в октябре, а входной параметр —
202509, то он будет возвращать правильную дату весь месяц, кроме последнего дня.Например:
25.10.2025
createFromFormat('Ym', '202509')создаст дату2025-09-25. МетодfirstOfMonth()вернёт корректное2025-09-01.31.10.2025
createFromFormat('Ym', '202509')попытается собрать2025-09-31. Такой даты нет, и Carbon (как и DateTime) нормализует её в2025-10-01. После этогоfirstOfMonth()уже вернёт первое октября, а не сентября.То есть ошибка проявляется только в последние дни месяцев, где количество дней больше, чем в сентябре — из-за того, что
createFromFormat()подставляет текущий день, если его не указать.user-book
10.11.2025 14:12что то лыжи не едут
первый день 31.10.2025 это 01.10.2025, тут нет ошибкито есть вы неправильно написали пример ошибки
2medic
10.11.2025 14:12Мы рассматриваем первый день от периода, выраженного целым числом 202509, а не берём текущую дату. Представьте те две строчки, как функцию, которая на вход получает int $period.
Вроде бы чистая функция? Ан нет. Имеет странный побочный эффект.
user-book
10.11.2025 14:12дошло
у вас очень криво подобран пример, непонятно что в нем мы говорим все еще про хх.09.2025 как период разборая думал что 202510 возвращает 01.10.2025 что как бы верно
maikuss
10.11.2025 14:12Недавно попадался на глаза чей-то (программиста) комментарий, мол, с помощью ИИ он выполняет задание втрое быстрее и приступает к следующему, которое также делает втрое быстрее. И делался вывод, что в его компании ИИ уже заменил двух программистов из трёх . Логично же?
Kamil_GR Автор
10.11.2025 14:12И вы говорите...
Но конечно нужно больше контекста. Как я писал в начале, штамповать шаблоны и строить архитектуру, это разные вещи.
chesser69
10.11.2025 14:12Написать код это только часть процесса.
Труднее его отладить или, после тестирования, найти причину выявленной проблемы.
Так же, чтобы код был в стилистике ряда сопровождаемых проектов, иначе поддержка этого кода, для команды, заберёт больше чем его выигрыш.
Тут интересно какие задачи он решает.
Может уровень настолько прост, что ИИ ему дополняет код исходя из контекста и сигнатуры? )))
piton_nsk
10.11.2025 14:12с помощью ИИ он выполняет задание втрое быстрее и приступает к следующему, которое также делает втрое быстрее.
Интересно, платят ему тоже втрое больше?
iiwabor
10.11.2025 14:12Раньше суперкомпьютер проигрывал в шахматы человеческому чемпиону, потому что у человека было то, что у компьютера не могло быть по определению - интуиция. Человек чувствует, что вот этот ход сейчас лучший, но объяснить почему так - в данный момент не может и делает лучший ход интуитивно.
Но постепенно суперкомпьютер становился все производительнее и производительнее, и в какой-то момент просто стал просчитывать ВСЕ ходы на недоступную человеческому мозгу глубину. И человек проиграл.
Я постоянно использую Github Copilot в работе и могу точно сказать, что он уже на уровне средне-статического джуна - он вполне эффективно делает простые задачи, конечно за ним все надо проверять - собственно, как и за человеческим джуном.
А вот если они увеличат производительность и дотянут ИИ до мидла, то... то большинство программистов можно будет им реально заменить, оставив только тех, кто будет проверять результат работы ИИ и делать code-review. И это не выглядит недостижимым, к сожалению для нас, кожаных уб...
fixikus
10.11.2025 14:12Ну давайте посчитаем. В шахматах 64 поля и 32 фигуры. Сколько сейчас языков, фреймворков, баз данных, моделей данных, протоколов передачи данных и т.д и т.п? Брудфорсом это все осваивать никаких мозгов не хватит, даже электронных. Это не говоря о том, что в шахматах строгие правила. Есть ли такие правила в программировании?
iiwabor
10.11.2025 14:12В шахматах существует огромное количество вариантов ходов, и общее число уникальных партий оценивается примерно в 10 в 120-й степени, — это больше, чем количество атомов во Вселенной.
fixikus
10.11.2025 14:12А теперь посчитайте количество вариантов реализаций различного по, мне кажется оно стремиться к бесконечности. Смысл не в количестве вариантов даже, а в том, что как таковых "правил" в програмировании нет. Есть шаблоны и best practice, которые могут друг другу противоречить. То есть, вероятность того, что llm начнет ходить по кругу стремиться к 100%, что мы, собственно, и наблюдаем
Moog_Prodigy
10.11.2025 14:12Но это пока. Да и то, уже не везде наблюдаем. Спрашиваешь человека - а что ты хотел от llm? Он такой - да ничего особенного, я её попросил написать свою ОС, она жоско затупила. Оно говно.
Утрирую конечно, но не стоит ждать от инструмента, что он за тебя думать начнет. Кодить - может. Недалеко и недолго, но может. Думать - пока еще нет. Но пока.
fixikus
10.11.2025 14:12Думать он не начнет никогда, с той основой, что сейчас, пытаясь предсказать следующее слово.
Он такой - да ничего особенного, я её попросил написать свою ОС, она жоско затупила. Оно говно.
Я переодически пробую llm, но раз за разом она на простых примерах глючит и выдает хрень в >50% случаев. Может для питонистов и джаваскриптизеров этот процент пониже, но у меня на C/C++ и C# все плохо и лучше не становиться, да и врядли, станет
chesser69
10.11.2025 14:12Было всё не так. Если бы, в шахматах, комп реально считал все варианты, то человек был бы много дольше сильнее (сейчас, наверное, уже нет). Резкий прорыв при игре с человеком, обеспечил ФВ (форсированный вариант). В алгоритм стали закладывать, что большинство вариантов считают на глубину ограниченную (как правило, временем), а варианты со взятиями и шахами считают много дальше. Тут человек сразу и поплыл.
dplsoft
10.11.2025 14:12Раньше суперкомпьютер проигрывал в шахматы человеческому чемпиону, потому что у человека было то, что у компьютера не могло быть по определению - интуиция. Человек чувствует, что вот этот ход сейчас лучший, но объяснить почему так - в данный момент не может и делает лучший ход интуитивно.
Но постепенно суперкомпьютер становился все производительнее и производительнее, и в какой-то момент просто стал просчитывать ВСЕ ходы на недоступную человеческому мозгу глубину. И человек проиграл.
Вы используете дешевые спекуляции, и, кажется мне, вы рассчитываете на читателя-неофита, не знакомого с "проблемой алгоритмизации Го" )) игра такая, древне-китайская.
"Хит продаж последних 5 тысяч лет".
Суть проблемы в том, что игра Го - до сих пор не алгоритмизирована. Нет алгоритма который бы помог вам рассчитать какой делать ход дальше в Го - нет. Шахматы, для сравнения, алгоритмизировали ещё около 60-х годов прошлого века, и дальше был вопрос только наращивания вычислительных мощностей. Шахматные компьютеры были ещё в СССР. С го-же ситуация кардинально другая. Есть нейросети, которые выигрывают, но они выигрывают не алгоритмами.Во первых, в Го комбинаторика такая, что до сих пор ни один "кластер" не может это просчитать на всю глубину. Число комбинаций на доске 19*19 сравнимо с числом атомов во вселенной. В шахматах-же, на этом фоне - комбинаторика очень маленькая.
Во вторых, в Го нет "ценности хода". В отличии от шахмат, где слон равен трем пешкам (условно) и ситуация на доске очень легко оценивается численными методами.
В Го очень часто невозможно "оценить количественно" ценность конкретного хода. Ценность имеет "конструкция", комбинация камней на доске, "форма" из трех-четырех камней. Причем относительную - потому что важна ситуация на доске. И получится у тебя выстроить комбинацию или нет - ещё вопрос - противник то тоже строит "конструкции". То что ты строил, перестает работать и становится бесполезным (в плане достижения цели партии), потому что противник сделал "не то" и влияние окружающих камней теперь другое. И сработал или нет конкретный ход - окончательно станет понятно только в конце партии. Отсюда - перебирай ты варианты, не перебирай - ценность этого хода ты не выяснишь - она вполне себе статистически будет одинаковая - в половине исходов ты проиграл (это не говоря о проблеме перебора всех вариантов).Но натренированная на всем массиве игр и самостоятельных играх ИИ (та же альфаГо кажется) сегодня выигрывает в Го. Выигрывает не перебором или интуицией, а статистически настроенными весами в связах "нейронов". Она генерирует наиболее вероятные ходы из тех партий, которые похожи на текущую ситуацию и были выиграны. Вероятные ходы - на основании "впитывания" миллионов партий - накопленных за последние несколько тысячи лет людьми - в Японии есть институт Го который хранит партии сыгранные задолго до вашего рождения, причем там "хорошие парти" - сыгранные профессиональными игроками; это я отсылаю к проблеме поиска обучающей выборки для ИИ) и миллионов партий, сыгранных самим с собой (в пересчете на одна партия - один час, он наиграл сам с собой несколько тысяч лет)
И, повторюсь, альфа-го и ему подобные выигрывают у человека,... но есть нюанс.
В основной своей массе выигрывают. Кроме тех случаев, когда люди (про-игроки высоких данов) умудряются изобретать новые комбинации или эксплуатировать некоторую повторяемость/механистичность действий программы (которую они, как профессионалы в своей области, там, по отзывам некоторых, видят).Я это вам рассказываю, чтобы другие читающие вас, не поддавались на описанный вами как основание нарратив )) Он ошибочен (во первых, не перебором сильна ИИ, во вторых - она сильна только пока "находится на области обучения").
Отсюда - и выводы, которые вы строите на основании введения - вероятно ошибочны.
Я с частью ваших слов, как с оценками будущего, даже согласен - мидла нейросети не достигнут при текущих технологиях и имеющихся массивах кода. Но доказательная цепочка вами предложенная - ошибочна.
Dimmirslr
10.11.2025 14:12Аналогия с шахматами не совсем корректная - шахматах есть строгие правила, конечная цель и объективная метрика успеха (победа/поражение)
В программировании ничего этого нет. Правила постоянно меняются, цель часто размыта, а успех субъективен. Это гораздо более "грязная" задача
sunsexsurf
10.11.2025 14:12Я поймал себя на очень плохой мысли недавно, на неприятном ощущении. Когда пишу какой-то модуль, закидывая базовую задачу (даже если строго по шагам) в перплексити, то потом, когда что-то руками в коде сам дописываю, то отправляю в модельку еще раз «проверить, че я там написал». Оно как-то органически выросло само, но, поймав себя на этой мысли, не могу сказать, что она мне нравится. Чувство, к которому прихожу, такое: постоянный «вайб-кодинг» - хуже наркомании: очень сильно тебя привязывает и ты становишься просто «буфером обмена» между ответами модельки и твоей IDE. А если курсором пользоваться - так вообще не ясно, чем ты сам занят. Брррр.
NeoNN
10.11.2025 14:12Угу, тупеешь, надо в "качалку" литкодовскую ходить и читать книжки по программированию. Еще уточнять у модели "почему" бывает полезно. Но чаще всего, конечно, выдаётся решение неоптимальное, а иногда и просто нерабочее.
Dimmirslr
10.11.2025 14:12Как с калькулятором. Если постоянно им пользоваться, то в какой-то момент ты забываешь, как делить в столбик, и это не страшно, пока под рукой есть калькулятор, а вот когда его нет...
Jecky
10.11.2025 14:12От промта и постановки задачи очень зависит, пока сама себе сетка ставить задачу не очень может, отсюда и большинство проблем дебаггинга. Пока нужно писать длинный промт, программист будет нужен. Ну и со стихами Басё-Кисё даже Gemini 2.5 Pro можно сказать не справляется, ну с 10-го раза кое как, и промт на пару страниц
farengeyt451
10.11.2025 14:12Работодатели пытаются внедрить ИИ и если не уволить, то снизить зарплаты айтишников.
Вот с этим согласен, сейчас llm используют как рычаг давления и пугалку (и у меня на работе тоже) на разработчиков. Не думайте о повышении зарплаты, скажите спасибо что у вас работа есть. Но на текущий момент llm не может полностью заменить разработка иначе в реалиях текущего мира жестокого капитализма мы бы наблюдали массовое внедрение llm. Зачем платить команде из десяти разработчиков если их можно было бы заменить двумя "вайб кодерами"?
dplsoft
10.11.2025 14:12Зачем платить команде из десяти разработчиков если их можно было бы заменить двумя "вайб кодерами"?
Дада. Вайбкодеры — новые «индусы». #йапиарюсь ;)
и развитие сиуации, судя по всему, будет аналогичное.
За той разницей, что "индусский код" не уничтожил локальные команды, а эти архаровцы (эффективные менеджеры), не смыслящие в отрасти, могут.
Dimmirslr
10.11.2025 14:12Вся эта история с увольнением программистов просто театр для инвесторов - руководство читает в новостях, что ИИ это будущее, и чтобы выглядеть современными, они объявляют о трансформации и оптимизации, сокращают 10-20% самых неэффективных сотрудников, которых и так собирались уволить, а сэкономленные деньги вкладывают в пилотный проект по внедрению ИИ. В отчетах - красота, а на деле ничего не поменялось
user-book
10.11.2025 14:12на деле в больших компаниях постоянно текучка кадров и сокращая они тут же нанимают им на замену кого-то
просто выкинув отдел заменив ИИ это не театр, это абсурд (cloudflare и amazon передает привет)
2medic
10.11.2025 14:12И это может случиться раньше, чем мы думаем.
А может и не случиться. Уже близок потолок возможностей текущих архитектур вроде трансформеров. Модели стали больше, умнее и аккуратнее, но это уже не даёт новых качественных скачков — только постепенные улучшения.
Достигнут архитектурный предел. Трансформеры умеют только предсказывать текст. Они не понимают причинно-следственных связей и не могут реально думать. Т.е. их задача — дать текст, максимально похожий на ответ на заданный вопрос, на основе уже виденного текста.
Данные тоже конечны. Интернет уже весь выкачали. Новые данные, те же тексты, только зашумленные.
Достигнут предел вычислений. Следующий порядок роста обойдётся очень дорого. И в деньгах и в энергии и во времени.
Kamil_GR Автор
10.11.2025 14:12Кстати да. И сейчас надо пересматривать принципиально методы обучения. С текущим подходом не хватит и всех данных мира.
Calculater
10.11.2025 14:12Так вот, лицо, пожелавшее романтики, далее ЛПР, ставит задачу — рассмотрите внедрение ИИ в производственный процесс.
Какой трогательный эвфемизм...
RedHead
10.11.2025 14:12>По состоянию на 10.11.25 автор думает что LLM пока не отберут работу у программистов
amazingname
10.11.2025 14:12Для бизнеса AI в разработке сейчас это то же самое как в начале 90х интернет в разработке. Это не новая технология которую надо внедрять. Это новая реальность от которой вам никуда не деться.
Т.е. вы конечно можете если у вас сидит команда обложившись книжками подключить им интернет, отправить их на курсы интернета и уволить пару человек надеясь что у остальных же теперь работа с интернетом пошла быстрее.
На все это было бы глупо. Потому что интернет у них уже есть дома и на работе так или иначе будет, они сами уже роют что там полезного в интернете и вы их ничему не научите, разрешения пользоваться интернетом в работе они у вас не спросят, а работа пошла быстрее не только у вас но и у ваших конкурентов, соответственно подросли аппетиты заказчика и уволив лишних вы проиграете.
fixikus
10.11.2025 14:12Смысл интернета - в открытости информации, вы правы. Но llm это не интернет, это ТВ. По началу типо было круто. Сейчас - шлак полный, смотреть по ТВ нечего, одна реклама и пропаганда. Llm по тому же пути идут.
Ooaoo
10.11.2025 14:12
я тут недавно полез узнать по поводу регистров некоторых у проца и вижу, что дипсик явно что то не то говорит, в итоге спустя 5-6 запросов я смог убедить что он не прав. А так он мне скидывал пункты из даташита, номера страниц где можно было прочитать. Потом кидал строчки инклуда, где должны были быть прописаны регистры которые он выдумал и тд)
AdrianoVisoccini
итого
Почему современные LLM пока не отберут работу у программистов? Может и отменят и может даже раньше чем мы думаем. Отлично согласованная статья хочу заметить
Kamil_GR Автор
Да. Пришлось быть честным.. Современные LLM не программисты, а vibe и хайп, но по здравому размышлению, не смог заставить себя также уверенно заявить о будущем.
flancer
"Современные" - не отберут, а вот из "ближайшего будущего" - возможны варианты.
Uroborus
С такой аргументацией можно писать о любой профессии что она завтра будет не нужна.
"Сегодня технологии не отберут работу по профессии X, а вот завтра могут и отобрать."(c)
Что технически является правдой. Но в таком случае какой толк от таких статей, если все сводиться к тому что вероятность потерять работу равна вероятности встретить динозавра на улице - 50/50?
Kamil_GR Автор
Потому что я не могу позволить себе в отличие от многих экспертов утверждать, что через год останется один программист из 100. Или через пять лет. Во-первых это будет неправдой. Во-вторых, ни конкретных сроков, ни конкретных прогнозов назвать сейчас нельзя. А тот кто называет, делает это от балды. В чём я уверен на 100%, это то что текущая итерация LLM программистов не заменит, и весь хайп с сокращениями, это именно хайп, не связанный с эффективностью LLM как кодера. Об этом я написал.
Но бездумно переносить это в будущее неправильно. И я предполагаю, что даже без изменения архитектуры LLM возможно принципиальное повышение качества ее работы. И это надо учитывать. Но сроки никто не назовёт. Вообще есть вероятность, что нужно менять принципиально метод обучения LLM, потому что в таком виде возможно не хватит всех данных мира для следующего фазового скачка.
2medic
Просто сейчас модно объяснять кризис новым словом ИИ. Рынки объективно сжимаются, и происходит это на фоне того, что глобализация в последнее время буксует. Так что сокращения будут. Но не по причине ИИ. Хотя на него будет модно ссылаться.
flancer
Какой толк вообще от всего, если Тепловая смерть Вселенной наступит с вероятностью 100%? Но коммент свой вы всё-таки написали.
Полагаю, у всех есть поводы делать то, что они делают, просто остальные не все и не всегда могут эти поводы понять. Вернее, все всё понимают лишь на доступном им уровне. Включая и вас, и меня, и автора публикации.