Автор каналу Tech With Tim поставив шести популярним мовним моделям однакове завдання: з нуля зібрати Mario Kart‑подібну гру в Cursor за один промпт (з можливістю одного короткого доопрацювання). Після того, як усі агенти відпрацювали в однаковому середовищі з однаковими ассетами, він порівняв не стільки «магію ШІ», скільки суворі метрики: час виконання, кількість файлів і рядків коду, архітектуру та ігровий результат.
Цей тест не претендує на повну науковість, але добре показує, як різні LLM поводяться в середньо-складному реальному сценарії, де важить не лише швидкість генерації, а й те, чи є в результаті взагалі що запускати.
Суха математика: хто був найшвидшим
Коли всі агенти закінчили роботу, перше, на що подивилися, — час виконання. Розклад вийшов показовим:
Gemini завершив роботу за 3 хвилини 56 секунд. OpenAI — за 6 хвилин 15 секунд. Kimi — за 6 хвилин 24. Cursor (у тесті — реалізація Claude Opus 4.8) — за 8 хвилин 45 секунд. Grok працював 21 хвилину. Claude фінішував останнім — 23 хвилини 18 секунд.
Є ще одна деталь: Claude взагалі не починав писати код приблизно до сьомої–восьмої хвилини. Модель довго «думала» в максимальному режимі reasoning, який був ввімкнений для всіх систем, де це можливо. Лише після цього перейшла до генерації файлів.
Чисто за відчуттями це ставить Gemini та GPT‑модель OpenAI в очевидні лідери за швидкістю. Але час сам по собі мало що означає, коли мова про складний застосунок. Далі в гру вступають структура проєкту та обсяг роботи.
Файли, рядки, ефективність: хто справді працював
За кількістю файлів явним лідером став Claude. Жодна інша модель не наблизилася до нього: якщо відсортувати проєкти зверху вниз, саме Claude створив найбільше файлів, а далі йдуть інші моделі зі значним відривом.
Картина повторюється і за рядками коду: на вершині знову Claude, за ним Kimi, далі Grok, Cursor/Opus, OpenAI та Gemini. Це не тільки про «багато чи мало коду», а й про те, скільки реально було зроблено роботи для реалізації функціоналу.
Щоб зрозуміти, як швидко кожна модель генерує цей код, автор ввів ще одну метрику — рядки коду за хвилину. Тут розкладання протилежне до часових показників:
Kimi показав «екстремальну» швидкість, ставши лідером за рядками на хвилину. Далі — Gemini, потім модель OpenAI, за ними Cursor, Claude і останнім — Grok. Саме Grok виявився найповільнішим за цією метрикою.
Так сформувалася своєрідна карта ефективності: одні моделі продукують багато коду дуже швидко, інші — менше, але структурованіше. Та головний критерій усе одно не в цифрах, а в тому, що в підсумку відкривається в браузері.
Результат на екрані: коли кількість не переходить у якість
Головний підсумок за підсумковим геймплеєм виявився доволі простим.
Серед усіх LLM Claude дав найкращий результат «з великим відривом». Це стосується ігрової функціональності, використання ассетів, загальної завершеності гри. OpenAI (GPT 5.5) зміг видати придатну до гри версію — неідеальну, без багатьох додаткових елементів, але таку, в яку реально можна було грати.
Чотири інші моделі суттєво розчарували. Більшість з них не створили нічого близького до повноцінного Mario Kart‑подібного проєкту. Ассети були використані неправильно чи фрагментарно, вʼюшки і модель гри — зламані, функціонал — урізаний до рівня технодему.
Висновок виявився доволі жорстким: такий рівень складності застосунку, та ще й у межах одного промпта, виявився надто важким для значної частини «менш потужних, не фронтирних» моделей. На простих задачах вони можуть виглядати впевнено, але в реальному комплексному завданні відстають від лідерів.
Як оцінювали: AI‑суддя, нормалізований скоринг і упередження
Щоб перетворити окремі враження від гри та коду в числову оцінку, автор виніс суддівство за межі власної суб’єктивності.
Для початку він доручив первинне оцінювання окремій AI‑моделі. Було запущено кілька різних моделей‑оцінювачів, щоб уникнути упередженості на користь конкретного вендора чи архітектури. Після цього всі бали були вручну перевірені та частково підкориговані — саме для того, щоб, за формулюванням автора, отримати «справедливий результат».
За підсумковим рейтинґом загальної якості знову ж таки переміг Claude. На другому місці — GPT, на третьому — Composer. Решта моделей «доганяли» далеко ззаду, уже без шансів скласти конкуренцію лідерам за підсумковим скором.
Щоб урахувати фактор часу, автор ввів «нормалізований швидкісний бал». Фактично це якість, помножена на тривалість виконання: чим швидше модель видала певний рівень якості, тим більшу перевагу вона отримувала.
Навіть у такій системі, де час суттєво «штрафує» повільні моделі, картина не змінилася радикально. Результати сильно зблизилися, але Claude, який працював майже 23 хвилини проти приблизно шести–семи у OpenAI, все одно вийшов уперед за обраною формулою. Баланс «час/якість» залишив його загальним переможцем.
Що стоїть за цифрами: архітектура та підхід моделей
За статистикою часу й рядків коду ховається ще одна важлива різниця — як саме кожна модель підходила до побудови проєкту.
У Claude (Opus) одна з ключових причин довгого виконання стала очевидною під час аналізу коду: модель фактично з нуля розробила повноцінний ігровий рушій. Крім фронтенд‑частини, вона створила набір Python‑інструментів для аналізу спрайтів, їх розбору й підготовки до використання. Код було розбито на безліч дрібніших файлів, проєкт вийшов модульним і чітко структурованим. За візуальним враженням JavaScript виглядав «шумно», але з погляду організації це був справді зібраний «движок», а не просто один великий скрипт.
OpenAI обрав більш прагматичний шлях. Архітектура залишалася «здоровою»: чиста розбивка на файли, без надмірно довгих модулів, відносно продумана фізика руху, проста, але робоча AI‑логіка для переміщення картів. Були реалізовані деякі предмети й механіки. Водночас відчутно бракувало цілого шару «обвʼязки»: не використовувалися надані ассети, фактично були відсутні ефекти частинок, аудіодвижок, титульний екран та інші елементи, які мали б додати грі завершеності.
Composer на цьому тлі виглядав як спрощена версія. В коді було багато пропусків: бракувало статистики, значна частина ассетів не була задіяна, сам проєкт вийшов мінімалістичним і не намагався побудувати щось складніше за базову структуру.
Kimi, попри найвищу швидкість генерації за рядками коду на хвилину, мало що запропонував за функціональністю. Модель «наштампувала» величезну кількість коду, але кінцевий результат майже не містив тих фіч, які були вказані в початкових вимогах.
Grok виявився, можливо, найбільшим розчаруванням. Модель працювала дуже довго, але не видала нічого, що було б схоже на очікуваний результат. За сукупністю «час + якість» саме Grok отримав неформальний статус «найгіршої ціннісної пропозиції» в експерименті.
Gemini 3.1 проявив себе з іншого боку: модель відпрацювала надзвичайно швидко, але обмежилася тим, що згенерувала кілька (приблизно пʼять) JS‑файлів. Це було радше фрагментарне рішення, ніж повноцінна гра з усім передбаченим набором механік.
Фінальний розклад: що це означає для практичного деву
Підсумкові «key takeaways» з цього порівняння виглядають так.
Claude переміг за якістю результату, але заплатив за це значно довшим часом генерації, ніж усі інші учасники тесту. GPT видав працюючий, відносно збалансований застосунок суттєво швидше — за приблизно третину, а фактично близько чверті часу Claude.
Kimi написав масивний обсяг коду, однак не зміг перетворити його на якісний кінцевий продукт. Grok став найгіршим варіантом за співвідношенням витраченого часу й одержаної якості — довга генерація та один з найнижчих результатів у підсумковій оцінці.
Загальний висновок звучить обережно, але чітко: «інші» моделі, які можуть здаватися цілком компетентними на дрібних або вузьких задачах, на складному цілісному завданні на кшталт Mario Kart значно програють лідерам. Там, де потрібна і продумана архітектура, і детальний функціонал, і стабільна робота, реальну відстань між GPT/Claude та рештою ринку важко не помітити.
Автор при цьому наголошує: ці висновки стосуються саме цього конкретного сценарію і не є «остаточною таблицею рангів» для всіх можливих завдань. Але як практичний зріз поведінки моделей під реальним дев-навантаженням це порівняння добре показує головну дилему вибору LLM: швидкість проти глибини — та те, як по‑різному моделі розставляють акценти між цими полюсами.