Claude или ChatGPT для программирования решает рабочий процесс

Если выбирать Claude или ChatGPT для разработки по принципу самой умной модели, вы получите дорогой ответ на неверный вопрос. Команда покупает целую операционную систему для инженерной работы: модель, среду выполнения инструментов, права доступа, инструкции репозитория, интеграции, контроль оплаты и процесс проверки. Модель важна, но именно окружающая система определяет, дойдет ли хороший результат до продакшена безопасно.

Честное сравнение в 2026 году идет между Claude Code и Codex, а обычные Claude и ChatGPT нужны для обсуждения архитектуры, исследований и небольших фрагментов. Я видел, как команды неделями меняли модели, оставляя расплывчатые запросы, сломанные тесты и отсутствие критериев приемки. Они измеряли личные предпочтения, а не инженерный результат. Подходит тот вариант, который выполняет ваши типовые задачи с меньшим числом исправлений, предсказуемой ценой и доказательствами, которым может доверять проверяющий.

Сравнивайте агентов для программирования, а не окна чата

Claude и ChatGPT работают как универсальные помощники; Claude Code и Codex действуют как агенты, которые изучают репозиторий, редактируют файлы, запускают команды и доводят до конца задачу с изменениями в нескольких файлах. Это различие меняет все сравнение. Ответ в чате может выглядеть отлично, хотя импорты сломаны, миграции не применены, а тесты никто не запускал. Агент оправдывает свое место, когда замыкает цикл между запросом на изменение и проверенным состоянием репозитория.

Оценивайте отдельно три уровня. Уровень продукта включает тарифы учетной записи, администрирование, конфиденциальность и совместную работу. Уровень агента включает доступ к файлам, запуск команд, подтверждения, память, расширения и удаленную работу. Уровень модели включает рассуждение, генерацию программного кода, соблюдение инструкций, задержку и стоимость токенов. Фраза Claude лучше ChatGPT часто означает, что кому-то больше понравился текст одной модели в чате. Фраза Claude Code лучше Codex должна означать, что при одинаковых правах и постановке задачи он подготовил лучше проверенный патч.

Поэтому два инженера могут прийти к противоположным выводам, и оба будут честны. Один сравнивает Claude Sonnet 5 в Claude Code с более дешевой моделью Codex и строгими правами. Другой сравнивает Claude Opus 5 с GPT-5.6 Sol при высоком уровне рассуждения в облачной задаче. На результат влияют качество репозитория, файлы инструкций, доступные инструменты и готовность разработчика остановить агента.

Используйте чат для споров об архитектуре, незнакомых понятий и короткого программного кода, который вы вставите вручную. Выбирайте агента, когда нужны поиск по репозиторию, согласованные правки, команды, тесты и итоговый diff. Если в пробном запуске агентам не разрешили выполнить настоящие команды проверки проекта, такой тест не покажет, какой продукт подходит команде.

Поведение модели зависит от задачи и уровня рассуждения

Современные передовые модели обоих поставщиков достаточно сильны, поэтому форма задачи показывает более полезные различия, чем общий балл за программирование. OpenAI предлагает GPT-5.6 Sol для сложных рассуждений и разработки, Terra как баланс возможностей и цены, Luna для дешевой массовой работы. Anthropic предлагает Claude Sonnet 5 для программирования и масштабных агентных процессов, Claude Opus 5 для сложной и долгой инженерной работы. В обоих семействах можно обменять больше времени и токенов на более глубокое рассуждение.

В ограниченном изменении с понятными тестами скорость и дисциплина обычно полезнее максимального интеллекта. Например, нужно добавить поле в существующий ответ API, обновить сгенерированные фикстуры или исправить локальную ошибку типов. Сначала запускайте быструю модель и переходите к сильной, только если неудача показала нехватку рассуждения. Самая мощная модель для каждого исправления линтера зря расходует деньги и часто удлиняет обратную связь.

Длинные рефакторинги проявляют другое поведение. Смотрите, строит ли агент точную карту до правок, сохраняет ли местные соглашения, замечает ли сгенерированные файлы и удерживает ли цель после падения тестов. Побеждает не патч с наибольшим объемом программного кода. Нужен минимальный патч, который выполняет договоренность и легко проверяется. Я снижаю оценку агентам, которые переписывают посторонний программный код, даже если их версия выглядит чище. Умение соблюдать границы задачи относится к инженерному качеству.

Отладка показывает еще одно различие. Слабый запуск строит догадку по тексту ошибки и меняет первую подходящую функцию. Сильный запуск воспроизводит проблему, прослеживает данные до границы, где они меняются, добавляет проверку рядом с причиной, затем исправляет дефект. Попросите каждого агента показать упавшую команду и ту же команду после успешного исправления. Объяснения без таких доказательств не получают баллов в моих оценках.

Для интерфейса нужна визуальная проверка, а не заявление, что CSS должен работать. Дайте агенту запущенное приложение, целевой снимок экрана и право изучить отрисованный результат. Для инфраструктуры потребуйте пробный запуск, вывод плана или проверку конфигурации. Аккуратный текст модели ничего не гарантирует рядом с командой, меняющей состояние, поэтому система прав входит в тест.

Поставщики часто меняют модели по умолчанию и поведение агентов. Закрепляйте идентификаторы моделей в процессах через API, если важна воспроизводимость, записывайте уровень рассуждения и версию агента в журнал запуска. В продуктах по подписке псевдонимы и значения по умолчанию могут меняться, поэтому после значимого релиза повторяйте набор оценок, а не переносите вывод прошлого квартала.

Шесть задач из репозитория полезнее публичных тестов

Хорошая проверка использует задачи, которые команда уже решила, но скрывает исходное решение от агента. Публичные тесты помогают поставщикам находить регрессии и дают покупателю грубый сигнал о возможностях. Они не знают соглашений вашего монорепозитория, нестабильных интеграционных тестов, политики подтверждений и определения приемлемого патча. Выбирать агента по одной таблице популярно, потому что она дает простой ответ. Это ошибка: ваши расходы возникают на всем пути до принятого изменения.

Соберите небольшой набор задач с естественными различиями:

1. Исправьте воспроизводимый дефект, который затрагивает не меньше двух модулей.
2. Добавьте функцию с явным приемочным тестом.
3. Проведите рефакторинг без изменения наблюдаемого поведения.
4. Исправьте сборку или обновление зависимости, которое не проходит.
5. Проверьте pull request с одним неочевидным дефектом и безобидным шумом.

Шестую задачу посвятите своему риску: миграции, изменению прав, ошибке конкурентности или взаимодействию в интерфейсе. Для обоих агентов оставьте одинаковыми начальный коммит, инструменты, лимит времени и режим прав. Разрешите им повторить попытку после ошибки, потому что восстановление тоже входит в работу.

Храните описание проверки рядом с репозиторием. Этот фрагмент специально скучный: скучные критерии проще оценивать одинаково.

trial: checkout-refund
start_commit: 8f21c6a
limit_minutes: 35
allowed_commands:
  - make test-unit
  - make test-integration
  - git diff --check
acceptance:
  - duplicate webhook returns 200
  - refund is recorded once
  - existing payment tests pass
penalties:
  unrelated_file: 2
  unverified_claim: 3
  destructive_command: 10

Оценивайте результат, а не убедительность журнала. Я использую шесть критериев: правильность, доказательства проверки, соблюдение границ, восстановление после ошибки, усилия проверяющего и общие расходы. Правильность получает наибольший вес. Быстрый патч, который заставляет проверяющего заново восстанавливать рассуждение агента, нельзя назвать дешевым: работу просто переложили на человека.

Усилия проверяющего нужно измерять конкретно. Попросите его записать минуты на понимание diff, запрошенные исправления и возможность слить патч после обычной проверки. Число ответов агента храните только как диагностический показатель. Один долгий автономный запуск может требовать меньше человеческого времени, чем восемь быстрых обменов, но ушедший в сторону долгий запуск бывает намного хуже.

Если решение затронет всю команду, выполните каждую задачу несколько раз. Результаты агента различаются, и один удачный проход мало что доказывает. Исследовательская лаборатория не нужна: два или три запуска, слепая проверка там, где она уместна, и письменные заметки об ошибках покажут крупные различия. Сохраняйте неудачные запуски. Они часто обнаруживают пробелы в правах, недостающие инструкции репозитория или тесты, которые никогда не были детерминированными.

Экосистема инструментов определяет, сколько работы завершится

Claude Code и Codex теперь покрывают похожие области, но детали процесса все равно могут решить покупку. Claude Code доступен в терминале, поддерживаемых IDE, настольном приложении и браузере. Официальная документация описывает CLAUDE.md для инструкций репозитория, автоматическую память, подключения MCP, навыки, хуки, субагентов, команды агентов, GitHub Actions и GitLab CI/CD. Настольный продукт добавляет параллельные сессии с изоляцией Git, визуальную проверку diff, предпросмотр, локальные и удаленные среды.

Codex доступен через CLI, расширение IDE, настольную среду и облачную работу. Его конфигурация использует AGENTS.md для правил репозитория и поддерживает навыки, MCP, хуки, субагентов, локальные и облачные среды, рабочие деревья Git, неинтерактивное выполнение, SDK и интеграции, включая GitHub. Считать функции бессмысленно. Важно, помогает ли привычная инженерам среда легко проверять работу и проводить ревью.

Команда серверной разработки, которая живет в терминале, оценит составные команды, автоматические запуски без интерфейса и точные правила подтверждения. Продуктовой команде с несколькими задачами интерфейса важнее изолированные рабочие деревья, панели предпросмотра, снимки экрана и перенос сессии между локальной и удаленной средой. Компания под жестким регулированием посмотрит на управляемую конфигурацию, идентификацию, события аудита, работу с данными и соответствие облачного запуска сетевой политике.

MCP требует трезвой оценки. Он дает любому агенту доступ к трекерам задач, файлам дизайна, данным наблюдения, внутренней документации и системам развертывания. Каждый коннектор расширяет набор данных, которые агент читает, и действий, которые он выполняет. Сначала давайте MCP только чтение, открывайте узкий набор инструментов и разрешайте запись лишь после того, как сможете проверить аргументы и результат по журналу. Избыток инструментов снижает надежность агента, когда названия пересекаются или инструкции противоречат друг другу.

Файлы инструкций репозитория влияют непропорционально сильно. Запишите в них команды сборки, уровни тестов, архитектурные границы, правила для сгенерированных файлов и ожидания от ревью. Не вставляйте корпоративный справочник. Агенту нужны операционные ограничения, применимые во время редактирования. Если Claude Code получает зрелый CLAUDE.md, а Codex не получает AGENTS.md, вы проверили качество документации, а не агентов.

Первый месяц проваливается из-за процесса, а не модели

Внедрение агента успешно, только когда команда меняет путь работы от постановки до выпуска. Установить всем CLI и объявить инициативу с ИИ значит создать активность, а не пропускную способность. Инженеры выбирают легкие задачи, отправляют широкие запросы и радуются сгенерированному программному коду, а очередь на ревью и медленный набор тестов остаются прежними. Через месяц руководство видит платежи за подписки, но не связывает их с ускорением релизов.

Начните с договоренности о задаче. Каждая подходящая агенту задача должна описывать наблюдаемое поведение, желаемое поведение, границы, команду проверки и рискованные места, где требуется человеческое решение. Это не лишняя бумажная работа ради ИИ. Опытный инженер просит ту же информацию перед правкой незнакомого программного кода. Если никто не может сформулировать приемку в нескольких предложениях, агент выберет наиболее правдоподобное толкование, а проверяющие будут спорить с результатом, который им не задали.

Сначала ограничивайте патчи размером, который один проверяющий понимает за обычный рабочий отрезок. Агент быстро меняет десятки файлов, поэтому хочется объединить рефакторинг, обновление зависимости, функцию и уборку. Такой патч трудно проверять и еще труднее откатывать. Делите работу по наблюдаемому поведению, а уборку выносите отдельно, если у нее есть самостоятельная польза. Быстрый набор текста не оправдывает широкую зону поражения.

Возможности проверяющих становятся ограничением раньше, чем ожидает большинство основателей. Если каждый инженер запускает трех агентов параллельно, команда создает больше предлагаемых diff, чем старшие инженеры успевают изучить. Непроверенные ветки стареют, конфликтуют и требуют нового времени агента при переносе изменений. Ограничьте незавершенную работу, назначайте проверяющих до долгого запуска и измеряйте время от старта задачи до принятого слияния. Одна задержка генерации скрывает очередь, которую на самом деле ждет клиент.

У ошибки агента должен быть владелец. Если запуск остановился после нескольких сбоев инструментов, не разрешайте бесконечные повторы с более широкими правами. Ответственный инженер решает, нужно ли добавить контекст в инструкции репозитория, сломан ли тест или задачу следует выполнить человеку. Запишите решение. Повторяющаяся неудача на одном классе задач дает данные о процессе, а не говорит о невезении.

На еженедельном рабочем разборе изучайте несколько успешных и неудачных запусков. Ищите отсутствующие команды, повторяющиеся трудности с подтверждениями, слишком крупные diff, неверные предположения и тесты, которые прошли без проверки приемки. Меняйте инструкции репозитория или шаблон задачи, только когда видите повторяющуюся закономерность. Если добавлять правила после каждой странной ошибки, получится противоречивый файл, непонятный людям и агентам.

Не привязывайте оплату или рейтинг разработчика к строкам сгенерированного программного кода, часам агента или числу принятых работ. Такие метрики поощряют легкие задачи и слабое ревью. Измеряйте длительность цикла по классу задач, минуты проверяющего, дефекты после выпуска, переделки и расходы на агента. Команда должна получить признание за удаление ненужной задачи или исправление тестовой среды, даже если агент не написал программный код для продакшена.

Первый месяц должен закончиться одним операционным решением: какие категории работ агент выполняет регулярно, где нужна более сильная модель или старший проверяющий, а что остается только людям. Такая таблица маршрутизации превращает эксперимент в инженерную систему. Без нее каждый новый релиз модели заново открывает спор, в котором побеждает самый громкий случай.

Сделайте таблицу достаточно точной для исполнения. Обновление зависимости с успешными модульными тестами может выполнять экономичная модель с обычным ревью. Для миграции платежей могут потребоваться сильнейшая модель, владелец базы данных и пробный запуск на копии производственных данных. Изменение аутентификации может остаться у человека, пока агент пишет тесты или проверяет diff. Эти границы ускоряют инженеров и не заставляют придумывать политику риска во время каждой сессии. Пересматривайте их по фактам, а не по объявлениям поставщика.

Права доступа входят в качество программирования

Агент, которому нужны неограниченный shell и сеть, чтобы выглядеть компетентным, не готов к обычной командной работе. Дайте обоим продуктам минимальные полномочия, при которых задача все еще выполнима, затем оцените поведение на границе. Хороший агент запрашивает существенное право в нужный момент, объясняет команду и безопасно продолжает после отказа.

Разделяйте права на чтение, редактирование, выполнение, сеть и внешнюю запись. Чтение репозитория отличается от запуска его скриптов. Запуск тестов отличается от применения миграции базы данных. Создание локальной ветки отличается от открытия pull request или отправки сообщения в Slack. Команды попадают в неприятности, когда одно широкое подтверждение молча разрешает все эти действия.

Самая узнаваемая ошибка начинается с безобидной задачи по зависимости. Агент не может подключиться к реестру пакетов, и разработчик разрешает сеть на всю сессию. Затем скрипт жизненного цикла запускается с окружением разработчика, находит учетные данные и может обратиться к другому узлу. Ничего злонамеренного не должно произойти, чтобы система контроля уже оказалась плохой. Подтверждение привязали к сессии агента вместо конкретной команды, адреса и срока.

Используйте одноразовые ветки или рабочие деревья, не помещайте секреты в стандартное окружение и требуйте явного подтверждения разрушительных или внешних действий. Записывайте команды и вывод. Для облачных агентов проверьте хранение репозитория, сетевые настройки, передачу секретов и исключает ли ваш корпоративный тариф обучение на данных компании. Пользовательские настройки и корпоративный договор дают разные средства конфиденциальности.

Ревью программного кода остается ответственностью человека. Агент должен предоставить доказательства: измененные файлы, запущенные тесты, встреченные ошибки и оставшуюся неопределенность. Проверяющий изучает границы безопасности, миграции данных, конкурентность и поведение, которого тесты не видят. Быстрая генерация увеличивает объем программного кода, который команда предлагает, но не расширяет возможности ревью автоматически.

Цена имеет смысл только на принятую задачу

Цена подписки означает входной платеж и лимиты, а не стоимость выпущенной работы. Текущие индивидуальные тарифы Claude указывают Pro за $20 в месяц, Max 5x за $100 и Max 20x за $200. Текущие тарифы ChatGPT указывают Plus за $20 и варианты Pro за $100 и $200 с разными лимитами. Claude Code входит в подходящие тарифы Claude, Codex входит в подходящие тарифы ChatGPT. Лимиты, кредиты и временные акции меняются, поэтому закупка должна сохранить реальные условия оформления и утвержденную таблицу ставок.

Командная оплата добавляет еще один уровень. Стандартное место ChatGPT Business стоит $25 на пользователя при ежемесячной оплате или $20 на пользователя в месяц при годовой, минимум покупают два места, доступ включает ChatGPT и Codex. Claude Team включает Claude Code в каждое место и предлагает варианты с большим объемом работы. Корпоративные договоры обеих сторон сочетают оплату мест, кредиты или оплату по потреблению в зависимости от поколения контракта. Не переносите цену индивидуального тарифа в прогноз команды.

Ставки API показывают, почему маршрутизация моделей важна. OpenAI указывает для GPT-5.6 Sol $5 за миллион входных токенов и $30 за миллион выходных, для Terra $2,50 и $15, для Luna $1 и $6. Anthropic указывает для Claude Opus 5 цены $5 и $25. Для Claude Sonnet 5 до 31 августа 2026 года действует вводная цена $2 и $10, затем стандартная цена составит $3 и $15. Anthropic также пишет, что токенизатор Sonnet 5 может создавать примерно на 30 процентов больше токенов для того же текста, чем Sonnet 4.6, поэтому стабильная ставка за токен не гарантирует стабильную цену задачи.

Не сравнивайте эти числа простым умножением один раз угаданной длины запроса. Агенты повторно читают файлы, вызывают инструменты, сохраняют или сжимают контекст, создают токены рассуждения и могут запускать других агентов. Скидка на кеш помогает при повторяющемся контексте, а параллельная работа и максимальное рассуждение быстро увеличивают потребление. В таблице ставок Codex OpenAI приводит ориентир около $100-200 на разработчика в месяц с большим разбросом из-за модели, числа экземпляров, автоматизации и скоростного режима. Используйте это как подсказку поставщика для планирования, а не как свой бюджет.

Считайте цену принятой задачи по этой формуле:

accepted_task_cost = agent_charges + reviewer_minutes * loaded_hourly_rate / 60 + rework_minutes * loaded_hourly_rate / 60

Отдельно добавьте долю подписки или места, распределенную между выполненными задачами. Затем сравните медианную цену принятой задачи по типам. Модель, которая тратит вдвое больше токенов, но сокращает ревью и переделки, может быть дешевле. Дешевая модель с правдоподобными, но неполными патчами бывает самым дорогим пунктом списка.

Задайте правила маршрутизации после испытания. Ограниченное обслуживание отправляйте экономичной модели, обычную разработку функций сбалансированной, сложную отладку и широкие рефакторинги сильнейшей. Установите потолок расходов для автономных циклов и параллельных агентов. Когда задача достигает потолка, верните ее человеку вместе с журналом и состоянием репозитория, а не покупайте еще одну попытку без предупреждения.

Claude подходит командам, которые живут в терминале

Claude Code служит сильным вариантом по умолчанию для команд, чья работа начинается в shell и расширяется через явные инструменты. Совместимый с Unix неинтерактивный режим, CLAUDE.md, хуки, поддержка MCP и прямая автоматизация GitHub и GitLab удобны инженерам, которые хотят видеть и менять цикл команд. Текущие уровни Sonnet и Opus также дают понятную пару для обычной и сложной работы.

Выбирайте его, если разработчики уже управляют работой командами терминала, нуждаются в собственных хуках вокруг правок или хотят один движок агента в CLI, IDE, настольном приложении, браузере и CI. Он также подходит, когда Agent SDK соответствует планируемому внутреннему уровню автоматизации. Все это не отменяет проверки лимитов при ежедневной параллельной работе. Общие лимиты кажутся щедрыми на демонстрации и тесными, когда несколько инженеров одновременно запускают долгие сессии.

Claude Code подходит хуже, если утвержденный процесс зависит от поверхности продукта или административного контроля, которого нет в вашем контракте, либо испытание показывает постоянные лишние правки в вашем репозитории. Не покупайте бренд в надежде, что запросы исправят несовпадение процессов. Попросите Anthropic показать точные средства идентификации, работы с данными, регионом и потреблением, которые нужны отделам безопасности и финансов.

ChatGPT подходит командам, которым нужна одна широкая среда

ChatGPT вместе с Codex служит сильным вариантом по умолчанию, когда компания хочет держать разработку, исследования, файлы, общий анализ и агентные процессы в одном пространстве OpenAI. Codex охватывает локальные CLI и IDE, настольную работу и облачное выполнение, а система расширений включает инструкции репозитория, MCP, навыки, хуки, субагентов и автоматизацию. Команды, уже использующие ChatGPT для продуктовых и операционных задач, могут не создавать еще одну учетную и административную границу.

Выбирайте его, если разработчикам нужно переходить между локальной работой с репозиторием и делегированными облачными задачами, если изоляция рабочих деревьев помогает параллельным изменениям или если Codex SDK и процесс GitHub подходят вашей внутренней платформе. Уровни Sol, Terra и Luna в GPT-5.6 дают практичную шкалу возможностей и цены. Оплата кредитами по токенам также делает тяжелое использование агента заметным, хотя финансам все равно придется связать кредиты с принятыми задачами.

Codex подходит хуже, если общие агентные кредиты затрудняют распределение расходов, нужная модель или среда недоступна вашему пространству либо облачные задачи противоречат политике репозитория или сети. Доступ по тарифу ChatGPT не включает использование OpenAI API; API оплачивается отдельно. Эта деталь удивляет команды, которые создают прототип в интерактивном режиме, а потом автоматизируют тот же процесс.

Большинству команд нужен путь к смене поставщика

Один основной агент сокращает расхождение инструкций, время обучения и поддержку. Привязка каждого процесса к одному поставщику создает другую проблему. Держите команды репозитория, приемочные тесты и архитектурные правила независимыми от обоих продуктов, затем адаптируйте тонкий слой инструкций в CLAUDE.md и AGENTS.md. Источником истины должны оставаться репозиторий и CI, а не история беседы.

Разумное внедрение начинается с пяти-десяти инженеров или одной полной продуктовой команды на четыре недели. Сначала используйте испытание из шести задач, затем отслеживайте производственную работу по категориям. Каждую неделю проверяйте расходы, принятые патчи, пропущенные дефекты, заблокированные запуски и время ревью. Уберите показатели тщеславия, такие как число сгенерированных строк или сообщений в чате.

Выберите основного агента для ежедневной работы, а второго оставьте для небольшого набора случаев: проверки рискованного diff, новой попытки после повторных ошибок или проверки зависимости проблемы от модели. Не разрешайте двум агентам редактировать одно рабочее дерево. Давайте им одинаковые начальные коммиты и сравнивайте diff, когда нужна независимая попытка.

Когда руководители просят меня выбрать до появления данных по задачам, я советую купить минимальные тарифы для честного испытания, а сэкономленный бюджет потратить на порядок в репозитории. Надежная команда тестирования, быстрые фикстуры и ясная ответственность улучшают работу обоих агентов. В моем Team & AI Audit такие данные о процессе и расходах помогают найти места, где ИИ сокращает инженерные затраты, прежде чем компания начнет широкую перестройку.

У решения есть срок годности. Повторяйте набор испытаний после крупных изменений модели, цены или политики, а также после существенных изменений базы программного кода или структуры команды. Выбор между Claude и ChatGPT не требует вечной верности. Это измеримое операционное решение, и репозиторий должен доказать, когда его пора изменить.