# Как Claude Code vs OpenHands меняет экономику миграции

> Сравниваем Claude Code vs OpenHands по выбору модели, работе с MCP, интеграции с CI, стоимости миграции и ежемесячным часам на поддержку.

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

Claude Code и OpenHands предлагают разные компромиссы. Claude Code дает тесно связанный набор инструментов вокруг агента программирования Anthropic с документированными настройками проекта, хуками, конфигурацией MCP и официальным GitHub Action. OpenHands проводит более широкую границу между моделями и развертыванием через CLI, облачный сервис, среду выполнения с открытым исходным кодом и Software Agent SDK. Ни один выбор не будет всегда безопаснее или дешевле. Ответ зависит от того, от чего именно вы хотите иметь возможность отказаться и как часто рассчитываете этой возможностью пользоваться.

## Переносимость - это выбор способа работы, а не модель в списке

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

В OpenHands выбор модели вынесен в отдельный, явно заданный слой конфигурации. Документация CLI показывает провайдера, модель, API-ключ и необязательный базовый URL в `~/.openhands/agent_settings.json`; временные переопределения через переменные окружения используют `LLM_MODEL`, `LLM_API_KEY` и `LLM_BASE_URL`. SDK следует соглашению LiteLLM об именовании, например `provider/model_name`, поэтому эксперименты с моделями становятся обычной частью архитектуры. Команда, которой нужно запускать внутреннюю конечную точку, сравнивать нескольких провайдеров или использовать локально размещенную модель, получает от такой границы реальную свободу выбора.

Claude Code позволяет выбирать поддерживаемые модели Claude через параметр модели, псевдонимы, настройки и переменные окружения. Он также может работать через API Anthropic и поддерживаемые корпоративные платформы. Это выбор внутри продукта, построенного вокруг Anthropic, а не нейтральная к провайдерам оркестрация. Если требование отдела закупок звучит так: «Мы должны заменить поставщика модели, не меняя среду агента», одного Claude Code недостаточно. Если требование звучит так: «Нам нужно переходить между одобренными способами развертывания Claude, не перестраивая работу разработчиков», он может выполнить его с гораздо меньшим количеством дополнительных компонентов.

До сравнения инструментов сформулируйте нужный запасной выход одним предложением. Например: «запускать одну проверку pull request на моделях двух провайдеров», «не выпускать исходный код за пределы контролируемой среды выполнения» или «заменить интерактивный клиент, сохранив общие инструменты MCP». Если никто не может назвать событие, которое запустит переход, переносимость превращается в страховку без описанного страхового случая. За нее придется постоянно платить расхождением конфигураций.

## Выбор модели перенести проще всего

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

Здесь OpenHands дает более понятную среду для экспериментов. Можно параметризовать провайдера, модель, базовый URL и учетные данные, а затем прогнать фиксированный набор задач через CLI или SDK. Это полезно, когда разнообразие моделей задано бизнес-требованием. Но настройку под конкретную модель никто не отменяет. Документация OpenHands предупреждает, что для эффективной работы локальных моделей нужны подходящее оборудование и модели, рассчитанные на выполнение инструкций и агентный режим. Ответ от совместимой конечной точки API еще не доказывает, что модель завершит задачу в репозитории.

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

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

```json
{"case":"auth-cookie-regression","agent":"openhands","model":"provider/model","exit_code":0,"tests_passed":true,"forbidden_paths_changed":[],"human_review_minutes":11}
```

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

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

## В конфигурации рабочего процесса скрыта цена перехода

Инструкции репозитория выглядят как проза, но работают как программная логика. Claude Code обычно получает указания проекта через `CLAUDE.md`, настройки в `.claude/`, разрешения, хуки, команды, навыки и плагины. У OpenHands есть собственные настройки агента, варианты среды выполнения, микроагенты или правила репозитория, настройки безопасности, управление диалогом и сборка через SDK. Копирование предложений сохраняет только самый заметный слой.

Рассмотрим инструкцию: «Перед полным набором тестов запусти тесты только для измененной части». В одной конфигурации хук может запрещать коммит, пока команда не завершится успешно. В другой это совет, который модель может трактовать по-своему. Эти механизмы неравноценны. У хука есть событие, условие совпадения, входные данные, код завершения и сценарий сбоя. Соблюдение промпта вероятностно. Во время миграции отнесите каждое поведение к одному из типов: инструкция, детерминированный контроль, граница учетных данных или привычка оператора. Восстановите каждый пункт с прежним уровнем принуждения.

Храните перечень рабочих процессов в репозитории, а не в документе к совещанию:

```yaml
behaviors:
  - id: protect_generated_client
    trigger: before_file_write
    enforcement: block
    paths: ["src/generated/**"]
    evidence: "tool event plus denied path"
  - id: focused_tests
    trigger: after_edit
    enforcement: advise
    command: "./scripts/test-changed"
    evidence: "command and exit code"
  - id: release_approval
    trigger: before_command
    enforcement: human
    command_pattern: "./scripts/release*"
    evidence: "approver identity and decision"
```

Точный формат файла выбираете вы. Его задача - показать семантику, которую скрывает каталог конкретной платформы. Во время пробного перехода с Claude Code на OpenHands пометьте каждое поведение как встроенное, адаптированное, вынесенное наружу или удаленное. Для «адаптированного» нужны ответственный и тест. Для «удаленного» нужно явное принятие риска, а не молчаливый пропуск.

Безопасность требует отдельной проверки равноценности. Запрос подтверждения - это не песочница, а песочница - не политика учетных данных. Запишите, какой процесс может читать секреты репозитория, выходить в сеть, устанавливать зависимости, менять историю git и писать за пределами рабочей области. Затем проверяйте отказы на практике, а не доверяйте названиям настроек. Если перенесенный агент выполняет больше задач благодаря более широким учетным данным, он не сохранил качество процесса, а изменил риск. Сравните и момент принятия решения человеком. Десять запросов без достаточного контекста в одном запуске CI провоцируют слепое подтверждение, а один структурированный запрос с командой, целью и причиной можно осмысленно проверить. Переносимость должна сохранять решение, которое проверяющий действительно способен принять.

Популярный совет поддерживать одинаковые промпты для обоих агентов ошибочен. Одинаковый текст дает внешнюю симметрию, хотя названия инструментов, модели событий, разрешения и загрузка контекста различаются. Поддерживайте одну короткую, нейтральную к платформе политику для неизменных правил, а для каждого агента пишите тонкие адаптеры. Общая политика может запрещать изменения в каталогах сгенерированных файлов; один адаптер обеспечит это через разрешения или хуки Claude Code, другой применит контроль безопасности OpenHands или внешнюю проверку файловой системы. Цель - равноценность, а не одинаковые файлы.

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

## Совместимость с MCP не делает интеграции переносимыми

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

Руководство Claude Code по MCP различает локальную, проектную и пользовательскую области. Проектная конфигурация лежит в `.mcp.json`, может храниться в системе контроля версий и требует подтверждения перед использованием. Руководство также описывает соединения через stdio и удаленный HTTP, подстановку переменных окружения, OAuth для удаленных серверов и команды вроде `claude mcp list`. В документации по отладке разобран сбой, который часто встречается в системах инструментов: относительные пути к исполняемым файлам вычисляются от каталога запуска, поэтому сервер MCP работает в одном терминале и ломается в CI или из другого подкаталога.

Руководство по SDK OpenHands настраивает серверы через словарь `mcpServers` и умеет фильтровать открытые инструменты регулярным выражением. В примере с OAuth токены сохраняются через базовый клиент, а первый вход требует действий в браузере. В руководстве прямо сказано, что такой поток не подходит для полностью автоматических headless-задач, если провайдер не предлагает другой способ аутентификации. Эта оговорка важнее галочки «Поддерживает OAuth».

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

1. Запустите сервер из корня репозитория и из вложенного каталога.
2. Получите список инструментов и сравните названия вместе со схемами входных данных.
3. Вызовите один инструмент только для чтения с известным результатом и один запрещенный инструмент записи.
4. Выполните перезапуск без кэшированных учетных данных в headless-среде.

Четвертая проверка находит самые дорогие сюрпризы. Браузерная сессия разработчика может месяцами скрывать пробел в аутентификации CI. Локальная команда stdio может зависеть от менеджера запуска пакетов, которого нет в производственном образе. Проектный файл может ссылаться на переменную окружения, доступную на ноутбуках, но отсутствующую в pull request из форков.

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

## CI показывает разницу в архитектуре

CI превращает помощника в производственную зависимость. В интерактивной работе можно уточнить задачу, войти через браузер, заметить странный diff и вручную повторить запуск. Для задания на pull request нужны определенные событие, набор разрешений, рабочая область, политика секретов, тайм-аут, контракт результата, правило параллельного запуска и реакция на сбой. Выбор между Claude Code и OpenHands становится намного яснее, когда эти понятия записаны.

Claude Code предлагает официальный путь через GitHub Action и вариант ручной конфигурации рабочего процесса. В документации показан параметр `claude_args` для ограничений и выбора модели, включая ограничение числа шагов, выбор модели и конфигурацию MCP. Так проще перейти к разбору задач, работе с pull request или проверке в GitHub. Связь компонентов здесь намеренная: ваш процесс зависит от входных параметров action, аутентификации Anthropic, разрешений Claude Code и поведения конкретного релиза.

OpenHands описывает интеграцию с CI через Software Agent SDK и составные GitHub Actions для задач вроде проверки pull request. Путь через SDK дает больше контроля над сборкой агента, инструментами, событиями, обратными вызовами и средой выполнения. За этот контроль вы платите сопровождением дополнительного прикладного кода. Если вам нужны GitLab, внутренняя очередь или собственная политика песочницы, именно ради такого владения можно затевать миграцию. Если GitHub - единственная управляющая система, замена поддерживаемого action собственной оберткой над SDK может стать дорогим способом получить тот же результат.

Считайте результаты CI программным интерфейсом. Не заставляйте следующие шаги извлекать данные из разговорной прозы. Требуйте код завершения и объект результата со стабильными полями:

```json
{"status":"changes_proposed","commit":"abc1234","checks":{"unit":"passed","lint":"passed"},"review_required":true,"artifacts":["agent.patch","run-events.jsonl"]}
```

Режим print в Claude Code поддерживает структурированные форматы результата для скриптов, а OpenHands предлагает headless-режим и работу через SDK с программными событиями. Названия полей выше задают контракт вашей обертки, а не утверждают, что один из инструментов возвращает именно такой объект. Создайте по одной обертке для каждой платформы, а остальную часть CI привяжите к своему контракту.

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

CI также показывает, кто отвечает за лицензии, образы и обновления. OpenHands можно запускать локально с открытым исходным кодом, в его облачном сервисе или через SDK, поэтому кому-то придется выбирать и сопровождать границу развертывания. Claude Code переносит больше решений о среде выполнения внутрь продукта, но за версии action, разрешения, секреты и правила репозитория по-прежнему отвечаете вы. Ни один вариант не убирает операционную работу, они распределяют ее по разным статьям.

## Стоимость миграции нужно считать в инженерных часах

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

Используйте расчет окупаемости, который сможет проверить основатель компании:

```text
migration_hours = inventory + adapters + integration_tests + ci_rebuild + training + rollback_plan
monthly_net_savings = current_maintenance_hours - candidate_maintenance_hours
                    + model_or_runtime_savings_in_engineer_hours
break_even_months = migration_hours / monthly_net_savings
```

Переведите денежную разницу в инженерные часы по полной часовой ставке, но оставьте рядом исходные денежные суммы. Экономия на API и время сотрудников неравнозначны с точки зрения работы компании. Более низкий счет за модель может помочь финансовому отделу, пока платформенный инженер по-прежнему теряет день каждый месяц на исправление совместимости.

Допустим, изучение занимает 24 часа, адаптеры рабочего процесса - 48, работа с MCP и учетными данными - 32, перестройка CI - 40, оценка - 36, обучение - 16, а подготовка отката - 12. Всего миграция требует 208 часов. Если OpenHands каждый месяц сокращает расходы на модель и среду выполнения в эквиваленте 12 инженерных часов, но добавляет 8 часов платформенной поддержки, чистая экономия составит 4 часа. Окупаемость займет 52 месяца. Если ограничение поставщика иначе потребует 80 часов в каждом из двух ожидаемых процессов закупки, осторожно учтите предотвращенные расходы; не выдавайте их за ежемесячную производительность.

Рассчитайте три варианта: оптимистичный, базовый и неблагоприятный. В неблагоприятный включите один сломанный адаптер провайдера, одно изменение аутентификации MCP и ухудшение модели, из-за которого понадобится перенастройка. Если решение работает только в оптимистичном варианте, это ставка на неизменность зависимостей. Для небольшого экспериментального процесса такой риск может быть приемлем, но для системы, проверяющей каждый pull request, это слабое обоснование.

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

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

## Ежемесячная поддержка определяет цену переносимости

Поддержка - это регулярная плата за переносимость. Измеряйте ее по причинам, а не одной общей категорией «ИИ-инструменты». Полезный журнал разделяет обновления агента, перенастройку модели, смену провайдера, работу с серверами MCP, ремонт CI, проверку безопасности, помощь разработчикам и оценочные запуски. Без такого разделения гибкую платформу обвинят в изменениях модели или припишут ей заслугу за работу, которую незаметно выполнила другая команда.

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

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

OpenHands часто выигрывает, когда выбор провайдера или способа развертывания имеет конкретную деловую ценность, когда агент нужно встроить в более крупное приложение или когда собственная обработка событий CI и контроль песочницы оправдывают дополнительные слои. В поддержку входят выбор среды выполнения или облака, совместимость с провайдерами моделей, изменения SDK или CLI, образы, политика безопасности, интеграции и та же дисциплина оценки. Широкая граница полезна тем, что позволяет заменять части. Но она создает больше комбинаций компонентов, способных сломаться.

Установите бюджет поддержки до внедрения. Для небольшого производственного развертывания это может быть половина дня в месяц плюс ежеквартальное окно оценки; для платформы агентов во множестве репозиториев бюджет будет больше. Точная величина менее важна, чем действия при ее превышении. Заранее решите, сократите ли вы матрицу моделей, отключите сервер MCP, зафиксируете релиз, сузите область CI или назначите владельца платформы. Фраза «Мы будем поддерживать оба варианта в актуальном состоянии» не описывает рабочий процесс.

Параллельный запуск заслуживает отдельной строки. Оставить Claude Code разработчикам, а OpenHands использовать для автоматизации может быть разумно, потому что процессы различаются. Дублирование каждой интерактивной команды, сервера MCP, задания CI и политики обычно удваивает объем проверок, но не ценность. Используйте общие тестовые сценарии и нейтральные к агентам политики, а затем выберите одну основную реализацию для каждого процесса.

## Проба на двух репозиториях отвечает на трудные вопросы

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

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

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

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

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

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

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

## Выбирайте ограничение, которое проживет два года

Подходящая платформа соответствует ограничению, которое сохранится, а не функции, которая впечатляет в этом квартале. Выбирайте Claude Code, когда команде нужен цельный процесс вокруг Claude, она использует GitHub или простую headless-автоматизацию и больше выигрывает от сокращения платформенных компонентов, чем от смены провайдеров. Выбирайте OpenHands, когда выбор модели или среды выполнения записан в требованиях, агента нужно встраивать через SDK или контроль над развертыванием и CI оправдывает дополнительные уровни владения.

Оставляйте Claude Code и выборочно добавляйте OpenHands, когда у конкретного процесса другие ограничения. Для регулируемой автоматизации может понадобиться контролируемая среда выполнения, а интерактивная разработка останется в Claude Code. Сервис оценки моделей может жить в OpenHands, пока небольшая продуктовая команда сохраняет более простой повседневный инструмент. Разделяйте по рабочим процессам, а не по предпочтениям разработчиков, иначе в каждом репозитории появятся два наполовину заброшенных пути.

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

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

Во время Team & AI Audit в oleg.is я рассматриваю выбор агента как решение об операционной модели: пятидневный аудит за $5,000 должен найти минимум $50,000 экономии в год, иначе он бесплатен. Независимо от того, заказываете вы внешнюю проверку или используете собственную таблицу, требуйте от решения такой же дисциплины.

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