Генерация кода как тест на вменяемость
Я дал Gemma 4 26b простую задачу - написать классическую игру Breakout на Python с Pygame. Казалось бы, тривиально для модели, которая нахваливает свои способности в кодинге. Результат? Игра, где шарик проваливается сквозь платформу, счет идет в минус, а кирпичи отскакивают от невидимой стены. Это не просто баги - это системный сбой логики.
Тест проводился 2 апреля 2026 года на свежевыпущенной Gemma 4 26b Instruct через официальный API. Промпт был прост: "Напиши полную игру Breakout на Python с использованием Pygame". Никаких хитростей.
Шарик, который не хочет жить по правилам
Первая странность - физика столкновений. Gemma 4 генерирует код, где проверка столкновения шарика с платформой выглядит так:
if ball.rect.colliderect(paddle.rect): ball_speed_y *= -1
Логично? На поверхности да. Но модель забывает про одно - шарик должен отскакивать в зависимости от того, в какую часть платформы попал. Удар по краю должен отправлять его под углом, а не просто менять вертикальную скорость. В итоге получается предсказуемая и скучная механика, которую не стал бы писать даже студент первого курса.
Счет, который уходит в минус
Вторая ошибка еще смешнее. Логика подсчета очков:
За каждый разрушенный кирпич - 10 очков. Когда кирпичей не остается - уровень пройден. Но Gemma 4 добавляет странный блок:
if len(bricks) == 0: score -= 100
За что? Почему за победу игрок теряет очки? Модель не объясняет. В комментариях к коде - тишина. Создается впечатление, что Gemma 4 где-то видела подобную конструкцию (может, для штрафов?), и тупо скопировала ее без понимания контекста.
Кирпичи с призрачной коллизией
Третий момент - обработка разрушения кирпичей. Код выглядит работоспособным, пока не замечаешь отсутствие проверки на выход за границы списка. Когда шарик ударяет кирпич, тот удаляется из списка. Но цикл продолжает работать с исходным индексом, что при определенных условиях ведет к IndexError.
Это классическая ошибка новичка, которую ловят на code review. Gemma 4 26b должна знать лучше - у нее же 26 миллиардов параметров и тонны обучающих данных с GitHub. Или нет?
| Ошибка | В чем проблема | Опасность для продакшена |
|---|---|---|
| Неправильная физика отскока | Шарик всегда отскакивает вертикально | Высокая - игра неинтересная |
| Штраф за победу | Логическая ошибка в подсчете очков | Критическая - ломает геймплей |
| Ошибка индексации | Возможный IndexError при удалении | Средняя - краш при определенных условиях |
Почему это важно за пределами Breakout
Можно сказать - да кому нужна эта Breakout в 2026 году? Но дело не в игре. Дело в том, что если модель путается в простой детерминированной логике, что будет с бизнес-приложениями?
Представьте: Gemma 4 генерирует код для банковского перевода. И добавляет туда balance -= amount * 2 потому что где-то видела подобный паттерн для комиссии. Или для медицинского софта путает условия. Страшно?
Это не теоретическая угроза. В прошлом месяце мы тестировали Gemini 2.5 Pro на legacy-коде - та модель хотя бы пыталась анализировать контекст ошибки. Gemma 4 же выдает уверенный, но неправильный код.
Что не так с обучением?
У меня есть теория. Google тренировал Gemma 4 на огромных объемах кода, включая учебные примеры и проекты с ошибками. Модель научилась генерировать синтаксически правильный Python, но не научилась отличать работоспособную логику от битой.
Она видела в датасете код начинающего разработчика, который сделал штраф за победу - и запомнила этот паттерн как "вариант обработки конца уровня". Без понимания, что это ошибка.
Интересно, что в мультимодальных задачах Gemma 4 показывает себя лучше - понимание аудио реализовано качественно. Но чистый код - слабое место.
А что с другими задачами?
Я проверил Gemma 4 на других классических алгоритмах - сортировках, поиске пути, парсинге JSON. Результаты лучше, но странности остаются. Например, при генерации быстрой сортировки модель иногда добавляет лишнюю рекурсивную ветку, которая замедляет алгоритм в 2 раза.
Для сравнения: FunctionGemma 270M, хоть и крошечная, но специально обучена для вызова инструментов - дает более стабильные результаты в своей узкой области.
Что делать разработчикам?
Если вы планируете использовать Gemma 4 для генерации кода в 2026 году:
- Не доверяйте слепо. Каждая строка - под подозрением.
- Тестируйте на простых кейсах вроде Breakout, прежде чем пускать в продакшен.
- Используйте вместе с другими моделями для ревью - одна найдет ошибки другой.
- Помните про возможные уязвимости - если модель ошибается в коде, она может ошибаться и в безопасности.
Будущее с дырой в логике
Google обещает исправить проблемы в следующих патчах. Но фундаментальная проблема остается: как научить модель не просто копировать паттерны, а понимать семантику кода?
Пока что, если хотите запускать Gemma 4 локально для экспериментов - инструкции есть здесь. Только не удивляйтесь, если ваша Breakout будет работать... оригинально.
Мой прогноз? К середине 2027 года мы увидим Gemma 5 с исправленной логикой. А пока - проверяйте каждый сгенерированный if. Даже если его написала модель с 26 миллиардами параметров.
