У новому експерименті ютубера Tech With Tim шість топових великих мовних моделей отримали однаковий виклик: самостійно зібрати з нуля браузерний клон Mario Kart. Жодних підказок по ходу, однакові ассети, жорсткі обмеження на взаємодію і вимога — щоб гру можна було запустити одним кліком. Результат виявився водночас показовим і доволі тверезим щодо реальних можливостей LLM у складних дев-сценаріях.
У тесті брали участь Opus 4.8, Composer 2.5, Kimi 2.5, Gemini 3.1 Pro, Grok build 0.1 та GPT 5.5, усі — через середовище Cursor. Далі — як саме було організовано експеримент, що вдалося моделям, а де вони провалилися.
Жорсткі правила: один промпт, спільні ассети, нуль налаштувань
Щоб наблизити тест до реального робочого сценарію, умови були максимально уніфіковані й обмежені.
По-перше, усі шість моделей отримали один і той самий початковий промпт. Він містив «усі основні вимоги, stretch-цілі та різні речі, які потрібні», тобто опис базової ігрової логіки, бажані фічі й додаткові можливості. Формат — «one-shot»: один великий запит, без покрокового ведення моделі за руку.
Було дозволено лише один додатковий промпт у разі, якщо початковий результат виходив повністю непридатним. Другий запит формулювався максимально загально — на кшталт «зроби гру іграбельною» або «виправ, бо не працює» — без структурованого фідбеку чи детального опису помилок. Усього, таким чином, моделі могли отримати максимум два промпти.
По-друге, усі працювали в однакових технічних умовах. Використовувалися «ті самі налаштування»: для кожної моделі було виставлено максимальний рівень «thinking» і найшвидший доступний режим. Усі LLM отримали «точно ті самі ассети»: один і той самий набір спрайтів, маніфест, стилі, базову директорію проєкту. Моделі могли вільно обирати, як саме використовувати спрайт-листи, але вихідна структура файлів і ресурсів була однакова.
Окремою вимогою стала «zero-setup» архітектура. Кожна гра мала запускатися одним кліком — без додаткового білду, інсталяції залежностей чи ручних налаштувань. Фактично, мова йшла про статичну веб-гру, яку можна просто відкрити у браузері.
Нарешті, усі моделі запускалися паралельно в ізольованих оточеннях. Для замірів використовувався таймер-скрипт, який відстежував «скільки часу вони працюють, кількість файлів та кількість рядків коду». Це дозволило не лише оцінити іграбельність, а й подивитися на обсяг і швидкість генерованого коду.
Перший захід: зелений екран, зламані карти і один умовний переможець
Після першого промпта стало очевидно, що завдання виявилося непростим навіть для сильних моделей. Розкид якості був радикальний: від повністю порожнього екрану до відносно іграбельної гонки.
Opus 4.8 на першій ітерації «побудував нічого»: замість гри — зелений екран і помилка в консолі. Composer 2.5 так само видав зламаний стан із помилками в консолі, який не дозволяв грати.
Gemini 3.1 Pro принаймні згенерував щось, що виглядало як гра: таймер старту, рух, дрифт по пробілу. Але поведінка картів і фізика були «дуже зламаними», геймплей важко було назвати коректним.
Grok build 0.1 також запустився із звуком і візуальними елементами, але керування практично не працювало. Машинка могла «їхати крізь стіни», базових обмежень треку не було, тож відчуття гри руйнувалося.
Kimi 2.5 показав карту, але «нічого не відбувалося»: ані клавіатурні, ані мишачі події не реагували, тож гра фактично існувала лише як статичний екран.
Єдиною моделлю, яка з першого промпта видала справді функціональний результат, став GPT 5.5. У цій версії Mario Kart можна було рухатися, використовувати предмети, дрифтувати, заїжджати на траву зі зниженням швидкості, зіштовхуватися з іншими картами і навіть ловити снаряди від суперників. Фінішна лінія, щоправда, не обмежувала зловживання траєкторією — можна було просто перетнути її по діагоналі.
Водночас у GPT-варіанті була помітна серйозна вада: «він не використав жоден із ассетів, які були надані». Спрайт-паки й візуальний стиль, які задавалися у вихідному оточенні, модель фактично проігнорувала, зібравши власний мінімальний візуальний сет.
На цьому етапі ключовий висновок був доволі жорсткий: для більшості моделей «такий рівень застосунку в одному промпті виявився надто складним», особливо з огляду на роботу з ассетами та структурою представлення.
Другий шанс: «зроби це іграбельним» як стрес-тест на здатність виправлятися
Після невдалих перших спроб усі моделі отримали свій єдиний додатковий промпт — короткий опис проблем на кшталт «гра не грається» чи «занадто швидко», без технічної діагностики чи підказок щодо коду.
Для Opus 4.8 другий захід став проривом. Після доопрацювання результат «виглядав значно краще і фактично працював». Можна було обирати персонажа (наприклад, Тоада), з’явилися звукові ефекти, зіткнення з об’єктами, робота предметів, уповільнення на траві, дрифт за шифтом і коректний рух назад. Візуально й функціонально це виглядало «найкраще з усього, що було видно на той момент».
Composer 2.5 почав працювати, але нестабільно. Модель зменшила надмірну швидкість, додала мапу, базові метрики, однак в одному з тестів карт застрягав у піску й фактично не міг продовжити рух.
Gemini 3.1 Pro став дещо краще керованим: рух нормалізувався, предмети хоч якось працювали, але загальна якість все ще лишалася «досить зламаною» — далеко від очікуваного рівня Mario Kart.
Grok build 0.1 після другого промпта видав дивну картинку із сирими спрайт-листами на екрані, рухом персонажа і, ймовірно, можливістю підбирати предмети, але без зрозумілого інтерфейсу й чіткої логіки використання айтемів. Загалом це виглядало «дуже покрученим» варіантом гри.
Kimi 2.5 дещо змінив візуальне оформлення і додав елементів інтерфейсу, проте «рух все одно не працював»: клавіатурні скорочення не реагували, помилок у консолі не було, але гра лишалася неіграбельною.
GPT 5.5 у відповідь на прохання «полішів» фактично залишив гру такою ж, як і після першого промпта: повністю функціональною, із паузою по Escape, дррифтом, використанням предметів, але все так само без інтеграції наданого ассет-паку і без додаткових візуальних ефектів, на кшталт частинок чи розширеного аудіо.
Після цього другого кола стало зрозуміло, що лише дві моделі — Opus 4.8 і GPT 5.5 — видали по-справжньому придатні до гри результати. Решта залишалися або сирими, або функціонально обмеженими.
Час, обсяг коду і «повільний переможець»
Завдяки таймер-скрипту можна було детально розкласти продуктивність кожної моделі за кількома вимірами: час генерації, кількість файлів, обсяг коду і швидкість написання.
Gemini 3.1 Pro виявився найшвидшим: повна генерація тривала менше чотирьох хвилин. GPT 5.5 вклався приблизно в шість з гаком хвилин. Kimi 2.5 показав дуже схожий час, також близько шести з половиною хвилин. Composer 2.5 працював помітно довше, близько восьми з половиною хвилин. Grok build 0.1 затягнув процес до понад двадцяти хвилин, а Opus 4.8 став найдовшим — близько 23 хвилин.
При цьому Opus не просто витратив багато часу. Модель «навіть не почала писати жодного коду до приблизно сьомої-восьмої хвилини», причому був виставлений «максимальний режим мислення», як і для інших моделей із подібними налаштуваннями. Значна частина часу пішла, очевидно, на планування й підготовку внутрішньої структури.
За кількістю файлів та рядків коду Opus також опинився на першому місці. Саме він створив найбільший кодовий масив; далі йшли Kimi, Grok, Composer, GPT 5.5 і Gemini. Якщо ж рахувати «рядки коду на хвилину», найшвидшою виявилася Kimi, далі розташувалися Gemini, GPT 5.5, Composer, Opus та наостанок Grok.
Окремо було розраховано «нормалізований скоринговий показник швидкості», де якість результату множилася з урахуванням часу виконання. Навіть за такого підходу, коли повільні моделі отримують штраф, Opus «все одно вийшов на перше місце» за загальним підсумком — попри те, що GPT 5.5 впорався приблизно за третину, а фактично майже за чверть його часу.
Архітектура й якість: повноцінний рушій проти «мінімально придатної» гри
Остаточні висновки будувалися не лише на суб’єктивному відчутті іграбельності. Для об’єктивізації оцінки був використаний окремий AI-аналізатор коду, який пройшовся по результатах усіх шести моделей. Було запущено кілька різних моделей-оцінювачів, результати звірялися між собою, а потім коригувалися вручну, щоб уникнути випадкового перекосу.
У підсумку за загальним рейтингом Opus посів перше місце «з помітним відривом». GPT 5.5 опинився другим, Composer — третім, інші моделі розмістилися нижче.
Причина домінування Opus — у глибині та структурі створеного коду. Модель не просто «зробила гру», а фактично «згенерувала цілий ігровий рушій». Усередині проєкту з’явився набір Python-інструментів для аналізу ассетів, вирізання і коректного використання спрайтів. Логіка гри була винесена в окремі модульні файли, структура — максимально розділена, з чітко виділеними компонентами.
З погляду читабельності JavaScript-коду це, можливо, виглядало досить громіздко, але саме така модульність і чітке розбиття на складові стали ключем до високої оцінки коду.
GPT 5.5, своєю чергою, показав «хорошу архітектуру»: чисті файли, не надто великі, відносно «робастну» фізику, простий, але працюючий AI для руху картів. Декілька предметів були реалізовані коректно. Водночас він «не мав жодного з ассетів, які вимагалися», а також мінімально працював із візуальними ефектами та аудіо, не реалізувавши, наприклад, двигун частинок, повноцінний аудіо-рушій чи титульний екран на рівні, описаному в промпті.
Composer 2.5 з кожним критерієм виглядав «все слабше й слабше»: бракувало статистики, ассети використовувалися частково або некоректно, загальний рівень складності й глибини реалізації був відчутно нижчим.
Kimi 2.5 «написав масивну кількість коду, але не дав хорошого результату на виході». Grok build 0.1 витратив «дуже багато часу на роботу», але кінцевий продукт виявився одним із найгірших і найменш придатних до гри. Gemini 3.1 Pro згенерував «дуже швидко» приблизно п’ять JS-файлів, але це було далеким від повноцінної, продуманої гри з усіма зазначеними фічами.
Ключовий висновок із цього порівняння: коли завдання стає достатньо складним і багатокомпонентним, «моделі другого ешелону» можуть бути корисними для окремих задач, проте «реально не витягують» повний рівень складності застосунку, який очікується від фронтирних моделей на кшталт Opus чи GPT.
Обережні висновки: це не «коронація» однієї моделі
Попри доволі чітку ієрархію результатів, автор наголошує: «те, що показано, не є науковим тестом». Це один конкретний сценарій — створення середньої складності гри з мінімальною кількістю промптів і фіксованими обмеженнями в середовищі Cursor.
Тому результати не слід трактувати як універсальну рекомендацію «завжди використовувати лише одну модель». В іншому класі задач — від невеликих скриптів до бізнес-логіки аплікацій — розклад сил може бути іншим, як і пріоритети між швидкістю, вартістю й якістю.
Втім, експеримент дає кілька чітких орієнтирів. По-перше, фронтирні моделі на кшталт Opus можуть вигравати за якістю й архітектурою навіть тоді, коли працюють повільніше. По-друге, GPT 5.5 демонструє сильний баланс між швидкістю і практичною придатністю коду, хоч і може ігнорувати частину контексту, зокрема ассети. По-третє, для «важких» one-shot‑завдань на кшталт повноцінної гри «бюджетніші» чи менш потужні моделі виявляються помітно менш надійними.
Експеримент також показує, наскільки крихкими залишаються складні LLM-пайплайни: одну й ту саму задачу з чітко визначеним оточенням моделі розв’язують з абсолютно різною глибиною, стратегією та успіхом. У реальних командах це означає, що вибір моделі для складних dev-сценаріїв усе ще потребує не лише маркетингових порівнянь, а й власних «польових» тестів під конкретні задачі.