Як штучний інтелект врятував сонячну систему: випробування ChatGPT, Claude і Gemini
Нещодавно я попросив Claude, ChatGPT і Gemini створити симулятор сонячної системи. Це був час, коли Claude викликав справжній фурор, і багато хто, у тому числі я, замислювалися над тим, що варто шукати альтернативи ChatGPT.
У першому тесті результат був вражаючим та несподіваним: Claude працював блискуче, видавши найкращий код. Gemini створив робочий, але не надто вражаючий симулятор, а ChatGPT, на жаль, не впорався з поставленим завданням.
Виправлення помилок у коді: що змінилося?
Сьогодні я вирішив перевірити інший аспект — нe написання, а саме відлагодження коду. Завдання було виправити поламаний код ChatGPT, щоб перевірити, як різні моделі працюватимуть з уже створеним проєктом.
Попереднє тестування не дозволяло робити спроби повторно: оцінювався лише перший результат. І саме через цю суворість ChatGPT допустив помилку, яка зробила код нефункціональним.
Мала, але фатальна помилка
Головна проблема коду ChatGPT полягала в змішуванні одиниць вимірювання: деякі відстані були задані у кілометрах, інші — у астрономічних одиницях (а.о.). В результаті планети фізично виявлялися розташовані надто близько одну до одної, ніби вони взаємно накладалися.
Код був акуратним і охоплював всі необхідні функції, але ця маленька недоробка робила симулятор непрацездатним і унеможливлювала повноцінну оцінку проєкту.
Gemini — несподіваний чемпіон у дебагінгу
Вищий за очікування
Мій досвід із Gemini зазвичай був неоднозначним: цей ШІ схильний вигадувати проблеми навіть в правильному коді, і виправляти те, що не потребує змін. Але цього разу, використовуючи Gemini 3.1 Thinking, я був здивований позитивно.
Gemini точно вказав на основну помилку: модуль проєкції очікує координати у кілометрах, тоді як функції orbitalPosition і drawOrbit працювали з астрономічними одиницями. Саме через це планети збиралися ми поруч із Сонцем і не зображали реального простору.
Виправлення, запропоноване Gemini, було вірним — код почав працювати, і нарешті симулятор ожив. Ви можете переглянути цей проєкт на Vercel.
Чи виправився ChatGPT?
Траєкторія відновлення
Звісно, здається дивним просити ChatGPT знайти помилку у власному коді. Але за останній час ChatGPT значно покращив свої результати, іноді навіть випереджаючи Gemini. Особисто я помітив, що він краще реагує на кастомні інструкції, що суттєво впливає на якість відповіді.
Цього разу ChatGPT 5.4 Thinking без проблем ідентифікував проблему, дав коротке ясне пояснення та виправив код. Симулятор запрацював коректно.
Цікавим є факт, що ChatGPT витратив значно більше часу на “обдумування” завдання, напевно через зайнятість контексту або певні внутрішні налаштування. Проте результат виправданий — іноді більш «дробові» завдання даються моделі краще, ніж створення комплексного проєкту з нуля.
Claude — найбільший несподіваний гравець
Результат, що виявився неоднозначним
На попередньому етапі Claude створив найкращий за якістю симулятор. Проте в новому тесті, на виявлення й виправлення помилок, вийшло інакше.
Claude не відразу знайшов основний баг, пов’язаний із одиницями вимірювання. Замість цього він спочатку вказав на іншу, менш помітну проблему з камерою при панорамуванні за допомогою Shift-драг.
Ця недосконалість є, але вона не критична, адже не впливає на засадничу функціональність.
Перевірка другого шансу
Я дав Claude можливість поглянути на проблему знову — він погодився і здійснив повторний аналіз.
Спершу виникали неточні висновки, але бот не зупинився. Після декількох спроб він усвідомив головну помилку: невідповідність вимірювальних систем. Виявлену проблему він виправив правильно, хоч і опис наслідків був дещо іншими.
Цікаво, скільки токенів витрачено на весь цей процес, враховуючи жорсткі ліміти згідно з політикою Claude.
Чому потрібна друга думка — навіть штучна
Claude вирізняється набагато більш «ботовою» манерою спілкування. Він не намагається бути вашим приятелем або імітувати людські емоції так нахабно, як Gemini чи ChatGPT. Це помітно і у підходах до вирішення завдань.
У випадку з дебагом, Claude шукав і знаходив реальні баги, але не ту основну помилку, яка розпаковує всю проблему. Його логіка була такою:
- бачиш баг,
- код не має містити баґів,
- це значить, що цей баг найважливіший,
- завершуй роботу.
Цей тест зміцнив думку, що в роботі з великими мовними моделями не існує єдиної найкращої, найуніверсальнішої системи. Важливо звертатися до різних моделей, ставити однакові запитання і порівнювати відповіді.
Пам’ятайте: завжди корисно залучати «друге око» — навіть якщо воно штучне.
