Пишем простой код - 19 сборок без рабочего результата, что показал практический тест GPT-5.6 Sol/Pro и GPT-6 Astra/Pro

Мы задались целью написать простой компонент в помощь студентам, работающим над рефератами, курсовыми работами и ВКР. Чего греха таить, идея — «поставьте GPT задачу и занимайтесь своими делами» — звучит соблазнительно. Разработчики GPT — компания OpenAI — полагают, что их детище, а именно последние версии 5.6 и 6 (модель Астра), на это способно. Как выяснилось, не способно: модели не смогли ни написать элементарный код, ни пройти тесты на когнитивную оценку — испытания в среде AGE вновь оказались провалены.

Практическое тестирование последних поколений GPT вышло за пределы оценки качества текста, результаты которого по наблюдениям 2 суток мы опубликовали. 9–10 сентября 2026 года модели использовались для разработки программного продукта KontrPlagiatMonitor. В зафиксированную серию вошли 19 версий, причём 16 сборок были выпущены только 10 сентября. Ни одна из них не обеспечила устойчивую работу основного сценария программы.

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

Особенно показательно расхождение между внутренними тестами и фактической работоспособностью. В версии 0.9.1 было заявлено 18 успешно пройденных проверок. К версии 1.1.8 их количество выросло до 87. Формально качество тестового покрытия увеличилось почти в пять раз. Однако конечный результат не появился: последняя сборка обнаружила 108 потенциальных Telegram-источников, квалифицировала ноль, не сформировала ни одного постоянного источника и не получила ни одного требуемого сообщения. Для 107 из 108 кандидатов зарегистрирована ошибка проверки типа источника.

Критические ошибки последовательных сборок KontrPlagiatMonitor

Версия Внутренние тесты Критическая ошибка, выявленная при эксплуатации
0.9.1 18 PASS Архитектура предусматривала внешний API и API-ключ, хотя рабочий режим требовал функционирования без внешнего API. Реальная авторизованная Telegram-сессия и фактический интерфейс пользователя перед выпуском не проверялись.
0.9.2 18 PASS В реальной работе Telegram не обнаруживалось поле поиска. Одновременно возникал критический конфликт Playwright Sync API с асинхронным циклом выполнения.
0.9.3 26 PASS Telegram, VK и GPT были разнесены по отдельным браузерным профилям. Реальная пользовательская браузерная среда оказалась заменена искусственно разделённой архитектурой.
0.9.4 29 PASS Переход к одному Chrome не устранил проблему: браузер по-прежнему управлялся через отдельный профиль и CDP, а не через обычную пользовательскую сессию.
0.9.5 31 PASS Google Chrome запускался, однако конечная точка CDP не становилась доступной. Программный браузерный слой фактически не подключался.
0.9.6 33 PASS Вместо устранения проблемы была создана очередная отдельная директория профиля Chrome. Сохранилась зависимость от специально запущенной браузерной среды.
0.9.7 34 PASS Был жёстко закреплён путь к chrome.exe, но Chrome снова запускался с новым отдельным профилем. Пользователь получал фактически пустой браузер без обычной рабочей среды и авторизаций.
0.9.8 37 PASS Отсутствовал жёсткий локальный фильтр перед передачей результатов в GPT. В модель уходили нерелевантные данные, вкладки перехватывали фокус, а для кандидатов создавались лишние диалоги ChatGPT.
1.0.0 39 PASS Глобальный поиск Telegram был отключён, а список разрешённых источников оказался пуст. Результат — scan.no_sources и фактическое отсутствие работы основной функции.
1.0.1 42 PASS Система по-прежнему могла работать только с заранее вручную добавленными источниками. Автоматического обнаружения требуемых каналов не существовало.
1.1.0 50 PASS Авторизованный Telegram ошибочно определялся как разлогиненный из-за присутствия скрытых элементов входа и QR-авторизации. Поиск прекращался.
1.1.1 52 PASS Исправление разлогинивания оказалось неполным. Дополнительно возникали зависания команд Bridge и проблемы жизненного цикла служебной вкладки.
1.1.2 56 PASS После замены вкладки продолжал использоваться старый tab ID, что давало No tab with id. Одновременно применялся неверный селектор глобального поиска Telegram.
1.1.3 59 PASS Программа искала поле глобального поиска до фактического открытия поисковой панели. Кроме того, локальные чаты и глобальная выдача некорректно различались по структуре страницы.
1.1.4 63 PASS Обычный программный клик по значку поиска не обеспечивал открытие Global Search в фоновой вкладке Telegram. Основной поиск оставался нестабильным.
1.1.5 77 PASS Планировщик доверял старым временным меткам, созданным предыдущими дефектными версиями. Все запросы могли считаться недавно выполненными, поэтому запуск завершался с queries: 0.
1.1.6 82 PASS Реальная секция глобального поиска была открыта и содержала результаты, однако парсер отвергал её из-за текста заголовка «Глобальный поиск ещё» вместо точного совпадения «Глобальный поиск».
1.1.7 83 PASS Один поисковый запрос порождал длинную последовательность повторных Bridge-команд. Зафиксированы command_timeout, потеря вкладки и ошибка No tab with given id.
1.1.8 87 PASS Поиск уже обнаруживает кандидатов, но следующий слой практически полностью их уничтожает: 108 кандидатов, 107 отклонений при проверке, 0 квалифицированных источников, 0 постоянных источников и 0 найденных требуемых сообщений.

Эта последовательность показывает характер проблемы значительно точнее, чем единичный пример неработающего кода. За два дня отказ перемещался практически по всей архитектуре продукта: от выбора способа взаимодействия с GPT и браузером к управлению Chrome, профилями и CDP, затем к фильтрации сообщений, обнаружению источников, распознаванию авторизации Telegram, управлению вкладками, селекторам интерфейса, открытию глобального поиска, планировщику запросов, синхронизации Bridge, разбору поисковой выдачи и, наконец, проверке найденных источников.

При этом практически каждый новый релиз сопровождался положительным внутренним отчётом. Количество успешных автоматических проверок последовательно выросло с 18 до 87, но реальный пользовательский сценарий продолжал разрушаться.

Системные циклы критических отказов

Системная проблема Версии Наблюдаемый результат
Браузерная архитектура 0.9.2–0.9.8 Несколько последовательных переделок браузерного слоя: отдельные профили, общий профиль, CDP, новый профиль, жёсткий путь Chrome и окончательный переход к обычному Chrome через расширение.
Поиск источников Telegram 1.0.0–1.1.8 Девять последовательных версий исправляли одну основную производственную функцию — автоматическое нахождение и обработку требуемых Telegram-источников.
Определение состояния Telegram 1.1.0–1.1.3 Авторизованная сессия ошибочно определялась как неавторизованная, затем возникали ошибки поиска элементов и состояния страницы.
Управление вкладкой и Bridge 1.1.1–1.1.8 Зависание команд, устаревшие идентификаторы вкладок, тайм-ауты и гонки состояния последовательно нарушали выполнение поискового цикла.
Разбор реального интерфейса 1.1.2–1.1.7 Селектор существовал не там, где его ожидал код; поиск не открывался; правильная секция отбрасывалась из-за дополнительного слова в заголовке; повторный опрос приводил к тайм-ауту.
Проверка найденных источников 1.1.8 После устранения предыдущих уровней отказ переместился на следующий этап: программа нашла 108 кандидатов, но 107 отклонила и не получила ни одного рабочего источника.
Расхождение тестов и эксплуатации 0.9.1–1.1.8 Все релизы проходили собственные автоматические проверки, однако последовательные реальные запуски обнаруживали критические ошибки основного сценария.

Именно последний пункт является центральным результатом эксперимента. Если бы речь шла просто о недостаточном качестве сгенерированного кода, количество ошибок должно было сокращаться по мере получения обратной связи. Здесь наблюдается другой процесс: ошибка устраняется локально, после чего следующий реальный запуск обнаруживает критический дефект в соседнем звене системы. Модель успешно оптимизирует код под собственные тесты, но не обеспечивает работоспособность полного процесса.

К версии 1.1.8 автоматический набор сообщает о 87 успешно пройденных тестах. Реальная среда одновременно показывает 108 найденных кандидатов, 107 ошибок их проверки, 0 квалифицированных источников и 0 итоговых находок.

То есть отдельные внутренние операции выполняются, а целевая функция продукта остаётся неработоспособной.

Эти результаты дополняют проведённое ранее тестирование GPT-5.6 Sol/Pro и GPT-6 Astra/Pro при работе с текстом. В предыдущих испытаниях уже фиксировались критические нарушения инструкций, потеря ограничений, ложная самопроверка и повторное возникновение запрещённых ошибок. Программирование позволило проверить ту же проблему на более объективном материале: результат здесь определяется не стилем и не экспертной оценкой текста, а тем, выполняет программа требуемую функцию или нет.

В результате два последних исследованных поколения GPT демонстрируют одну и ту же фундаментальную проблему: высокая способность производить большие объёмы внешне убедительного результата не превращается в способность гарантированно доводить задачу до работоспособного состояния. Для KontrPlagiatMonitor потребовалось 19 зафиксированных релизов, а основной сквозной сценарий всё ещё не был стабилизирован.

Рынок и практический результат

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

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

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

Итог испытания. Критерий состоит не в количестве написанного кода и не в количестве зелёных внутренних тестов. Критерий — способность получить функционирующее программное решение после получения полной информации о предыдущей ошибке. В серии из 19 зафиксированных версий этот критерий не выполнен.

Наиболее показательная цифра всего эксперимента — не 19 сборок и даже не 87 зелёных тестов последней версии. Это соотношение результата версии 1.1.8: 108 обнаруженных кандидатов, 107 ошибок их проверки, 0 рабочих источников и 0 итоговых находок. Именно оно демонстрирует разницу между формально успешно протестированным кодом и реально работающим программным продуктом.