У новому експерименті з каналу Tech With Tim два з найпомітніших AI‑асистенти для розробників — Claude Code (Opus 4.7) та Codex (GPT 5.5) — отримали однакове завдання: самостійно зібрати складний веб‑застосунок Collab MD, реальний час колаборативний markdown‑редактор. Обидва інструменти працювали з однаковим технічним описом, архітектурою та макетом інтерфейсу, а процес було розбито на кілька фаз: від початкового scaffolding до реального часу синхронізації, курсор‑присутності, документного CRUD, версійності та експорту.
Ця частина експерименту зосереджується не на кінцевій якості коду, а на поведінці моделей під час збірки: швидкості, автономності, шаблонах використання ресурсів і тому, як саме вони керують середовищем розробки.
Нерівний старт: ліміти, моделі й повний доступ до системи
Перед запуском першого промпту обидва інструменти опинилися в різних умовах щодо використання ресурсів. Claude Code уже був частково «розігрітий»: приблизно 11% тижневого ліміту та 5% п’ятигодинного ліміту були витрачені раніше. Codex, навпаки, стартував практично з нуля — фактично 0% як загального, так і тижневого використання. Це важливий контекст, коли йдеться про те, наскільки агресивно кожен інструмент може «спалювати» підписку під час тривалої сесії.
З точки зору конфігурації, обидва асистенти отримали максимально «розв’язані руки». Claude Code працював на моделі Opus 4.7 у найвищому режимі reasoning з контекстним вікном у 1 мільйон токенів. Codex використовував GPT 5.5 в режимі extra high, без увімкненої опції 1.5x speed, щоб не створювати штучної переваги в швидкості, якої немає в Opus 4.7.
Ключовий момент — режим доступу. І Claude Code, і Codex було переведено у так званий bypass‑permission або full access mode. Це означає, що моделі могли самостійно:
редагувати файли в робочому каталозі,
запускати dev‑сервери,
керувати процесами.
Codex додатково мав право відкривати браузер і взаємодіяти з ним через кроки комп’ютерного контролю. Людське втручання вносилося лише на рівні нових промптів між фазами, а не при кожній зміні файлу чи запуску команди.
Такий режим перетворює AI‑асистента з «автодоповнювача коду» на напівавтономного агента, який не просто пише файли, а й керує середовищем розробки, тестує застосунок і реагує на помилки в реальному часі.
Scaffolding: швидкий Claude проти педантичного Codex
Перша фаза — scaffolding проєкту — виявила разючу різницю у стилі роботи двох систем.
Claude Code завершив початкове налаштування приблизно за шість хвилин. Codex натомість працював близько чотирнадцяти хвилин, тобто більш ніж удвічі довше. Якщо дивитися лише на таймер, перемога за швидкістю очевидна. Але структура створених проєктів показала іншу картину.
У випадку Claude Code структура клієнта й сервера була відносно компактною. У директоріях client/src та server/src було кілька основних файлів, достатніх для старту, але без надмірної деталізації. Це виглядало як мінімально необхідний каркас, на який можна швидко навішувати функціональність.
Codex пішов іншим шляхом. У клієнтській частині в src з’явилося значно більше директорій та файлів, з чіткішим поділом за відповідальністю. На сервері, окрім основних файлів, були додаткові структури на кшталт окремих типів, директорій dist, data та інших службових елементів, яких не було в проєкті Claude. Загалом scaffolding Codex був помітно більш розгалуженим і структурованим.
Це пояснює різницю в часі: Codex витратив додаткові хвилини не на «зайві роздуми», а на побудову більш повного каркасу застосунку, який ближчий до того, що зазвичай створює досвідчений розробник, орієнтований на масштабованість.
Однак різниця в підході проявилася не лише в структурі файлів, а й у тому, як моделі ставляться до запуску й тестування застосунку.
Автономне тестування: Codex сам запускає, Claude чекає вказівок
Уже на етапі scaffolding Codex продемонстрував агресивнішу модель автономії. Після створення структури він самостійно:
запустив застосунок,
відкрив браузер,
перейшов до локального URL,
перевірив базову працездатність інтерфейсу.
Це відбувалося через кроки комп’ютерного контролю: модель не просто виконувала команди в терміналі, а й взаємодіяла з браузером, створювала новий документ у Collab MD і візуально переконувалася, що сторінка працює. Такий підхід нагадує поведінку розробника, який після ініціалізації проєкту обов’язково запускає dev‑сервер і відкриває UI, щоб переконатися, що все хоча б «піднімається».
Claude Code, попри наданий повний доступ, поводився інакше. Після завершення scaffolding він не запустив застосунок самостійно, не відкрив жодного прев’ю й не перевірив працездатність у браузері. Модель лише повідомила, що сервер можна запустити, але не зробила цього без прямої вказівки.
Щоб побачити Collab MD у дії, довелося явно попросити Claude: «можеш запустити застосунок, щоб я міг його переглянути». Лише після цього він підняв сервер, але навіть тоді не відкрив попередній перегляд у вбудованій вкладці так, як це зробив Codex. У результаті застосунок запрацював, але шлях до нього виявився менш автоматизованим.
Це ілюструє фундаментальну різницю в робочому стилі:
Claude Code орієнтується на швидке виконання інструкцій і мінімально необхідні кроки, не витрачаючи час на ініціативне тестування.
Codex, навпаки, інвестує час у повний цикл: створити структуру, запустити, відкрити, перевірити, за потреби перезапустити.
Уже на першій фазі стає видно, що Codex сприймає себе радше як автономний агент, який контролює середовище, тоді як Claude більше нагадує дуже швидкого, але слухняного асистента, що чекає наступної команди.
UI‑фаза: синхронна швидкість, асинхронні проблеми
На другій фазі обидва інструменти отримали завдання побудувати базовий інтерфейс Collab MD: розділений екран із лівою панеллю редактора, правою панеллю прев’ю, верхньою панеллю керування та базовим markdown‑редагуванням.
Цього разу за часом вони вийшли майже внічию: Claude Code і Codex завершили фазу приблизно одночасно. Але різниця в автономному керуванні середовищем збереглася.
Codex продовжував тримати dev‑сервер у робочому стані й підтримував застосунок, що працює в браузері. Його Collab MD було доступно на порту 5174, і модель без видимих труднощів керувала запуском і перезапуском сервера.
Claude Code, навпаки, знову не мав запущеного застосунку після завершення фази. Щоб побачити оновлений інтерфейс, довелося знову явно попросити модель переконатися, що dev‑сервер працює на конкретному порту (5173). Claude намагався це зробити, але зіткнувся з труднощами при розгортанні, перш ніж йому все ж вдалося підняти застосунок.
Коли обидва інтерфейси запрацювали, виявилися перші відмінності в поведінці застосунків.
У Codex при відкритті нового документа з’являлася помилка у вигляді нескінченного циклу. Після кліку на «new document» UI входив у стан, де сторінка постійно оновлювалася або повторювала якусь дію, що робило роботу з документом неможливою. При цьому базові операції на кшталт створення й видалення документів працювали, але перехід до нового документа ламався.
У Claude Code кнопка «new document» взагалі не працювала. Однак, якщо вручну перейти за URL на кшталт /doc/test або /doc/hello-world, редактор відкривався й працював коректно. Тобто маршрутизація та сам редактор були реалізовані, але зв’язка між кнопкою створення документа та відповідним переходом не спрацьовувала.
Обидва інструменти отримали зворотний зв’язок про знайдені баги перед переходом до наступної фази. Важливо, що на цьому етапі Codex уже продемонстрував здатність виявляти проблеми ще під час scaffolding завдяки автоматичному запуску й перевірці, тоді як Claude покладався на те, що людина сама відкриє застосунок і знайде помилки.
Реальний час синхронізації: Codex тестує, Claude просто пише
Третя ключова фаза — додавання реального часу синхронізації через WebSocket‑з’єднання, щоб кілька користувачів могли одночасно редагувати один документ. Саме тут різниця в стилі роботи моделей проявилася ще виразніше.
На цьому етапі Codex завершив завдання першим — приблизно на сьомій хвилині. Claude Code, навпаки, затримався: він довше боровся з проблемами запуску dev‑серверів і розгортання, що вже траплялося раніше. Codex, попри складність завдання, не мав помітних труднощів із підтримкою робочого середовища.
Поки Claude намагався стабільно підняти сервер, Codex уже оновив застосунок, перезапустив його, відкрив у браузері новий документ і почав перевіряти, як працює синхронізація. Модель активно використовувала кроки комп’ютерного контролю, щоб взаємодіяти з UI, вводити текст і спостерігати за поведінкою застосунку.
Claude Code, зі свого боку, демонстрував іншу стратегію. Він швидко генерував код, але витрачав менше часу на автоматичне тестування на рівні браузера. Проблеми з dev‑серверами й розгортанням доводилося вирішувати вручну або через додаткові промпти, а не через ініціативні дії моделі.
У підсумку вимальовується чіткий патерн:
Claude Code швидко виконує окремі кодові завдання, але його робочий цикл менш насичений автоматичними перевірками в реальному UI.
Codex витрачає більше часу на кожну фазу, але значну частину цього часу проводить у режимі «живого» тестування: запускає сервери, відкриває браузер, клікає по інтерфейсу, створює документи, перевіряє, як усе поводиться.
Для розробника це означає різні сценарії використання. Claude може бути кориснішим там, де людина сама активно керує середовищем, запускає тести й перевіряє UI. Codex краще підходить для сценаріїв, де хочеться делегувати не лише написання коду, а й рутину з запуску, перезапуску та базового інтеграційного тестування.
Швидкість, вартість і контроль: що насправді означає «кращий» AI‑кодер
Якщо дивитися лише на таймінги, Claude Code виглядає привабливо: початковий scaffolding за шість хвилин проти чотирнадцяти в Codex, швидке завершення окремих фаз без зайвих дій. Але в реальній розробці швидкість генерації коду — лише частина історії.
По‑перше, Codex систематично витрачає час на те, що зазвичай робить людина: запуск dev‑серверів, відкриття браузера, перевірка базової функціональності, взаємодія з UI. Це збільшує загальний час фази, але зменшує кількість ручних кроків, які має виконати розробник. У довгих сесіях це може виявитися вигіднішим, навіть якщо модель повільніша на рівні «чистого» коду.
По‑друге, різниця в автономності впливає на витрати підписки. Claude Code стартував уже з 11% тижневого ліміту й 5% п’ятигодинного, тоді як Codex — із практично нульового використання. Модель, яка більше часу проводить у режимі комп’ютерного контролю, відкриває браузер, перезапускає сервери й активно тестує, потенційно споживає більше токенів і часу. Це може швидше «спалювати» ліміти, але водночас економити людський час.
По‑третє, підхід до тестування визначає характер помилок. У Codex уже на ранніх етапах виявляються баги на кшталт нескінченного циклу при створенні нового документа, бо модель сама доходить до цієї дії в UI. У Claude частина проблем, як‑от неактивна кнопка «new document», виявляється лише тоді, коли людина вручну натискає на елемент інтерфейсу.
Це не означає, що один інструмент «кращий» за інший у всіх сценаріях. Швидше, вони демонструють два різні підходи до ролі AI в розробці:
Claude Code — швидкий, контекстно потужний асистент, який добре працює в парі з розробником, що сам контролює середовище, запускає й тестує застосунок.
Codex — більш автономний агент, який бере на себе не лише написання коду, а й значну частину операційної рутини: запуск, перевірку, взаємодію з UI, пошук базових багів.
У міру того як AI‑інструменти для розробників стають дедалі складнішими, саме баланс між швидкістю, автономністю та вартістю використання, а не лише «якість коду», визначатиме, який із них виявиться практичнішим у конкретній команді чи проєкті.
Висновок: два стилі AI‑розробки замість одного переможця
Експеримент із Collab MD показує, що порівнювати Claude Code і Codex лише за кінцевим результатом — занадто спрощений підхід. Важливо дивитися на те, як вони поводяться в процесі: як швидко стартують, як будують структуру проєкту, наскільки активно керують середовищем, як часто й на якому рівні тестують застосунок.
Claude Code виявився швидшим на рівні початкового scaffolding і окремих фаз, але менш ініціативним у запуску й тестуванні. Codex працював повільніше, проте створював більш розгалужену структуру, самостійно запускав застосунок, відкривав браузер і витрачав значну частину часу на інтеграційні перевірки.
Для розробників це означає вибір не між «швидким» і «повільним» інструментом, а між двома різними моделями співпраці з AI. Один підхід передбачає, що людина залишається головним оператором середовища, інший — що AI поступово бере на себе роль автономного інженера, який не лише пише код, а й керує життєвим циклом застосунку.
У міру того як такі інструменти інтегруються в повсякденні пайплайни розробки, саме ці відмінності в поведінці — швидкість проти глибини тестування, економія токенів проти економії людського часу — ставатимуть вирішальними при виборі «кращого» AI‑кодера для конкретної задачі.