У блозі Tech With Tim вийшов детальний експеримент: два найпомітніші інструменти для AI‑розробки, Claude Code та Codex, отримали одне й те саме завдання — з нуля створити реальний застосунок. Не черговий «to‑do list» і не набір ізольованих алгоритмічних задач, а повноцінний веб‑додаток із фронтендом, бекендом, реальним часом і складною взаємодією. Мета — подивитися, як моделі поводяться в умовах, максимально наближених до роботи живого розробника.
Цей матеріал зосереджений саме на тому, як був поставлений експеримент: що будували, які вимоги закладали в технічне завдання, як структурували етапи розробки та в яких конфігураціях запускали Claude Code й Codex. Саме від якості постановки такого тесту залежить, чи можна взагалі робити висновки про «кращий» інструмент.
Collab MD: тест не про «хеллоу ворлд», а про реальний продукт
Замість синтетичних промптів на кшталт «написати функцію сортування» чи «згенерувати компонент React», обидва інструменти отримали завдання побудувати один і той самий застосунок — Collab MD. Це реальний, хоч і демонстраційний, продукт: колаборативний markdown‑редактор із роботою в реальному часі.
Базова ідея Collab MD проста, але технічно вимоглива. Інтерфейс має бути розділений на дві панелі: зліва — markdown‑редактор, справа — live‑прев’ю відрендереного тексту. Над ними — верхня панель із елементами керування. Уже цього достатньо, щоб перевірити, як AI‑кодер справляється з типовим стеком сучасного фронтенду.
Але справжня складність починається з вимог до реального часу. Collab MD повинен підтримувати одночасну роботу кількох користувачів над одним документом. Для цього в технічному завданні прямо прописано використання WebSocket‑з’єднань. Моделі мають не просто «якось синхронізувати текст», а побудувати систему, здатну обробляти паралельні зміни, потенційні конфлікти редагування та оновлення інтерфейсу без перезавантаження сторінки.
Окремий акцент зроблено на «присутності курсора» — користувачі повинні бачити, де саме в тексті працюють інші. Це означає додаткові повідомлення по WebSocket, відстеження позицій курсорів, оновлення стану клієнта й візуальне відображення цих позицій у редакторі.
До цього додається ще один пласт — керування документами. Collab MD має вміти створювати, читати, оновлювати й видаляти документи. Тобто в завданні одразу закладено повноцінний CRUD‑функціонал, а не лише «один текстовий файл у пам’яті». Це вимагає від моделей побудови хоча б мінімальної структури даних, API‑ендпоінтів і логіки збереження.
Нарешті, обов’язковою частиною специфікації є автозбереження та персистентність. Редактор не повинен покладатися на ручне натискання «Save» — зміни мають регулярно зберігатися, а документи переживати перезапуск застосунку. Це змушує AI‑кодери думати про бекенд‑сховище, інтервали автозбереження, обробку помилок і узгодженість стану між клієнтом і сервером.
Таким чином, Collab MD — це не демонстрація окремих можливостей моделей, а інтеграційний тест: фронтенд, бекенд, реальний час, стани, помилки, UX. Саме в такому середовищі стає видно, чи здатен AI‑інструмент поводитися як повноцінний «розробник», а не просто генератор фрагментів коду.
Обов’язкове проти «було б класно»: як розділили ядро й додаткові фічі
Щоб не перетворити експеримент на безкінечне нарощування функціоналу, специфікація Collab MD чітко розділяє обов’язкові можливості й так звані stretch‑цілі — бажані, але не критичні для базової версії.
До ядра застосунку входять:
- розділений інтерфейс редактора та прев’ю;
- реальний час через WebSockets;
- індикатори присутності курсора;
- повний CRUD для документів;
- автозбереження та персистентність.
Це той мінімум, без якого Collab MD перестає бути тим, чим його задумано: багатокористувацьким редактором, придатним для реальної роботи.
Натомість версійність, експорт і темна тема винесені в окремий блок stretch‑функцій. Ідея в тому, щоб спочатку змусити моделі довести до робочого стану основний сценарій — спільне редагування тексту, — а вже потім, якщо все не розвалиться, переходити до покращень.
Версійна історія передбачає збереження змін документа в часі, можливість перегляду попередніх станів і, потенційно, відкату. Це серйозне ускладнення моделі даних і логіки бекенду, тому його залишили на пізніший етап.
Експорт — ще один «приємний бонус», який вимагає додаткових форматів вивантаження (наприклад, Markdown‑файл або HTML), генерації файлів на сервері чи клієнті та коректної інтеграції з UI.
Темна тема — завдання радше для фронтенду й дизайну, але воно теж не тривіальне, якщо робити його акуратно: потрібна система тем, перемикач, збереження вибору користувача та коректна робота з усіма компонентами інтерфейсу.
Таке розділення на ядро й розширення важливе не лише з точки зору керованості експерименту. Воно показує, чи здатні моделі правильно розставляти пріоритети, коли отримують багату на деталі специфікацію. Спочатку — стабільний базовий сценарій, потім — «приємні дрібниці». У реальних командах саме так зазвичай планують релізи.
Рівні умови: однаковий стек, однаковий бриф, однакові фази
Щоб порівняння Claude Code і Codex було максимально чесним, обидва інструменти отримали однаковий стартовий пакет інформації. Перед початком будь‑якого кодування їм передали письмову специфікацію Collab MD, короткий огляд архітектури й опис бажаного UI‑макету.
Цей бриф не був надто жорстким, але й не залишав повної свободи. Важливий момент — однаковий технологічний стек. Автор експерименту спеціально зафіксував набір технологій, щоб уникнути ситуації, коли одна модель обирає, наприклад, простіший для себе фреймворк чи іншу парадигму, і за рахунок цього отримує перевагу. Завдання полягало в тому, щоб оцінити саме здатність працювати в заданих рамках, а не в «улюбленому середовищі» кожної моделі.
Далі весь процес розробки був розбитий на чіткі фази. Замість одного гігантського промпту «зроби мені Collab MD» моделі крок за кроком отримували окремі завдання:
спочатку — початкове проєктне scaffolding, тобто створення структури клієнта й сервера, налаштування залежностей і базового оточення;
потім — реалізація базового редактора та прев’ю, щоб користувач міг хоча б редагувати markdown і бачити результат;
далі — додавання синхронізації в реальному часі через WebSockets;
після цього — курсорна присутність, коли в інтерфейсі відображаються позиції інших користувачів;
окремим етапом — створення лендінг‑сторінки, яка слугує входом у застосунок і точкою керування документами;
наступний крок — повний CRUD для документів: створення, перегляд, оновлення, видалення;
далі — обробка статусу з’єднання, помилок і логіки перепідключення, без чого реальний час у мережі неминуче ламається;
і вже наприкінці — версійна історія, експорт і темна тема як додаткові можливості.
Такий покроковий підхід дозволяє не лише контролювати прогрес, а й фіксувати, як саме моделі поводяться на кожному етапі: де виникають помилки, як вони реагують на фідбек, чи не намагаються «перестрибнути» через кроки. Важливо, що обидва інструменти отримували однакові промпти на кожній фазі, включно з описом виявлених багів перед переходом до наступного завдання.
Конфігурації моделей: максимум можливостей для обох сторін
Ще один ключовий елемент експерименту — налаштування самих AI‑моделей. І Claude Code, і Codex запускалися в режимах, максимально наближених до «преміум‑доступу», щоб не обмежувати їх у ресурсах без потреби.
Claude Code працював на моделі Opus 4.7 у найвищому режимі reasoning. Це означає, що система мала доступ до повної потужності моделі, включно з розширеними можливостями міркування й планування. Контекстне вікно було встановлено на рівні 1 мільйона токенів — це дозволяє моделі тримати в пам’яті величезний обсяг коду, специфікацій і проміжних результатів без агресивного обрізання історії діалогу.
Codex, у свою чергу, використовував модель GPT 5.5 в режимі extra high. Опція прискорення на 1,5x не була увімкнена, щоб не створювати асиметрію: у Claude Code немає аналогічного режиму, тож для чесності обидва інструменти працювали без штучного форсажу. Контекстне вікно в Codex було меншим, ніж у Claude Code, але це — технічне обмеження самої платформи, а не вибір експериментатора.
Обидва інструменти отримали повний доступ до файлової системи й середовища виконання. Claude Code було переведено в режим повного доступу або bypass‑permission, що дозволяє моделі змінювати файли без ручного підтвердження кожної дії. Codex також працював у режимі full access: він міг запускати сервери, відкривати браузер, керувати процесами на машині.
Це важливо, тому що сучасні AI‑кодери — це вже не просто «чати з кодом», а агенти, здатні самостійно запускати застосунки, тестувати їх, відкривати сторінки в браузері й перевіряти, чи працює інтерфейс. Забирати в них ці можливості означало б штучно занижувати їхній потенціал.
Перед стартом експерименту автор перевірив і поточне використання лімітів. У Claude Code воно було на рівні приблизно 11% від тижневого ліміту й 5% від ліміту в п’ять годин — тобто запасу мало вистачити на повний прогін. У Codex показники були практично нульовими як за загальним, так і за тижневим використанням, тож модель стартувала фактично «з чистого аркуша».
Як виглядали перші кроки: scaffolding та базовий інтерфейс
Початковий етап — scaffolding — добре показав різницю в стилі роботи двох інструментів. Claude Code завершив цей крок приблизно за шість хвилин. Codex витратив близько чотирнадцяти хвилин, тобто більш ніж удвічі довше. Але різниця в часі пояснюється не лише швидкістю моделі, а й тим, що саме вона встигла зробити.
Структура проєкту, згенерована Codex, виявилася помітно більш розгалуженою. На боці клієнта в директорії source з’явилося більше папок і файлів, ніж у варіанті Claude Code. На сервері Codex створив окремі каталоги на кшталт types, dist, data та інші службові структури, яких не було в Claude‑версії. Тобто Codex витратив додатковий час на побудову більш детального каркасу застосунку.
Ще одна відмінність — поведінка після генерації коду. Codex не лише створив структуру, а й автоматично запустив застосунок, відкрив браузер і перевірив базову працездатність. Він навіть виявив конфлікт портів, завершив процес, який займав потрібний порт, і перезапустив сервер. Це демонструє активне використання можливостей «комп’ютерного агента».
Claude Code, навпаки, після завершення scaffolding не запустив застосунок автоматично й не відкрив прев’ю в браузері. Модель лише повідомила, що сервер можна запустити, але не зробила цього самостійно, попри наданий повний доступ. Довелося явно попросити її запустити застосунок, після чого Collab MD дійсно піднявся, хоча й без інтегрованого прев’ю, яке показував Codex.
На другому етапі — побудові базового інтерфейсу редактора — обидві моделі рухалися вже синхронніше. Вони реалізували розділений екран із редактором і прев’ю, додали верхню панель і базову логіку редагування markdown. Цей крок завершився приблизно одночасно для обох інструментів.
Під час раннього тестування UI виявилися перші баги. У Codex при відкритті нового документа інтерфейс потрапляв у нескінченний цикл оновлень — очевидна логічна помилка в обробці стану. Водночас Claude Code згенерував інтерфейс, у якому кнопка «новий документ» не працювала, але якщо вручну перейти за URL на кшталт /doc/test, редактор функціонував коректно й без «зациклення».
Обидва інструменти отримали зворотний зв’язок про ці проблеми до переходу на наступну фазу. Це важливий момент: експеримент не був «одноразовим запуском», де моделі залишаються наодинці зі своїми помилками. Їм, як і живим розробникам, повідомляли про знайдені баги, після чого вони мали врахувати це в подальшій роботі.
Реальний час як стрес‑тест: WebSockets і синхронізація
Фаза додавання реального часу стала першим серйозним стрес‑тестом для архітектури, яку моделі встигли побудувати на попередніх етапах. Саме тут проявляється, наскільки продумано вони організували обмін даними між клієнтом і сервером.
На цьому етапі завдання полягало в тому, щоб забезпечити одночасне редагування документа кількома користувачами через WebSockets. Це означає, що кожна зміна в тексті має транслюватися на сервер, а звідти — на всіх підключених клієнтів. Потрібно уникати нескінченних циклів оновлення, коректно обробляти швидкі послідовні зміни й не ламати локальний стан редактора.
Цікаво, що саме тут Codex вийшов уперед за часом: він завершив реалізацію реального часу приблизно на сьомій хвилині, тоді як Claude Code затримався довше. При цьому Claude продовжував відчувати труднощі з автоматичним запуском dev‑серверів і розгортанням, тоді як Codex упевнено піднімав застосунок і не мав проблем із базовим деплоєм.
Після завершення цієї фази Codex‑версія Collab MD уже дозволяла створювати нові документи й вводити текст, який синхронізувався між клієнтами. Це ще не повна картина всіх вимог (зокрема, курсорна присутність і розширена обробка помилок залишалися попереду), але саме тут стало видно, що моделі по‑різному розподіляють зусилля між архітектурою, інфраструктурою та швидкістю реалізації фіч.
Висновки: чому постановка експерименту важливіша за «переможця»
Експеримент із Collab MD показує, що порівнювати AI‑інструменти для розробки на основі окремих промптів — майже марна справа. Лише коли моделі отримують завдання побудувати цілісний застосунок із реальним часом, персистентністю, UI та обробкою помилок, стає видно їхні сильні й слабкі сторони.
Ключові елементи чесного порівняння тут такі: однаковий стек, однакова специфікація, чітко розбиті фази розробки, повний доступ до середовища виконання й максимально потужні конфігурації моделей. Додатково важливо розділяти обов’язковий функціонал і stretch‑цілі, щоб не плутати «гарні бонуси» з базовою працездатністю.
У цьому сенсі Collab MD — показовий кейс. Він достатньо складний, щоб виявити проблеми з архітектурою, синхронізацією й UX, але водночас досить компактний, щоб його можна було реалізувати в межах одного експерименту. А те, як Claude Code і Codex поводилися на різних етапах — від scaffolding до WebSockets, — дає значно більше інформації, ніж будь‑який рейтинг «хто швидше написав функцію сортування».
Подальший аналіз швидкості, автономності, якості реалізованих фіч і кількості багів — окрема історія. Але без такого ретельно продуманого сетапу самі по собі ці метрики були б малоінформативними. У підсумку головний висновок стосується не стільки конкретних моделей, скільки підходу: щоб зрозуміти, на що здатен AI‑кодер, його потрібно ставити в умови, максимально наближені до реальної розробки продукту.