Я протестировал Claude Code и OpenCode на реальном рефакторинге. Вот что получилось

Каждую неделю кто-нибудь пишет: «Ну всё, мы приплыли. ИИ отобрал у нас работу». А ещё через неделю кто-то выкладывает скриншот, как очередной агент удалил .env-файл, и подписывает его: «лол».

Обе реакции понятны. Но ни одна из них не является доказательством. Чтобы получить более полезный ответ, я сравнил Claude Code и OpenCode на одном и том же реальном рефакторинге: переносе сложного дашборда на Next.js 15 и React 19 с глубокой цепочкой пропсов на Zustand.

Цель была не выяснить, какой инструмент красивее пишет код с чистого листа. Меня интересовало другое: как каждый из терминальных ИИ-агентов справится с реальной миграцией большого проекта — где есть TypeScript, callback-пропсы, общее состояние интерфейса, проверка сборки и такая вложенность компонентов, что цепочка пропсов начинает восприниматься как личное оскорбление.

Результат оказался не в духе «ИИ заменил разработчиков» и не «агенты бесполезны». Всё практичнее: оба справились с задачей, оба споткнулись об одинаковые проблемы окружения, но один сделал более качественный первый проход. И самое интересное — не в успехах, а именно в ошибках.

#Что именно тестировалось

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

OpenCode идёт другим путём. Это открытый проект с поддержкой разных моделей — Claude, GPT, Gemini и локальных LLM. Основной акцент — на гибкости и прозрачности работы.

Для чистоты эксперимента оба инструмента работали на одной модели — Claude Opus 4.6. Так оценивалась не сама модель, а уровень оркестрации и управления процессом, который даёт каждый агент.

Важно: это не научное исследование. Один проект, одна задача, один компьютер и один промпт. Это практический отчёт, а не абсолютный рейтинг.

#Задача рефакторинга

Тестовый проект — дашборд на Next.js 15, React 19, TypeScript и Tailwind. Кодовая база была намеренно неприятной, но вполне реалистичной:

• дашборд управления проектами;
• моковые данные;
• шесть уровней вложенности компонентов;
• callback-пропсы, проходящие через компоненты, которые ими вообще не пользуются;
• глобальное состояние, поднятое слишком высоко в дереве компонентов.

Всё состояние находилось в dashboard/page.tsx и передавалось вниз через множество компонентов:

DashboardPage
├─ DashboardHeader
├─ Sidebar
├─ ContentArea
│  ├─ ProjectList
│  │  └─ ProjectCard
│  │     └─ TaskRow
│  └─ StatsFooter
└─ TaskModal

Например, один только ProjectCard получал восемь пропсов, большинство из которых просто прокидывал дальше в TaskRow. Идеальный кандидат на миграцию в Zustand.

Требования были чёткими:

• создать Zustand Store для пользователя, проектов и UI;
• убрать prop drilling;
• удалить неиспользуемые пропсы;
• сохранить полную типобезопасность TypeScript;
• не сломать существующее поведение приложения.

#Промпт

Оба инструмента получили абсолютно одинаковое задание:

• полностью изучить кодовую базу;
• создать Zustand Store;
• перевести компоненты на работу со Store;
• удалить лишние пропсы;
• запускать tsc после каждого серьёзного изменения;
• в конце выполнить сборку проекта;
• вести файл MISTAKES.md — записывать все ошибки, причины и способы исправления.

Последний пункт оказался особенно полезным. Вместо магического «оно как-то заработало» агенты были вынуждены документировать свои ошибки и ход рассуждений. А это критически важно, если вы хотите понимать, что именно ИИ делает в вашем проекте.

#Как справился Claude Code

Claude Code начал правильно — сначала подробно изучил кодовую базу:

• открыл page.tsx;
• проследил импорты;
• проанализировал все дочерние компоненты;
• составил карту состояния и связей между компонентами.

Только после этого он начал писать код. Созданный Zustand Store выглядел логично: состояние пользователя, проектов, интерфейса и отдельные действия для обновления задач и управления модальными окнами.

Ошибка №1. Поломка npm-шима. Первая проблема вообще не относилась к коду:

npx tsc --noEmit
Cannot find module '../lib/tsc.js'

После установки Zustand пересоздались скрипты в node_modules/.bin, и обёртка TypeScript стала ссылаться на неверный путь. Claude правильно диагностировал это как ошибку окружения и начал запускать бинарники напрямую:

node node_modules/typescript/lib/tsc.js --noEmit
node node_modules/next/dist/bin/next build

Типичная проблема реальных проектов, которую редко показывают в красивых демо.

Ошибка №2. Рефакторинг сверху вниз. Claude начал менять корневой компонент раньше, чем обновил дочерние. TypeScript немедленно сообщил:

Type '{}' is missing the following properties from type 'SidebarProps'

Причина проста: родитель уже перестал передавать пропсы, а дочерние компоненты всё ещё их ожидали. Пришлось менять стратегию — двигаться снизу вверх:

TaskRow → ProjectCard → ProjectList → ContentArea → DashboardPage

После этого миграция пошла гладко.

Ошибка №3. Неполная цепочка изменений. Claude убрал проп user из ContentArea, но тот всё ещё передавался в StatsFooter, который пока не перевели на Store. TypeScript снова поймал проблему:

Property 'user' is missing...

Исправление простое, но ситуация хорошо показывает, насколько тесно связаны компоненты в глубоко вложенных React-приложениях.

#Итог Claude Code

#Как справился OpenCode

OpenCode начал иначе. Первым делом он построил карту проекта через поиск всех .tsx-файлов, затем извлёк типовую информацию — и только потом приступил к изменениям. Он создал практически такой же Zustand Store и не стал изобретать лишние архитектурные конструкции вроде middleware, провайдеров или дополнительных абстракций.

И дальше произошло самое скучное для любителей драматичных сравнений: оно почти сразу заработало.

OpenCode столкнулся ровно с теми же проблемами окружения — сломанный tsc и сломанная команда сборки Next.js. Но в отличие от Claude:

• не допустил ошибок в порядке рефакторинга;
• не пропустил зависимые компоненты;
• завершил миграцию без ошибок на уровне кода.

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

#Что на самом деле показал этот тест

Самый важный вывод оказался неожиданным. Тест не показал, что один агент лучше другого. Он показал три вещи.

1. Модель — это ещё не весь инструмент. Оба агента использовали одну и ту же модель, но вели себя по-разному.

2. Порядок рефакторинга критически важен. Большинство ошибок возникает не из-за кода, а из-за неправильной стратегии миграции.

3. Проверка должна быть частью промпта. Регулярный запуск TypeScript и сборки спасает от постепенного накопления ошибок.

#Как правильно писать промпты для CLI-агентов

После этого теста я бы всегда добавлял в большие рефакторинги такие правила:

• Работать снизу вверх — сначала листовые компоненты, потом родительские.
• Логировать каждое изменение — даже если ошибки не было.
• Не позволять агенту расширять область задачи — никаких лишних middleware, провайдеров и «улучшений архитектуры», если их не просили.
• Проверять побочные эффекты — любой callback может содержать аналитику, уведомления или навигацию; её легко случайно потерять.

#Claude Code или OpenCode: что выбрать

Если коротко — оба инструмента рабочие, и выбор зависит от задачи:

• Берите Claude Code, если нужна осторожность, строгие подтверждения действий и подробные объяснения каждого шага — удобно на критичном или незнакомом коде, плюс тесная интеграция с экосистемой Claude и MCP.
• Берите OpenCode, если важна гибкость в выборе моделей (Claude, GPT, Gemini, локальные), прозрачность и максимально чистый первый проход на рутинной миграции.

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

#Вывод

Этот тест изменил мой взгляд на терминальных ИИ-агентов. OpenCode оказался быстрее и аккуратнее в конкретной задаче. Claude Code — осторожнее и лучше объяснял свои решения. Но главный вывод вообще не про инструменты.

CLI-агенты не заменяют инженерное мышление. Они ускоряют работу тех разработчиков, которые умеют:

• выбрать правильную стратегию миграции;
• понимать архитектуру проекта;
• определять риски;
• отличать успешную сборку от действительно правильного результата.

Больше всех выиграют не те, кто полностью игнорирует ИИ, и не те, кто слепо ему доверяет. А те, кто способен сказать агенту: с чего начать, где остановиться и что ни в коем случае нельзя сломать.

Оставьте себе агента, компилятор и файл MISTAKES.md. Именно там происходит настоящая работа разработчика.

Разбираем ИИ-кодинг каждый день — без хайпа и паники. Подпишитесь на наш Telegram, чтобы не пропустить следующий разбор.