Где именно эксперимент цепляет
Я люблю такие тесты не за хайп, а за неприятную честность. Берут около 80 задач по программированию, дают их моделям в двух обёртках: нормальный Python и тьюринг-полные эзотерические языки. На Python выходит что-то вроде 85-95% успеха, а на эзоязыках — жалкие 0-11%.
И вот тут у меня не случилось шока. Скорее наоборот: цифры просто подсветили то, что я и так вижу в прикладной работе с кодогенерацией. Модель часто не «понимает задачу» в абстрактном виде — она уверенно едет по знакомым рельсам синтаксиса, паттернов и частых решений.
Если коротко, тезис такой: тьюринг-полнота сама по себе не спасает. Формально язык может уметь всё, что и Python, но для модели это вообще не значит, что она перенесёт навык. Вот это и есть неприятная часть истории про sample-efficient transfer — перенос знаний у трансформеров до сих пор довольно хрупкий.
Источник тут не академический, а скорее исследовательско-интернетный разбор вокруг идеи The Illusion of Thinking. Это важно проговорить честно: я бы не подавал это как окончательный приговор всей архитектуре. Но как стресс-тест на абстракцию — очень показательно.
Почему Python обманывает нас лучше, чем хочется
Я много раз видел, как команда смотрит на высокий процент в Python-бенчмарках и делает слишком смелый вывод: «ну всё, модель умеет программировать». Нет, она отлично статистически ориентируется в привычной экосистеме. Это полезно, но не тождественно мышлению.
Python — идеальная теплица для LLM. Огромный корпус кода, предсказуемые идиомы, масса однотипных задач, море документации и обсуждений. Модель там не просто сильная — она там дома.
А вот когда я выдёргиваю её из комфортной среды и прошу сделать что-то на необычном DSL, старом внутреннем языке правил или кривом конфиг-формате, магия резко тускнеет. Не потому что задача фундаментально сложнее, а потому что пропадает опора на знакомые шаблоны. Для меня это гораздо ближе к реальной жизни, чем очередной красивый Python demo.
Что это меняет в бизнесе и автоматизации
Для бизнеса вывод очень практичный: нельзя путать успешный copilot в знакомом стеке с универсальным reasoning-движком. Если у вас внедрение ИИ завязано на нестандартные процессы, внутренние DSL, легаси-системы или редкие форматы данных, риск недооценить хрупкость модели довольно высокий.
Я бы сформулировал правило так: чем дальше ваш контур от массового интернета, тем меньше стоит верить «средней температуре по бенчмаркам». Нужны свои eval-наборы, свои тесты переноса, свои ограничения на автономность агента. Иначе ИИ автоматизация будет выглядеть красиво в пилоте и неприятно в проде.
Кто выигрывает? Команды, которые строят AI-архитектуру с проверками, промежуточными представлениями, компиляцией в контролируемые шаги и жёсткой валидацией результата. Кто проигрывает? Те, кто пытается просто прикрутить модель к редкому доменному языку и надеется, что она «сама разберётся».
Мы в Nahornyi AI Lab с таким сталкиваемся регулярно, когда идёт разработка ИИ решений для внутренних процессов, а не для красивых демо. Если домен узкий, я почти всегда закладываю слой нормализации: сначала перевод задачи в более устойчивое представление, потом генерация, потом автоматическая проверка. Это не так романтично, зато работает.
Мой вывод без лишней драмы
Я бы не кричал, что «модели не умеют думать вообще». Это слишком дешёвая формула. Но я точно сказал бы иначе: их способность к переносу знаний сильно переоценена, особенно когда мы смотрим на привычные языки и удобные бенчмарки.
Если вы планируете внедрение искусственного интеллекта в код, ops или внутренние инструменты, держите в голове простой вопрос: модель решает мою задачу или угадывает знакомую форму задачи? Разница между этими двумя сценариями потом превращается либо в экономию месяцев, либо в очень дорогую иллюзию.
Этот разбор написал я, Вадим Нагорный, в Nahornyi AI Lab. Я руками собираю ИИ интеграции, агентные пайплайны и автоматизацию с помощью ИИ там, где есть легаси, нестандартные данные и требования к качеству. Если хотите, я помогу трезво проверить ваш кейс и вместе понять, где у модели реальная сила, а где только уверенный фасад.