Владимир Крылов, профессор математики, научный консультант Artezio и один из самых глубоких русскоязычных экспертов по применению ИИ в разработке, дал интервью по итогам года. Мы поговорили о том, почему reasoning-модели галлюцинируют вдвое чаще обычных (и это математически неизбежно), почему OpenAI объявил «код красный» и отстаёт от Google, и правда ли, что программисты, умеющие писать код только руками, скоро вымрут как вид. Спойлер: Паваротти не умел читать ноты, и это кое-что говорит о будущем vibe-coding.
Владимир Крылов регулярно проводит лекции о практическом применении LLM в разработке на канале Ai4dev. Если хотите разобраться в теме глубже, чем позволяет это интервью в блоге ЛАНИТ, подписывайтесь.
Сооснователь Anthropic Джек Кларк высказал идею, что агентная модель себя не оправдала и теперь надо разворачиваться в сторону универсальных моделей, которые при полной передаче знаний смогут выдавать лучший результат по запросам и генерации кода. Что вы об этом думаете?
Я не до конца понял, что Кларк имеет в виду, потому что агентная модель как таковая никуда не исчезает. Вопрос в том, что удачная передача навыков, сконцентрированных в одной языковой модели, может превращать её в разнонаправленного эксперта. Агент при этом всё равно останется агентом.
Сегодня в большинстве задач, которые формулируют разработчикам, мы встречаемся с узконаправленными требованиями: сортировка писем, отправка чего-то. Навыки такого «работника с электронной почтой» могут быть достаточно хорошо представлены в виде контекста для большой универсальной LLM, и после этого она превратится в этого самого сортировщика почты. По существу, глава Anthropic призывает: возьмите наших «Клодов», возьмите наши большие модели, просто передайте им нужные навыки, и агенты превратятся в хороших экспертов для выполнения вашей задачи.
Здесь играет роль и то, что разработки начали расползаться по локально развёрнутым системам. Вошли в моду малые LLM — те, которые можно развернуть on-premises: у себя дома, на предприятии. Смысла платить за использование больших моделей становится меньше. Чтобы не терять долю индустрии этих сверхгигантских дата-центров, наверное, и сделано это превентивное высказывание: не забывайте, что все ваши задачи решаются с помощью больших моделей, развёрнутых в гигантских дата-центрах BigTech. Вот у меня пока такое впечатление. Посмотрим, что будет дальше, но, на мой взгляд, это просто привлечение внимания к подпискам.
Сейчас мы видим, что инвесторы начинают потихоньку разочаровываться в OpenAI и замечают потенциал в моделях Google. Появляются сообщения, что в OpenAI объявили «код красный» и им надо срочно выпускать новые модели. Что происходит на рынке? Как бы вы могли объяснить эту суету и спешку с выпуском моделей? К чему она может привести?
Я не специалист по рынку и маркетинговым приёмам. Понятно, почему в OpenAI «код красный»: действительно ускоряется разработка новых моделей, а из-за отсутствия каких-то радикально новых идей в архитектуре и методах обучения OpenAI просто отстаёт. Возьмем ту же GPT-5: всем ясно, что это, по сути, дообученная модель GPT-4.5. Причина этого отставания мне непонятна, но похоже, что после ухода Суцкевера в OpenAI стало туго с новыми идеями.
Зато Google открыл дорогу для широкого развёртывания дата-центров на TPU — Tensor Processor Unit. Google является хозяином, изобретателем, разработчиком и тем, кто задаёт моду. Сегодня Google может даже обойти GPU от Nvidia, потому что использует более тонкие настройки и возможности низкоуровневого программирования TPU.
Опыт DeepSeek показал: можно, не имея высокопроизводительного GPU, благодаря новым методам обучения и тщательному конструированию новых ядер CUDA, получить прирост в производительности, фактически компенсирующий недостатки железа. Сэм Альтман сказал, что у OpenAI «красный код», потому что Google может сделать серьёзный рывок вперёд со своей следующей моделью благодаря стечению обстоятельств с TPU. А у OpenAI ещё не развёрнуто достаточное количество мощностей, компания увлеклась бизнесом и отстала. Альтман буквально в этом признался: концентрация усилий на бизнес-решениях, на увеличении проникновения ChatGPT отвлекла OpenAI от разработки новых рискованных решений.
«Галлюцинация в LLM — это не дефект архитектуры»
Последние исследования показывают, что даже новейшие решения вроде последних моделей OpenAI демонстрируют достаточно высокий уровень галлюцинаций — около 33%, что вдвое выше, чем у предшественников. На Хабре и Reddit это одна из самых обсуждаемых проблем. Подскажите, как математик вы могли бы объяснить, почему галлюцинация — это не баг, а математическое следствие архитектуры трансформеров? Существует ��и теоретический предел, ниже которого уровень галлюцинаций не опустится никогда?
Хороший вопрос. К счастью, недавно было опубликовано несколько работ, где именно с точки зрения математики разбираются эти проблемы. То, чем я в своё время занимался, очень тесно совпадает с тем, что было опубликовано.
Галлюцинация в LLM — это не инженерный артефакт, не дефект архитектуры и не следствие архитектуры трансформеров. Здесь сходятся особенности обучаемых моделей вообще. Есть не просто вычислительные проблемы — сам механизм attention представляет собой структуру, которая неизбежно содержит появление этих галлюцинаций. Существуют статистические ограничения, которые не преодолеют ни одна текущая архитектура, масштаб или оптимизация.
Это уходит куда-то в абстрактную математику. Возьмём функции как математический объект — например, функции, которые отображают множество целых чисел в множество целых. Множество таких функций континуально, а вот множество вычислимых функций счётно. Как говорится в математике, мера множества всех вычислимых функций равна нулю на множестве всех существующих.
Мы почти никогда не задаём себе неудобный вопрос: а что, если здесь в ИИ существенную роль сыграют невычислимые функции — те, для которых не существует машин Тьюринга, то есть их нельзя реализовать кодом ни на каком компьютере? Похоже, именно к этому мы и подошли.
Авторы одной из последних работ на эту тему доказывают теорему: для любого вычислительно перечислимого множества всегда найдётся такая последовательность, такой вход для LLM, на котором модель неизбежно ошибётся и не выдаст правильного ответа. Важно, что это утверждение не привязано к конкретной архитектуре или «параметрам побольше». Оно относится к самому виду задачи: к отображению (функции) из множества целых чисел в целое число — и к фундаментальным пределам вычислимости.
А вот что касается 33–48% галлюцинаций у новых моделей, здесь имеет место так называемый парадокс рассуждений. Обратите внимание: именно модели рассуждений, reasoning-модели, дали такой большой процент. Проблема здесь уже другая. Когда начинаются рассуждения, LLM упирается в генерацию огромного количества предложений, а мы в обучении пытаемся это ограничить.
Здесь мы приходим к новой проблеме, которая существует в теории обучения. В ней было показано, что такое VC-размерность при обучении и какая граница существует для приближения решения задачи методом обучения. Эта граница проявилась именно при использовании reasoning. Нет reasoning — и всё становится лучше.
Что же из этого следует? Известно одно: если вы вводите аугментацию, например, RAG, дополнительные инструменты, данные, которые привязывают к текущему решению задачи тот промпт, который вы подали во входное контекстное окно LLM, то вероятность галлюцинации резко снижается. Возьмите Gemini 2 Flash — 99,3% правильных решений, галлюцинации 0,7%. GPT-5 — 99,1%, GPT-4o — 98,5%. Когда вы отключаете режим рассуждений, вы уменьшаете частоту галлюцинаций. Плюс, когда вы используете дополнительные конкретные знания, относящиеся к вашей задаче, вы получаете резкий эффект уменьшения галлюцинаций.
Сегодня, на мой взгляд, все чаще понимают, что галлюцинация — это неотъемлемая характеристика, а не ошибка, требующая устранения. Отрасль признала, что нужно переходить к так называемой «калиброванной неопределённости» — когда системам обязательно вкладывают в обучающий контекст и алгоритмы способность сообщать, когда они чего-то не знают. Таким образом мы приходим к выводу: будем знать, сколько процентов галлюцинаций мы допускаем для этого типа задач. Иначе модель будет просто сообщать: «Я не знаю». Сегодня она так практически не говорит. Вы редко можете добиться от LLM признания «этого я не знаю».
Есть специальные датасеты, например PersonQA, позволяющие задать вопросы про конкретного человека. И вдруг LLM начинает изобретать то, чего никогда не было известно об этом человеке. Почему? Потому что она пытается ответить на вопросы как можно лучше, исследо��ать все возможные варианты и придумывает какой-то вариант. Тест на PersonQA подтверждает, что все модели на своём внутреннем знании всегда будут давать ошибку. Эта ошибка, как я уже сказал, не подлежит устранению. Она является неотъемлемым свойством обучаемых моделей вообще.
Одна из главных претензий — LLM не способны работать с большими кодовыми базами, не учитывают глобальный контекст проекта. При этом контекстные окна растут: у Gemini 2.5 Pro уже был миллион токенов. Почему увеличение контекстного окна не решает проблему архитектурного понимания? Это принципиальное ограничение или вопрос времени?
Конечно, такая претензия существует, но что значит «не может работать с большими кодовыми базами»? Зависит от того, как вы подходите к разработке. Если вы пытаетесь применить vibe-coding к работе с большой кодовой базой, то столкнетесь с ограничениями. Здесь два основных ограничения: архитектурное и вычислительное.
Контекстное окно сегодня может достигать миллиона токенов, и, казалось бы, мы можем погрузить туда большую кодовую базу. Но смотрите, что получается: объём вычислений при квадратичной реализации механизма attention приводит к тому, что если кодовая база содержит миллионы строк и тысячи файлов, то даже в окно с миллионом токенов они полностью не поместятся. Когда же они туда не помещаются, возникает смысловой, семантический разрыв — модель работает фрагментарно, обрабатывает локальные куски. А файлы, которые имеют влияние, но не попали в контекстное окно, оказываются в стороне. Человек-разработчик знал, что у него есть зависимость, а LLM эту зависимость просто не видит из-за attention. Из-за этого возникает множество проблем: кажется, что код содержит ошибки или написан как-то не так, имеет лоскутный характер.
Есть ещё архитектурная проблема — она называется «потерянный в середине». Механизм внимания работает так, что на вычисление коэффициентов attention наложена U-образная кривая: последние и первые токены учитываются, а токены в середине окна теряют внимание. Когда релевантный код находится в начале или конце, он отлично работает. Но если важные связи кода попадают в середину контекстного окна, проявляется проблема.
Понимание кода на уровне целого репозитория требует понимания межфайловых зависимостей, взаимодействия модулей, отношений импорта, соглашений. LLM с такими сложными связями сегодня работают плохо. Как только генерац��я кода произойдет с учётом некого локального файла, появляется проблема: начинается итеративный процесс тестирования и генерации, захватываются другие фрагменты, ошибка может начать распространяться вместо того, чтобы итеративно сойтись к нулю.
Когда вы пытаетесь весь большой репозиторий подвергнуть vibe-coding, так и получается, к сожалению. Сегодня стратегия снижения рисков обычно такая: нужно хранить не только полный репозиторий, но и его сжатый вариант — такие сжимающие кодеры постоянно совершенствуются. Можно также организовать RAG из кодовой базы. Если аккуратно сделать индексирование, то чередование между RAG и полной кодовой базой, как правило, гораздо быстрее сводится к регулярному качественному кодированию. Также рекомендуется специальным образом фрагментировать проект на составляющие и работать с законченными конструкциями, объединение которых даст лучший результат, чем работа с полной кодовой базой.
На Хабре опубликован детальный разбор auth-библиотеки, созданной Claude, где найдены многочисленные security-уязвимости: захардкоженные пароли, вложенные функции, неправильная реализация аутентификации. Почему модели систематически генерируют небезопасный код, несмотря на огромные обучающие датасеты? Это проблема данных или самой архитектуры обучения?
Честно говоря, я эту статью видел, и смысл там не совсем такой, как вы сформулировали в вопросе. Обратите внимание на заключение автора. Он пишет: «Для первой попытки создания библиотеки auth результат неплохой». Автор отмечает, что пока не рекомендовал бы использовать эту библиотеку. Ссылка только одна: «По моему опыту, очень сложно создать корректную и безопасную реализацию провайдера auth. И эта задача определённо требует больше времени и внимания, чем было потрачено на эту попытку. Пока».
Вывод не в том, что «модели систематически генерируют небезопасный код». Это тоже относится к ошибкам, с которыми вы встречаетесь, но тут целую библиотеку сгенерировали — специальную для авторизации. Мне кажется, это, наоборот, серьёзная демонстрация возможностей — пустить LLM туда, где идёт генерация критически важных фрагментов кода.
«Образование необязательно для эффективного использования LLM»
На Reddit сейчас активно обсуждают, стоит ли вообще начинающим учиться программировать с помощью LLM. Опытные разработчики предупреждают, что новички, полагаясь на искусственный интеллект, пропускают критические этапы: структурирование кода, отладку, исследование проблем. Что вы как профессор математики думаете о vibe-кодерах без реального понимания? Это угроза для профессии или естественная эволюция?
А все ли талантливейшие музыканты, которые известны, имели «реальное понимание», структурирование? Например, Лучано Паваротти, легендарный оперный певец, вообще не умел читать ноты. Есть воспоминания дирижёра Ричарда Бонинга: «Паваротти никогда не учился и не умел читать музыку. Всё разучивал на слух». Да что говорить, Виктор Цой вообще не имел профессионального музыкального образования. Фрэнк Синатра никогда не умел читать ноты, учился на слух.
Мы часто не сверяем выводы с историческим опытом человечества. Если утверждать, что красота и эффективность кода никак не связаны с дисциплиной структуры — той самой, которой нас учили «по-школьному», — то логика приведёт к простому выводу. Одним полезно изучать «музыкальную грамоту» (основы, правила, сольфеджио), а другим, чтобы стать выдающимся программистом, это может и не понадобиться. Большая языковая модель способна резко ускорить такой путь. Она позволит быстро продвинуться вперёд и получать качественный результат в режиме vibe-coding.
Владимир Владимирович, я слышал мнение, что классическое образование в программировании мешает использовать LLM. Вы не встречались с таким?
Нет, я так не думаю. Мне кажется, что оно необязательно для эффективного использования LLM. Когда-то раньше считали, ��акой ты программист, если шестнадцатеричную систему исчисления не знаешь? А кто сейчас активно использует шестнадцатеричную систему из наших ребят-программистов?
Разработчики жалуются, что 45% времени уходит на исправление кода, который LLM сгенерировала «почти правильно». Модели часто применяют оборонительное программирование вместо решения корневых причин. В чём математическая природа этой «почти правильности»? Почему модели систематически выбирают заплатки вместо архитектурных решений?
Я уже немного говорил об этом. Архитектурное решение требует целостного рассмотрения проекта, а при серьёзных проектах мы даже не можем весь проект загрузить в контекстное окно LLM. Если проект построен на глубоких взаимосвязях, получается, что модель пишет фрагментарными у��астками код качественный, но не учитывающий вещи, относящиеся к отдалённым частям. Ведь когда вы создаёте репозиторий, вы не думаете о том, как он будет загружаться в окно, не пытаетесь это учесть. Вот и получаются заплатки — каждая из них хороша, а в целом проект выглядит «не по-человечески». Одна из главных причин — именно в работе с очень большими проектами.
Какие модели сейчас наиболее перспективны для разработки ПО? Кто в лидерах? Как будет развиваться гонка дальше?
Дело не в самой модели как таковой. Среди моделей лидеры известны. Сегодня интересны именно находки, превращающие модель в соответствующего агента — например, Claude Code или Cursor. Многие указывают на перспективность новых китайских разработок. Но это все не просто изолированная модель, с которой вы один на один работаете, как с ChatGPT. Вы работаете с системами разработки, с агентами, интеллектуальными IDE. Если говорить о том, что в этом агенте можно менять LLM и смотреть результат, то, судя по всему, Anthropic сегодня создаёт наилучшие для кодирования модели. Когда их включают практически в любого достаточно совершенного агента, качество генерации кода оказывается выше.
«Прогресс всё сильнее смещается в сторону аугментации человеческого промпта»
А почему не все конкурирующие модели могут достичь одинакового результата? Почему у кого-то бывают прорывы, у кого-то — нет?
Законы масштабирования LLM исчерпали свои возможности, и все начинают это осознавать. Однако сделать сколько-нибудь радикальные шаги в архитектуре LLM пока не удаётся, хотя и здесь появляются многообещающие результаты. Зато как только вы начинаете применять tool use, модель приобретает колоссальные возможности. Когда она превращается в агента с инструментами, вы получаете результаты гораздо лучше, в том числе при разработке софта. Если даёте хорошие инструменты, агент позволяет построить гораздо лучший код, чем «голая» модель.
Почему модели не станут одинаково хороши в роли одного и того же агента? Казалось бы, инструменты одни и те же, память та же, а результат у одной заметно хуже. Потому что модели обучены по-разному.
Во-первых, различаются архитектурные и инженерные решения — особенно вокруг attention. Одни команды экспериментируют с Linear Attention и родственными подходами, чтобы уйти от квадратичной стоимости и эффективнее «тратить» токены на рассуждение. Это даёт скачок, но параллельно другой разработчик может выстрелить за счёт нового режима reinforcement learning, и внезапно именно он окажется впереди по качеству.
Во-вторых, всё более популярны нативные механизмы вызова инструментов: модели не нужно указывать формат — она умеет вызывать функции «из коробки». Но и здесь все обучают по-разному: качество работы с инструментами (как выбирать инструмент, как формулировать запрос, как проверять результат) становится отдельной осью, по которой модели расходятся.
Наконец, прогресс всё сильнее смещается в сторону аугментации человеческого промпта: модель дополняют планированием, оптимизацией промпта, расширением контекста промежуточными проверками. А если аугментация опирается на внешние источники знаний, в игру входит влияние разработчика: выигрывает не абстрактно «лучшая модель», а та, чья команда лучше продумала, чем и как именно подпитывать запрос.
Как вы считаете, модели будут долго оставаться энергозависимыми и ресурсозависимыми? Может наступить ситуация, когда модель не будет требовать таких ресурсов?
Это связано с тем субстратом, на котором модели строятся, — кремниевая основа с регистрами, памятью, GPU. С одной стороны, достаточно перенести архитектуру трансформера на другой субстрат — например, биологический или химический — и все энергетические характеристики существенно изменятся. Это одно направление.
Второе направление — по-другому организовать преобразование информации внутри. Обычно это называется созданием новых архитектур. Например, появился символический языковой процессор — LLM, которая внутри себя использует не просто токены с механизмом next token prediction, а работает непосредственно с уравнениями, символическими вещами. Ей совершенно очевидно, что такое x², тогда как объяснить это обычной языковой модели — довольно сложная задача. Раньше мы вызывали инструмент-калькулятор, и ошибки исчезали — те, которые так изводили, когда LLM не знала, сколько будет 5 + 17,5. А сейчас появляется архитектура, где внешний инструмент не нужен, он реализован внутри. Мы теперь знаем, какие инструменты нужны для высокоэффективной работы.
Здесь победы одного направления не будет — скорее всего, будет параллельное существование. Недаром Ян Лекун ушёл заниматься моделями физического мира. Он считает, что вообще всё неправильно — создавать знания на основе текстов и языка, их нужно создавать на абстракциях, описывающих физический мир. Я не могу с ним согласиться — это сильно ограниченный подход. Это один из инструментов, которым должна располагать модель, потому что мы сами не знаем этих абстракций. Пока вы думаете, что главное — куда упадёт молоток, выпавший из руки робота, вам хватает второго закона Ньютона. Но представьте, что он роняет квантовый молоток — вы не можете описать, что произойдёт. Знания человечества в основном развивались благодаря созданию письменного текста, поэтому отрицать языковые модели в пользу физических моделей мира было бы совершенно неверно. Хотя это должно присутствовать рядом, внутри, вместе.
Почему LLM так плохо переносят знания между доменами? Мы учим их всему подряд, а они ведут себя так, будто каждый новый проект — первая встреча с реальностью.
У каждой LLM есть параметрические знания, зашитые внутри весов. Здесь ничего не меняется от задачи к задаче — она одинаково «образована». Сегодня мы дополнили LLM внутренней памятью агента. Эффективно работать с этой памятью ещё не умеют. Когда строите мультиагентную систему, вы, как правило, зашиваете стратегию работы с памятью внутрь. Но в самой LLM управление памятью пока рассматривается просто как инструмент — оно несовершенно.
В RAG существует масса проблем с релевантностью отдельных чанков, которые возвращаются во время retrieval, потому что не хватает способности семантического анализа для правильного определения адекватных документов. Здесь много проблем, которые будут разрешаться по мере развития. Проблема, которую вы обозначили, будет постепенно решаться, потому что память сегодня не является органической частью LLM.
«Видеть новое и не бояться его применять очень важно для программиста»
В 2024 году вы написали на Хабре, что будут созданы другие рабочие места, требующие иных умений и знаний, связанных с LLM. Какие именно умения станут ключевыми для программистов через 3–5 лет? На что делать ставку молодому специалисту?
Я, конечно, не пророк и не могу сказать, какие умения станут ключевыми через 3–5 лет. Знаю одно: молодой человек, вступающий на стезю разработки информационных систем, не должен быть консерватором. Он не должен упираться в существующие методики и воспринимать всё новое с позиции «ничего нового под Луной, всё, что было, то и завтра будет». Видеть новое и не бояться его применять — очень важно для программиста.
Насколько мы близки к тому, что LLM заменят программиста совсем? Это самый спорный и болезненный вопрос.
Мне кажется, LLM в нынешнем виде не станут полноценной заменой человеку. Скорее, появится иной класс систем, который возьмёт на себя эту роль. Вполне возможно, что значительная часть задач разработки ПО будет решаться автономно, практически без участия человека.
Если смотреть шире и допустить, что мы — лишь один из исторических этапов цивилизации и однажды передадим эстафету дальше (если, конечно, не успеем уничтожить себя раньше), то да: продолжат уже «они» — не люди, а кто-то совсем другой. Но это будут не LLM — по крайней мере, не в том виде, в каком мы понимаем их сегодня.
Как вы отно��итесь к идее самопишущихся программ, самовосстанавливающихся систем, которые сами себя могут чинить и дорабатывать? Это действительно тренд или мы говорим о далёком будущем?
Почему же? На канале Ai4Dev у меня уже есть лекция о саморазмножении LLM. Я достаточно детально рассмотрел этот вопрос — он во многом касается того, о чем вы спрашиваете. Самосовершенствование как мутация при размножении вполне проходит.
А LLM способна эволюционировать самостоятельно, без участия разработчиков?
Сейчас есть LLM, работающие в режиме continuous training. Они всё время обучаются, эволюционируют.
Тогда почему сверхразум, универсальный интеллект не появился? Мы только о нём говорим уже который год. Почему LLM застопорились в показателях? Неужели маркетинг задушил научную часть?
Он не задушил прогресс — скорее, заставил индустрию активнее перераспределять ресурсы в пользу быстрого, измеримого практического результата. Как говорил Сэм Альтман, фокус смещается туда, где можно показать эффект здесь и сейчас.
Достаточно посмотреть на то, что происходит с бенчмарками. Все бросились придумывать метрики вроде GDP Vault, т. е. попытки измерить вклад конкретной LLM в валовой продукт, буквально «прибавку к ВВП». В таких оценках фигурируют десятки профессий и крупнейшие сектора экономики, которые дают основную долю ВВП. Задачи формулируют и проверяют профессионалы с опытом от 15 лет — и именно они в итоге будут «ставить оценку» той или иной модели.
Вспоминается формулировка, которую я помню в пересказе (кажется, её приписывают Сатье Наделле): общий искусственный интеллект появится тогда, когда модель начнёт приносить 100 млрд долларов дохода. Видите, как мы разворачиваемся от научных вопросов и аккуратных определений? Вместо «что такое AGI» получается «сколько он приносит». Заработало 100 млрд — значит, объявляем: вот он, общий интеллект. Экзамен по философии отменяется, бухгалтерия зачёт поставит.
Опытный разработчик с двадцатилетним стажем пишет на Хабре, что vibe-coding имеет негативные когнитивные последствия — теряется что-то важное, когда программист перестаёт писать код руками. Это страхи или реальная угроза? Люди разучатся думать?
Мне кажется, теряются программисты, которые умеют писать код только руками. Вот такие программисты перестанут быть программистами.
Я с удивлением прочитал один серьёзный отчёт в «Российской газете»: каждый пятый россиянин сегодня считает, что Солнце вращается вокруг Земли. Опросы проводил Институт психологии РАН. 16% опрошенных не сомневаются, что люди и динозавры жили в одно время. При этом 90% респондентов не смогли назвать ни одного ныне живущего российского учёного мирового уровня. 39% верят в существование ведьм и колдунов, 34% — в то, что экстрасенсы могут предсказывать будущее.
Вот такие вопросы совершенно естественны. Часть людей, которые думают, что люди и динозавры жили в одно время, могут говорить: нет, нельзя, все обязательно должны понимать, как написать код руками. Но стоит ли учиться писать код руками для компьютера CL1 — в одной из лекций я рассказывал о больших проектах на биокомпьютерах, где используются живые нейроны. Что толку от того, что программист умел писать код для кремниевых процессоров, если теперь надо работать на CL1? Он должен освоить новое, приспособить LLM к тому, чтобы генерировать код для этой платформы через симуляцию субстрата.
Ваш прогноз на 2026 год. Чья LLM станет лучшей? Давайте сделаем ставку, а потом сверим в следующем интервью.
Не делаю ставки ни на лошадей, ни на людей.
Но я скажу вам другое, и это, пожалуй, и есть прогноз. Сам вопрос «чья модель лучше» через год-два скорее всего потеряет смысл. Мы уже сейчас видим: разница между топовыми моделями на большинстве практических задач — проценты, иногда доли процента. Лидерство переходит от одной компании к другой каждые несколько месяцев. Сегодня Anthropic впереди в кодинге, завтра Google сделает рывок на TPU, послезавтра появится какой-нибудь новый DeepSeek и всех удивит.
Понимаете, гонка моделей — это как гонка процессоров в 90-е. Все следили: Intel или AMD, сколько мегагерц. А потом оказалось, что важнее — какой софт вы на этом запускаете, какую экосистему вокруг построили. То же самое происходит сейчас. Победит не тот, у кого модель на полпроцента лучше на каком-нибудь бенчмарке, а тот, кто создаст лучшую экосистему агентов, лучшую интеграцию с инструментами разработчика, лучший developer experience.
Если хотите мой совет — не утруждайте себя постоянным отслеживанием того, кто «победил» в очередном рейтинге. Следите за тем, как меняется ваша собственная продуктивность с разными инструментами. Попробуйте Claude Code, попробуйте Cursor, попробуйте что-то ещё через полгода. Ваш личный опыт — это единственный бенчмарк, который имеет значение.
А что касается 2026 года… Я думаю, мы будем обсуждать совсем другие вопросы. Не «чья модель лучше», а «какой агент лучше решает мою конкретную задачу». Ответ будет зависеть не от названия компании в заголовке, а от того, как этот агент настроен, какие у него инструменты, какой контекст вы ему дали. Вот это и есть настоящий сдвиг, который произойдет. Модель станет commodity как электричество из розетки. Никто же не спрашивает, с какой электростанции у вас ток. Важно, что вы с этим током делаете.
Так что ставок не делаю. Но с удовольствием обсу��у через год, насколько я оказался прав или неправ в этом предсказании.
Автор: Artezio_team
