Порівняння AI‑інструментів для програмістів дедалі частіше виходить за межі абстрактних бенчмарків. У свіжому експерименті автор каналу Tech With Tim поставив перед двома флагманськими середовищами — Claude Code (Opus 4.7) та Codex (GPT 5.5) — однакове реальне завдання: з нуля зібрати Collab MD, веб‑додаток для спільного редагування markdown у реальному часі.
Обидва інструменти отримали однаковий текстовий технічний опис: спліт‑екранний редактор, синхронізація через WebSocket, курсорна присутність, управління документами, автозбереження та персистентність, а також перелік «стретч‑фіч» на кшталт історії версій, експорту та темної теми. Побудова додатка була розбита на фази — від базового UI до реального тайм‑колабу й документного CRUD.
Ця частина експерименту зосереджується на тому, що вийшло «на виході»: як саме Claude Code і Codex реалізували ключові фічі інтерфейсу, реального часу та збереження, і які баги проявилися в процесі.
Базовий інтерфейс: обидва моделі влучили в макет, але з різними шрамами
Після початкового етапу scaffolding, коли було створено структуру проєкту, обидва інструменти перейшли до другої фази — побудови основного інтерфейсу редактора. Специфікація вимагала спліт‑екран: зліва markdown‑редактор, справа — прев’ю, зверху — топбар із елементами керування.
На цьому етапі і Claude Code, і Codex продемонстрували, що здатні досить точно інтерпретувати UI‑вимоги. Обидва згенерували спліт‑екранний інтерфейс із верхньою панеллю та базовим редагуванням markdown. З погляду макета, ключова вимога була виконана: користувач отримував знайому структуру «редактор + прев’ю» з верхнім баром, що відповідає типовим патернам для markdown‑додатків.
Однак перші ж інтерактивні тести показали, що зовнішня схожість ще не означає надійність поведінки. Коли справа дійшла до роботи з документами, виявилося, що обидва середовища припустилися критичних помилок у логіці, але різного характеру.
У Codex при спробі створити новий документ інтерфейс миттєво впадав у нескінченний цикл. Відкриття нового документа призводило до повторюваної послідовності дій, що виглядала як зациклена логіка створення або завантаження документа. Це типовий симптом проблем зі станом: або неправильна обробка маршруту, або некоректний ефект у фронтенді, який постійно тригерить сам себе.
Claude Code, навпаки, показав більш стабільну поведінку ядра редактора, але «спіткнувся» на зв’язуванні UI‑елементів. Кнопка «New document» у його версії просто не працювала: натискання не призводило до створення чи відкриття нового документа. Водночас, якщо вручну перейти за URL на кшталт /doc/test, редактор відкривався і працював коректно. Це важливий нюанс: проблема була не в самому редакторі чи логіці документа, а в маршрутизації або обробнику кнопки, який не був правильно прив’язаний до відповідної дії.
У підсумку обидва інструменти формально виконали вимогу до інтерфейсу, але з різними компромісами. Codex продемонстрував більш «живий» UI, який одразу запускався, відкривав документи й навіть дозволяв їх видаляти, але приховав у собі серйозний логічний баг із нескінченним циклом. Claude Code видав більш стриманий, але стабільніший редакторський досвід, якщо обійти зламану кнопку й перейти безпосередньо за URL документа.
Ранні баги: що говорять нескінченні цикли та «мертві» кнопки
Поведінка обох додатків на ранньому етапі тестування добре ілюструє різні типи помилок, до яких схильні AI‑генеровані застосунки.
У випадку Codex нескінченний цикл при відкритті нового документа вказує на глибшу проблему в управлінні станом. Коли користувач натискав «New document», інтерфейс починав повторювати одну й ту ж послідовність дій, що візуально проявлялося як «зависання» або постійне перезавантаження. Така поведінка зазвичай означає, що:
компонент реагує на зміну стану, яку сам же й ініціює, без належних умов;
або логіка маршрутизації зациклює перенаправлення між двома станами;
або ефект у фреймворку (наприклад, React‑hook) викликається без коректного масиву залежностей і постійно перезапускається.
Для кінцевого користувача це означає повну неможливість працювати з новими документами, навіть якщо інші частини інтерфейсу виглядають функціональними.
Claude Code зіткнувся з іншим класом проблем: інтеграційно‑маршрутизаційним. Кнопка «New document» була присутня в інтерфейсі, але не виконувала жодної дії. При цьому прямий перехід на URL документа демонстрував, що:
маршрути на рівні застосунку налаштовані;
логіка ініціалізації документа працює;
редактор коректно відображає і дозволяє редагувати вміст.
Інакше кажучи, ядро функціональності було на місці, але «дроти» між UI‑елементом і цією логікою не були підключені. Це може бути відсутній обробник події, неправильний шлях у роутері або помилка в навігаційній функції.
Ключовий момент у цьому експерименті полягає в тому, що обидва інструменти отримали явний фідбек про виявлені баги ще до переходу до наступної фази. Автор прямо описав Codex проблему з нескінченним циклом при створенні нового документа, а Claude Code — несправну кнопку «New document» і той факт, що редактор працює при прямому переході за URL.
Це означає, що подальша поведінка моделей — зокрема, у фазі реального тайм‑колабу — вже не була повністю автономною. Вони не «самі здогадалися» про помилки, а реагували на зовнішній опис проблем. Для практичного використання це важливий сигнал: ефективність таких інструментів суттєво залежить від якості зворотного зв’язку, який їм дає розробник, і від того, наскільки чітко формулюються симптоми багів.
Реальний час: хто швидше вийшов на стабільну синхронізацію
Наступна велика віхa — додавання реального тайм‑колабу через WebSocket. На цьому етапі обидва інструменти мали перетворити локальний markdown‑редактор на багатокористувацький застосунок, де зміни синхронізуються між вкладками майже миттєво, а присутність інших користувачів відображається в інтерфейсі.
У цій фазі Codex виявився швидшим. Його реалізація реального часу завершилася приблизно на сьомій хвилині, тоді як Claude Code продовжував працювати довше, паралельно борючись із проблемами запуску дев‑серверів і деплойменту. Codex не лише закінчив код швидше, а й без особливих труднощів підняв застосунок, відкрив його в браузері та дозволив перевірити поведінку в реальному часі.
При тестуванні колаборації Codex забезпечив майже миттєве оновлення вмісту між вкладками. Коли в одному вікні вводився текст, інше оновлювалося практично без затримки. До того ж, у застосунку з’явилася форма ідентифікації курсора — певний ярлик або мітка, що дозволяє відрізняти користувачів один від одного. Це не обов’язково повноцінні «аватарки» чи кольорові курсори, але достатній рівень відображення присутності, щоб зрозуміти, хто саме редагує документ.
Claude Code також реалізував реальний тайм‑колаб, але з іншим акцентом. Його версія підтримувала оновлення між кількома клієнтами в реальному часі, як і вимагала специфікація, однак додатково включала підсвічування «намірів» курсора. Це означає, що інтерфейс не просто показував, де знаходиться курсор іншого користувача, а й виділяв область або позицію, на якій той фокусується. Такий підхід робить спільне редагування більш передбачуваним: видно не лише факт присутності, а й те, куди спрямована увага іншого учасника.
З погляду користувацького досвіду це два трохи різні підходи до колаборації. Codex робить ставку на швидкість і базову ідентичність користувачів, забезпечуючи майже миттєву синхронізацію. Claude Code додає шар семантичної інформації — «намір» курсора — що може бути особливо корисно в сценаріях, де кілька людей одночасно працюють над одним фрагментом тексту.
Водночас варто пам’ятати, що обидва інструменти вже мали історію ранніх багів у документному потоці. Реальний час лише підсилює наслідки таких помилок: нескінченний цикл у Codex або несправна навігація в Claude Code можуть зробити колаборацію нестабільною, навіть якщо сама WebSocket‑синхронізація працює коректно.
Персистентність і надійність: коли сторінка F5 стає тестом на зрілість
Окремий пласт проблем проявився в тому, як додатки поводилися при оновленні сторінки та роботі з персистентністю документів. Для реального колаборативного редактора автозбереження й надійне зберігання — не менш важливі, ніж сам реальний час. Користувач очікує, що документ не зникне після випадкового перезавантаження вкладки.
На певному етапі збірки виявилося, що реалізація Claude Code не завжди коректно зберігає документи між перезавантаженнями сторінки. Після F5 створені або відредаговані документи могли не відновлюватися належним чином, що вказує на проблему в інтеграції з механізмом збереження — чи то локальне сховище, чи то бекендова база даних.
Це не просто дрібний UX‑недолік. Для додатка на кшталт Collab MD така поведінка означає ризик втрати даних і підриває довіру до інструменту. Якщо користувач не впевнений, що його зміни переживуть перезавантаження, реальний тайм‑колаб втрачає значну частину своєї цінності.
Цікаво, що ранні симптоми в Claude Code — несправна кнопка «New document» при працездатному редакторі за прямим URL — уже натякали на розрив між UI та документним життєвим циклом. Проблеми з персистентністю лише підсилили це враження: модель добре справляється з локальною логікою редагування, але дає збої на стику з довготривалим зберіганням і відновленням стану.
У випадку Codex у наданому фрагменті експерименту основний акцент був на нескінченному циклі при створенні нового документа, а не на персистентності після перезавантаження. Однак уже сам факт такого циклу вказує на потенційні ризики для надійності документного потоку. Якщо логіка створення документа зациклюється, це може впливати й на те, як документ зберігається, і на те, як він відновлюється після оновлення сторінки.
Для розробників, які розглядають AI‑інструменти як «співавторів» коду, це важливий урок: навіть якщо модель успішно реалізує складні фічі на кшталт WebSocket‑колаборації чи курсорної присутності, критично необхідно вручну перевіряти базові сценарії надійності — створення, збереження, перезавантаження, повторне відкриття документа.
Що це означає для розробників, які покладаються на AI‑кодери
Порівняння Claude Code та Codex на прикладі Collab MD показує, що оцінювати AI‑інструменти лише за швидкістю генерації коду або обсягом scaffolding — недостатньо. Ключові відмінності проявляються саме в тому, як моделі поводяться на рівні фіч, багів і надійності.
По‑перше, обидва інструменти продемонстрували здатність швидко реалізувати складний інтерфейс: спліт‑екранний markdown‑редактор із топбаром був побудований у межах однієї фази, без необхідності детально «розжовувати» кожен елемент. Це свідчить про те, що сучасні AI‑кодери добре працюють із високорівневими UI‑специфікаціями.
По‑друге, характер багів виявився різним. Codex схильний до глибших логічних помилок у потоках стану, які проявляються як нескінченні цикли або неконтрольовані оновлення. Claude Code частіше «спотикається» на інтеграційних моментах — кнопки, маршрути, підключення до механізмів збереження. Для команди розробки це означає різні стратегії тестування: у випадку Codex варто особливо уважно перевіряти життєвий цикл компонентів і ефекти, у випадку Claude Code — зв’язки між UI та бекендом, а також персистентність.
По‑третє, обидва інструменти виявилися чутливими до якості фідбеку. Після виявлення ранніх багів автор прямо описав проблеми кожній моделі, і подальші кроки вже будувалися з урахуванням цього опису. Це підкреслює, що ефективність AI‑кодера — це не лише властивість моделі, а й функція взаємодії з людиною. Чим точніше сформульовано симптоми помилки, тим вищі шанси, що модель запропонує адекватне виправлення.
По‑четверте, у фазі реального тайм‑колабу обидва інструменти досягли цілей специфікації, але з різними акцентами. Codex зробив ставку на швидке завершення реалізації та майже миттєву синхронізацію з базовою ідентичністю курсорів. Claude Code додав більш «семантичну» фічу — підсвічування намірів курсора, що покращує спільний досвід редагування, але при цьому виявив слабкі місця в персистентності.
Нарешті, проблеми з перезавантаженням сторінки в Claude Code нагадують, що для будь‑якого колаборативного редактора перевірка F5 — це не дрібниця, а базовий тест зрілості. AI‑інструменти можуть вражати здатністю швидко зібрати складний стек — від WebSocket до курсорної присутності, — але саме дрібні, «нудні» сценарії на кшталт збереження й відновлення стану часто виявляються найвразливішими.
Висновок: AI‑кодери вже будують складні фічі, але без людини не обійтися
Експеримент із Collab MD показує, що і Claude Code, і Codex уже здатні самостійно реалізовувати нетривіальні функції: спліт‑екранний markdown‑редактор, реальний тайм‑колаб, курсорну присутність. Обидва інструменти дотрималися базової UI‑специфікації, а в реальному часі забезпечили синхронізацію між клієнтами, включно з відображенням користувачів через мітки курсора або підсвічування намірів.
Водночас, коли справа дійшла до стабільності й надійності, виявилося, що без уважного людського контролю не обійтися. Нескінченний цикл у Codex при створенні нового документа, несправна кнопка «New document» і проблеми з персистентністю в Claude Code — усе це нагадує, що AI‑генерований код потребує такого ж ретельного тестування, як і написаний людиною.
Для розробників це означає, що AI‑кодери вже можуть суттєво прискорити реалізацію складних фіч, але не замінюють інженерного мислення. Вони добре справляються з інтерпретацією специфікацій і побудовою архітектури, але відповідальність за виявлення й виправлення критичних багів, особливо в логіці стану та персистентності, все ще лежить на людині.
Collab MD став показовим полігоном: він продемонстрував, що сучасні моделі вже вміють будувати реальні продукти, а не лише демо‑фрагменти коду. Але також нагадав, що шлях від «працює в більшості випадків» до «можна довірити продакшен» усе ще вимагає людського досвіду, уважності й системного тестування.