Codex против Claude Code: эксперимент по созданию Typeform-клона автономными кодинг-агентами
Создание программных продуктов силами автономных систем искусственного интеллекта постепенно переходит из области демонстраций в реальную разработку. Однако способность модели генерировать код сама по себе не гарантирует получение работающего веб-сервиса. Когда агенту поручают задачу «под ключ», результат определяют архитектурные приоритеты среды, стратегия распределения ресурсов и то, как система понимает критерии готовности.
Практический стресс-тест двух ведущих платформ — OpenAI Codex и Claude Code — наглядно показал, к каким разным итогам приводит один и тот же запрос. Обеим системам поручили с нуля создать коммерческий аналог сервиса опросов Typeform, задействовав субагентов для исследования, разработки и тестирования. Итоги выявили ключевое расхождение: пока одна среда сфокусировалась на сквозном пользовательском опыте и за несколько часов собрала работающий продукт, вторая потратила трое суток и тысячи долларов на сложнейшую инфраструктуру, но сломала базовый интерфейс.
Условия эксперимента и мультиагентная оркестрация
В основу эксперимента лег сценарий создания веб-приложения без ручного написания кода человеком. Запрос требовал реализовать законченный продукт: многостраничный конструктор форм с ветвлением логики, сохранением состояний, генерацией публичных ссылок и дашбордом аналитики ответов. Промпт прямо предписывал не останавливаться на первом прототипе, а продолжать циклы исследования, сборки и тестирования до полной готовности.
Обе системы запускались в автономном режиме через агентный цикл (agent loop) — механизм в управляющем слое (harness), координирующий диалог между моделью, терминалом, файлами и инструментами:
- Claude Code использовал связку из одного оркестратора (Claude Opus 4.8) и 35 субагентов (Claude Fable 5 и Opus 5). Субагенты здесь — изолированные контексты с собственными инструкциями и ограниченными инструментами для конкретных подзадач.
- OpenAI Codex работал под управлением модели GPT-5.6 Sol на высоком уровне рассуждений, развернув одного оркестратора и 126 субагентов, глубоко распараллеливших инженерные задачи.
Экономика вычислений: скорость, бюджет и токены
Разница в подходах сразу отразилась на эксплуатационных показателях:
| Параметр | Formora (Claude Code) | RealForm (OpenAI Codex) | Особенности метрик |
|---|---|---|---|
| Время сборки | 5,5 часов | ~61–62 часа (~2,5 дня) | Разница по времени составила более 11 раз в одном запуске |
| Агенты | 1 оркестратор, 35 субагентов | 1 оркестратор, 126 субагентов | Большее число агентов усложнило координацию и удлинило цикл |
| Объем токенов | ~2,8 млн токенов | 11,5–32,5 млн токенов | Токены отражают объем вычислений; в логах Codex зафиксированы расхождения |
| Затраты по API | ~$447–$832 | ~$3000 | Разница в стоимости достигла 3,6–6,6 раз в зависимости от учета логов |
| Тесты | 296 тестов (199 unit, 102 browser) | 2300+ прогонов (341 unit, 391 browser) | У Codex число тестов включает множественные повторные компиляции |
| Итог | Работающий сценарий, шероховатости UI | Глубокий бэкенд, сбои функций в конструкторе | Продуктовая завершенность против избыточной инженерии |
Финансовые и вычислительные показатели опираются на единичный авторский запуск с внутренними расхождениями в логах, поэтому их стоит воспринимать как демонстрацию контраста в поведении систем, а не как универсальный стандарт.
Сопоставление продуктов: Formora против RealForm
Приложение Formora (Claude Code) встретило минималистичной посадочной страницей, однако в рабочем пространстве обнаружилась готовая пользовательская логика:
- Конструктор поддерживал многостраничные формы и более 7 типов вопросов: шкалу мнений (Opinion Scale), рейтинг, выпадающие списки и NPS (Net Promoter Score — индекс лояльности клиентов).
- Работали условное ветвление и настройка тем. Форму можно было опубликовать по прямой ссылке, пройти и мгновенно увидеть ответы в сводном дашборде.
- Поддерживалась отправка вебхуков (webhook — HTTP-уведомление о событиях в сторонние сервисы).
- Из минусов отмечены интерфейсные шероховатости: затрудненный возврат из разделов тем и вебхуков, а также сбои нумерации вопросов.
Приложение RealForm (Codex) на старте показало стильный лендинг, но при создании форм вскрылись критические дефекты:
- Кнопка удаления отдельного вопроса удаляла всю секцию формы.
- Загрузка изображений на экран приветствия выдавала ошибку, а палитра тем не реагировала на клики.
- Окна подтверждения смещались за пределы экрана.
Несмотря на 2300+ тестовых прогонов, включая 391 автоматический браузерный тест (headless browser test — программная эмуляция действий без отрисовки окна), тесты проверяли лишь системную доступность элементов, упустив логические сбои интерфейса.
Анатомия компромисса: почему архитектура вытеснила продукт
Анализ сессии Codex показал реализацию около 135 архитектурных возможностей: неизменяемые ревизии данных (immutable revisions), офлайн-восстановление при сбоях, защита миграций базы данных, изоляция конкурентных запросов и строгие доменные границы.
Для высоконагруженной корпоративной системы эти свойства критичны. Однако для первой версии продукта они стали преждевременной оптимизацией. Агент попал в замкнутый цикл: проектируя защиту для гипотетических рисков, он создавал субагентов, писал для них тесты, находил новые уязвимости и углублял бэкенд, не доведя до ума базовый интерфейс.
Claude Code пошел по пути вертикального среза (vertical slice) — сквозной цепочки «интерфейс → логика → база данных → публикация». Это позволило быстро замкнуть продуктовую петлю. Причина перекоса — в двусмысленности требования «production-ready»: для бизнеса это работающий пользовательский сценарий прямо сейчас, а для инженера платформы — отказоустойчивость и безопасность. Без точных приоритетов агент сам выбирает, что считать готовностью.
Методология промптинга для агентных циклов
Наблюдаемые сбои позволяют сформулировать правила управления автономными агентами:
- Внедряйте фазу планирования (Planning Stage). Требуйте сначала составить архитектурный план и зафиксировать функции текущей итерации, отложив сложные ревизии или офлайн-режимы на потом.
- Задавайте 3–5 сквозных пользовательских сценариев. Формулируйте задачи через цепочки действий с критериями приемки (Definition of Done): «создать форму, опубликовать ссылку, отправить ответ и увидеть его в аналитике».
- Контролируйте интерфейс поэтапно. Переходите к новым блокам только после ручной или браузерной приемки ключевых экранов.
- Устанавливайте жесткие лимиты. Ограничивайте бюджет токенов, предельное время и число итераций агентов, предусматривая остановку для проверки человеком.
- Разделяйте роли. Используйте одного агента для быстрой сборки UI и проверки гипотез, а второго подключайте позже для точечного аудита безопасности и рефакторинга бэкенда.
Разбор подчеркивает: автономные агенты не отменяют инженерного контроля, а делают разработчика системным архитектором, чей результат зависит от декомпозиции задач и точного контроля критериев приемки.