Сейчас реально стало тяжелее объяснять разницу между «накидал на коленке» и архитектурным подходом.
Это заказчикам довольно быстро объяснят хакеры, которые будут ломать такие поделки пачками и использовать для "заработка". Вот пару раз попадет заказчик на деньги тогда и задумается.
Так и есть. Подписка за 20 евро, мне не хватает лимитов, следующее по цене это 100 евро, но тяжко такое одному тянуть, а лимитов для одного там с избытком, с коллегой на работе решили на двоих одну брать.
Если не привязываться к провайдеру, то следующая подписка GitHub Copilot Pro+ за 40$. Если не привязываться к одному семейству моделей, то можно использовать например Claude Pro за 20 (или OpenAi Codex за 20) + Copilot Pro за 10 + OpenCode Go за 10. Если не привязываться к подписочным моделям и платить за api, то можно использовать openrouter или OpenCode Zen или вообще редактор Zed и их интеграцией.
В этой связи хотелось бы отметить следующее - применение ИИ, на данный момент, сильно подорвало систему преемственности кадров. Молодой специалист приходил как раз на рутинные должности подготовки и обработки информации (кодер-джун, помощник юриста, составляющий типовые исковые заявления и т.п.).
Я бы еще добавил один неочевидный момент. Рутинные задачи нужны не только для передачи знаний и воспитания специалистов. Они нужны для формирования команды, для распределения нагрузки внутри команды, так как на рутинных задачах можно просто отдохнуть от "творческих задач".
Проблема индустрии в том что сюда идут за длинным рублем, в виду того что в других областях крайне сложно заработать сопоставимые деньги. Все это сопровождается внедрением ии, охлаждением экономики - что только усугубляет проблемы.
Это постоянно происходит, до ИТ все шли в юристы, до юристов, делать евроремонты, до этого были 90-е и шли в челноки. Был ажиотаж среди таксистов, дальнобойщиков, ювелиров. В медицине всегда стремились в гинекологи или стоматологи. Или в косметологию. Даже в ИТ постоянно выделялись какие-то области куда шли, то CV, то ML, сейчас вон ИИ. Просто про это все не так было известно как сейчас, так как не было интернета и разных соцсетей.
Это было правдой когда ThinkPad был частью IBM. После того как подразделение ThinkPad было продано Lenovo, данная линейка скатилась в яму. Перечислю то что стало хуже:
Корпус был из титано-магниевого сплава, а стал из унылого пластика.
Процессор распаян на материке. Лично у меня два раза отпадал процессор от перегрева и приходилось сдавать в ремонт и делать реболлинг.
Формат экрана поменяли с 3:4 на 9:16, из рабочей машины сделали мультимедийную машину.
Убрали лампочку подсветки, вместо этого вставили унылую клавоподсветку.
После проблем с перегревом, хотя раз в год менял термопасту, делал чистку, перешел на маки, и забыл про эти все проблемы как про страшный сон. Алюминиевый корпус весь рассеивает тепло, в отличии от пластикового.
И подобные статьи явно провоцируют у многих желание "подсунуть текст закона на вход AI-фабрике и через неделю получить готовую систему
Это отлично. Это великий фильтр для управленцев и руководителей всех уровней. Пусть они генерит тонны кода сами, попадают на деньги из-за багов и штрафов. Пусть они увольняют разработчиков, а потом нанимают тех же людей за намного большие деньги.
Провайдеры ИИ вряд ли схлопнутся. И в идеальной картине мира нужна отдельная инфраструктура для генерации, доставки токенов и любого взаимодействия между агентами, типа как для газа/воды/электричества. С наймом людей все сложнее, есть автоматизированное производство, со станками чпу, сканерами штрих кодов, роботами доставщиками на складе, и любыми другими автоматизациями. Что будет если часть или вся автоматизация пропадет? Такое производство вряд ли сможет нанять людей как проще так и дешевле. Потому что автоматизация вытесняет часть профессий, люди переучиваются. Попробуй сейчас найти токаря, фрезеровщика, того же кладовщика. И это уже не говоря про офисную и управленческую автоматизацию. Даже если получиться заместить людей, то сильно ли долго такое производство продержится в условиях конкуренции? ИИ это тоже автоматизация, или мета-автоматизация. Да пока зависимости от этой ИИ автоматизации не очень критичная, но это быстро меняется с каждым днем.
Какие-то модели с открытыми весами может и доберутся, но вот железо доступнее не станет.
Предполагаю что это просто очередной передел рынка и расширение существующих монополий. Какое-то количество компаний перейдет на ИИ полностью или почти полностью, как только это произойдет, для этих компаний начнется падение. 5-10-20 месяцев, не важно, код в любом случае так деградирует, что эти компании просто не смогут обслуживать клиентов, а попытка привлечь людей не сработает из-за кучи непонятного кода. Но перед тем как это случиться, эти компании и их инвесторов просто выжмут провайдеры ИИ постоянным повышением цен, ужесточением лимитов и прочими методами.
Проблема джунов и их развития на моей памяти где-то с 2010 года. Разработка была другая, было больше свободы и доступа к проду, было меньше информации, больше ошибок. И софт был разный, со своими особенностями, и клиенты за нужные им функции платили лояльностью и обратной связью. Были стартапы где тоже можно было опыта получить. Потом все стало одинаковое, и началась погоня за девятками стабильности, контуры доступа, всякий маркетинг и сео. В таких условиях опыт особо не получишь, прод сам не сломаешь, сам не починишь, сидишь в песочнице из линтеров, чекеров, тестов. Сейчас опыт можно получить только в крупных компаниях. И есть такое ощущение, что роль кузнецы кадров на себя возьмут стартапы, и их будут покупать не из-за перспективной идеи, а из-за собранной и сработанной команды.
Сначала начинаем с провайдеры с простой подпиской за 10/20 баксов, с 5-и часовыми лимитами и прочими ограничениями. Оптимизируем свою работу за счет умного оркестратора и нужных настроек. Дорогие модели выполняют более сложную работу, дешевые простую и с учетом особенностей моделей, в доке про ohmyopenagent можно про это почитать. Оптимизируем более сложные моменты, например, добавляем lsp сервера, mcp сервера и прочее, чтобы оркестратор например типы для typescript выводил с помощью lsp или фиксил ошибки, а не слал запросы, или mcp для индексации кодовой базы, чтобы не было кучи вызовов grep и анализа выводов этой команды.
Когда упираемся в лимиты, добавляем еще один/два провайдера с простой подпиской за 10/20 баксов. Оптимизируем роутинг, lsp, mcp.
Если опять упираемся в лимиты, то да уже переходим на оплату за API для каких-то моделей, но опять таки оптимизация тут такая же как и в предыдущих пунктах. Никто например не мешает для планировщика использовать github-copilot/claude-opus-4.6, а для кодинга, openrouter/claude-sonnet-4.6 с оплатой за токены.
С оптимизаций роутинга все просто, или делаем `bunx oh-my-openagent install` отвечаем на вопросы какие провайдеры подключены и получаем готовый конфиг с fallback или читаем доки и правим конфиг. В вот с lsp/mcp надо играться и подбирать под свои задачи и свой стек.
И еще все сильно зависит от стиля разработки, при ручной разработке, написал задачу, посмотрел diff, запустил, скинул ошибку, получил фикс довольно сложно попасть в лимиты, и токены улетают не очень сильно. При полностью автоматической разработке каждый шаг очень сильно зависит от предыдущего. Планировщик должен простой промпт преобразовать в хороший план задавая вопросы и анализируя код. От плана зависит то какие задачу каким сабагентам уйдут в работу. От того как задача поставлена сабагенту и какие lsp/mcp доступны такой и будет результат.
Я бы сказал что пока не пройдешь путь с лимитированными планами, и оптимизациями, идти в платное API смысла нету, токены будут улетать.
И еще, если проект большой, и надо модели с большим контекстом, то тут вариант только API. Если окно забито больше чем на 50% то llm начинает галлюцинировать, а на лимитированном плане копилота например всего 128К для любой модели, а через API можно получить окно 1М для Opus/Sonnet
У Вас же просто ручной роутинг без учета особенностей моделей, и вы по сути залили проблему деньгами. За 50 баксов можно взять Copilot Pro+ (40 баксов) + OpenCode Go(10 баксов) - в таком сетапе моделей будет больше(и полностью бесплатные тоже есть в этих планах) и по лимитам явно не меньше чем в Вашем сетапе. Так же явная проблема с том что качество кода всегда плавает из-за того что разные задачи идут в разные модели, с оркестратором качество +- одинаковое из-за того что этапы и модели стандартизированы.
Переходить на оплату по токенам нужно тогда когда не влазишь в лимиты подписки. И тот же opencode(как и другие оркестратор) никак не управляет подписками, он просто подключает провайдер и дергает внутри агента нужную модель в нужно провайдере.
Объясняю на примере Copilit Pro за 10 баксов доступно 300 запросов в месяц, для Cloude Sonnet 4.6 мультипликатор 1, тоесть в месяц доступно 300 запросов, для Grok Code Fast 1 мультипликатор 0.25 тоесть всего доступно 1200 запросов в месяц. Причем один запрос максимально 128К входящих токенов, тоесть в идеальной ситуации мы можем послать 128К * 300 токенов = 37.5M токенов. Да это все в 5 часовых лимитах и прочие ограничения.
А если те же 37.5М токенов заслать через api для того же Cloude Sonnet 4.6 это 3$ за миллион токенов это уже 112.5$.
Но вот для Grok Code Fast 1 ситуация другая, можно послать 128К * 1200 токенов = 150M токенов. Через api 150M токенов для Grok Code Fast 1 обойдутся 30 баксов, по 0.2$ за миллион. Думаю что это из-за того что Microsoft вложился в Anthropic и получает ресурсы по скидки, и заинтересован в раскрутке их моделей.
У opencode go в доке написано
Бесплатные модели включают Big Pickle плюс промо-модели, доступные на данный момент, с квотой 200 запросов/день. Go включает GLM-5.1, GLM-5, Kimi K2.5, Kimi K2.6, MiMo-V2.5-Pro, MiMo-V2.5, Qwen3.5 Plus, Qwen3.6 Plus, MiniMax M2.5, MiniMax M2.7, DeepSeek V4 Pro и DeepSeek V4 Flash с более высокими квотами запросов, применяемыми в скользящих окнах (5 часов, неделя и месяц), что примерно эквивалентно $12 за 5 часов, $30 в неделю и $60 в месяц (фактическое количество запросов зависит от модели и использования).
Тоесть если посылать максимально большие запросы как в примере выше то максимум можно утилизировать на 60$, если сравнивать с ценой за токены.
Похоже что для провайдеров выгодно продавать такие планы, потому что клиенты не утилизируют все запросы по максимуму, плюс многие пользователи берут минималку чтобы просто попробовать, и в реальности не тратят даже 10$ если смотреть по цене api.
У копилота плюс что у него доступны модели Anthropic и OpenAI одновременно, и для оркестраторов это круто, потому что там где сильны модели Anthropic слабы модели от OpenAI и наоборот. Но c 1-го июня майки меняют тарификацию и вроде как мультипликаторы и надо будет смотреть выгодно будет их дальше использовать или нет.
А тут и писать особо нечего, ставим opencode в виде cli или плагина для ide. Все делаете по инструкции. Если надо чтобы это все было заряжено, ставите ohmyopenagent или расширяете плагинами. Так же читаете доку на ohmyopenagent, там есть рекомендованный сетап на 30 баксов, есть описание всех моделей, и почему и для чего они были выбраны и для каких задач лучше. Что подключать зависит уже от вас, можете подключить любой провайдер, тот же openrouter или copilot c кучей моделей (если ставите ohmyopenagent то он спросит что за провайдеры нужны и сгенерирует нужную конфигурацию)
Можно использовать Claude code + proxy, через прокси подменить модели на нужные, и потом уже переключаться вручную между ними.
Чистый opencode, если охота иметь больше контроля, и меньше тратить токенов. Всегда можно навернуть плагинов, чтобы получить например Ralph режим (это что-то типа while true; делай задачу пока все тесты не будут зелеными)
И opencode + ohmyopenagent, куча интергированных плагинов, разные агенты, автоматические режимы работы. Больше потребляет токенов.
Есть и другие агенты(оркестраторы агентов) - roo, kilo, cline, но их я не пробовал.
С opencode бывают проблемы, за ним надо следить, бывает игнорирует промпт, надо повторять, бывает в авторежиме (ohmyopenagent) как будто зацикливаться на этапе планирования и его выполняет по кругу не переходя к кодингу, бывает сабтаска подвисает. В этом плане Claude code получше будет.
Есть еще get-shit-done, это полностью разработка автоматическая разработка, тоже есть возможность настраивать модели для разных задач (под капотом там pi agent). Но мне не сильно зашло, сильно много вопросов задает, результат очень зависит от того что ты отвечаешь. Создавал один и тот же проект с нуля, чуть по разному отвечал, план создания и развития проекта получался очень разный. В существующий проект интегрировалось сложно, генерит кучу документов которые забивают контекстное окно. Вообщем вещь хорошая, но не для моих задач.
Конкретно сейчас мой сетап такой opencode + ohmyopenagent и copilot за 10 баксов, поменяется тарификация или лимиты у copilot перейду что-то другое.
Какой-то древний подход. Сейчас используют сабагентов и умный роутинг. Главный агент (например Claude oppus) разбивает задачу на подзадачи для других агентов, доку пишет например gemini, код пишет например sonnet, мр ревьюит например deepseek, анализирует код например chatgp и так далее. Для каждой задачи/шага выбирают своего оптимального агента. И это все работает в связке, chatgp проанализировал код и отдал главному, главный прям в плане вписал какие именно файлы надо менять, чтобы кодописатель не лез в кодовую базу и ничего не анализиовал сам. Причем если например закончились токены для кодописателя sonnet, через конфигурацию идем и меняет на что-то другое. Такой подход позволяет более равномерно утилизировать токены на всех агентах и использовать бесплатных/дешевых агентов для вспомогательных вещей, типа поиск по кодовой базе.
На самом деле можно выбрать и другой агент. Помимо Claude Code, я пробовал RooCode, OpenCode, KiloCode. Разница между ними не очень велика, но мне проще всего оказалось работать с Claude, пока я не сделал своего агента.
Почему выбор пал именно на Claude Code и CCR? Если разница не очень велика то не лучше ли выбрать более подходящий инструмент? OpenCode закрывает вопросы с подключением разных моделей от разных провайдеров, роутингом, персональными настройками для каждого проекта. И если этого всего не хватает, то с помощью oh-my-openagent можно очень сильно прокачать OpenCode.
За всю свою практику первый раз вижу идею обновлять что-то внутри json.
Обычно колонка с таким типом(json, jsonb) используется для хранения сырых неструктурированных данных. И в таблице обычно есть колонки которые обновляются из этих сырых данных.
А при миграции и добавлении новой колонки происходит что-то типа
alter table add column status table_status_enum;
update table set status=raw->'document'->'status'::table_status_enum
С json/jsonb чуть сложнее работа с constraints, в частности с enum, и нет возможности создать pk.
В битве меча и щита, всегда побеждает меч.
Это заказчикам довольно быстро объяснят хакеры, которые будут ломать такие поделки пачками и использовать для "заработка". Вот пару раз попадет заказчик на деньги тогда и задумается.
Мавзолей на луне, вот это было бы эпично. А очередную АЭС, вот это прям банально.
Если не привязываться к провайдеру, то следующая подписка GitHub Copilot Pro+ за 40$.
Если не привязываться к одному семейству моделей, то можно использовать например Claude Pro за 20 (или OpenAi Codex за 20) + Copilot Pro за 10 + OpenCode Go за 10.
Если не привязываться к подписочным моделям и платить за api, то можно использовать openrouter или OpenCode Zen или вообще редактор Zed и их интеграцией.
Я бы еще добавил один неочевидный момент. Рутинные задачи нужны не только для передачи знаний и воспитания специалистов. Они нужны для формирования команды, для распределения нагрузки внутри команды, так как на рутинных задачах можно просто отдохнуть от "творческих задач".
Это постоянно происходит, до ИТ все шли в юристы, до юристов, делать евроремонты, до этого были 90-е и шли в челноки. Был ажиотаж среди таксистов, дальнобойщиков, ювелиров. В медицине всегда стремились в гинекологи или стоматологи. Или в косметологию. Даже в ИТ постоянно выделялись какие-то области куда шли, то CV, то ML, сейчас вон ИИ. Просто про это все не так было известно как сейчас, так как не было интернета и разных соцсетей.
Это было правдой когда ThinkPad был частью IBM. После того как подразделение ThinkPad было продано Lenovo, данная линейка скатилась в яму. Перечислю то что стало хуже:
Корпус был из титано-магниевого сплава, а стал из унылого пластика.
Процессор распаян на материке. Лично у меня два раза отпадал процессор от перегрева и приходилось сдавать в ремонт и делать реболлинг.
Формат экрана поменяли с 3:4 на 9:16, из рабочей машины сделали мультимедийную машину.
Убрали лампочку подсветки, вместо этого вставили унылую клавоподсветку.
После проблем с перегревом, хотя раз в год менял термопасту, делал чистку, перешел на маки, и забыл про эти все проблемы как про страшный сон. Алюминиевый корпус весь рассеивает тепло, в отличии от пластикового.
Это отлично. Это великий фильтр для управленцев и руководителей всех уровней. Пусть они генерит тонны кода сами, попадают на деньги из-за багов и штрафов. Пусть они увольняют разработчиков, а потом нанимают тех же людей за намного большие деньги.
Всем известны компании где сидит этот 1% разработчиков.
И если бы я сидел в том же Anthropic на халявных токенах, то тоже бы входил в этот 1%.
Провайдеры ИИ вряд ли схлопнутся. И в идеальной картине мира нужна отдельная инфраструктура для генерации, доставки токенов и любого взаимодействия между агентами, типа как для газа/воды/электричества. С наймом людей все сложнее, есть автоматизированное производство, со станками чпу, сканерами штрих кодов, роботами доставщиками на складе, и любыми другими автоматизациями. Что будет если часть или вся автоматизация пропадет? Такое производство вряд ли сможет нанять людей как проще так и дешевле. Потому что автоматизация вытесняет часть профессий, люди переучиваются. Попробуй сейчас найти токаря, фрезеровщика, того же кладовщика. И это уже не говоря про офисную и управленческую автоматизацию. Даже если получиться заместить людей, то сильно ли долго такое производство продержится в условиях конкуренции? ИИ это тоже автоматизация, или мета-автоматизация. Да пока зависимости от этой ИИ автоматизации не очень критичная, но это быстро меняется с каждым днем.
Какие-то модели с открытыми весами может и доберутся, но вот железо доступнее не станет.
Предполагаю что это просто очередной передел рынка и расширение существующих монополий. Какое-то количество компаний перейдет на ИИ полностью или почти полностью, как только это произойдет, для этих компаний начнется падение. 5-10-20 месяцев, не важно, код в любом случае так деградирует, что эти компании просто не смогут обслуживать клиентов, а попытка привлечь людей не сработает из-за кучи непонятного кода. Но перед тем как это случиться, эти компании и их инвесторов просто выжмут провайдеры ИИ постоянным повышением цен, ужесточением лимитов и прочими методами.
Проблема джунов и их развития на моей памяти где-то с 2010 года. Разработка была другая, было больше свободы и доступа к проду, было меньше информации, больше ошибок. И софт был разный, со своими особенностями, и клиенты за нужные им функции платили лояльностью и обратной связью. Были стартапы где тоже можно было опыта получить. Потом все стало одинаковое, и началась погоня за девятками стабильности, контуры доступа, всякий маркетинг и сео. В таких условиях опыт особо не получишь, прод сам не сломаешь, сам не починишь, сидишь в песочнице из линтеров, чекеров, тестов. Сейчас опыт можно получить только в крупных компаниях. И есть такое ощущение, что роль кузнецы кадров на себя возьмут стартапы, и их будут покупать не из-за перспективной идеи, а из-за собранной и сработанной команды.
Скорее всего залезли через другую дыру, а сказали что через эту. Обычно зловреды после заражения закрывают уязвимости.
Я бы сказал так.
Сначала начинаем с провайдеры с простой подпиской за 10/20 баксов, с 5-и часовыми лимитами и прочими ограничениями. Оптимизируем свою работу за счет умного оркестратора и нужных настроек. Дорогие модели выполняют более сложную работу, дешевые простую и с учетом особенностей моделей, в доке про ohmyopenagent можно про это почитать. Оптимизируем более сложные моменты, например, добавляем lsp сервера, mcp сервера и прочее, чтобы оркестратор например типы для typescript выводил с помощью lsp или фиксил ошибки, а не слал запросы, или mcp для индексации кодовой базы, чтобы не было кучи вызовов grep и анализа выводов этой команды.
Когда упираемся в лимиты, добавляем еще один/два провайдера с простой подпиской за 10/20 баксов. Оптимизируем роутинг, lsp, mcp.
Если опять упираемся в лимиты, то да уже переходим на оплату за API для каких-то моделей, но опять таки оптимизация тут такая же как и в предыдущих пунктах. Никто например не мешает для планировщика использовать github-copilot/claude-opus-4.6, а для кодинга, openrouter/claude-sonnet-4.6 с оплатой за токены.
С оптимизаций роутинга все просто, или делаем `bunx oh-my-openagent install` отвечаем на вопросы какие провайдеры подключены и получаем готовый конфиг с fallback или читаем доки и правим конфиг. В вот с lsp/mcp надо играться и подбирать под свои задачи и свой стек.
И еще все сильно зависит от стиля разработки, при ручной разработке, написал задачу, посмотрел diff, запустил, скинул ошибку, получил фикс довольно сложно попасть в лимиты, и токены улетают не очень сильно. При полностью автоматической разработке каждый шаг очень сильно зависит от предыдущего. Планировщик должен простой промпт преобразовать в хороший план задавая вопросы и анализируя код. От плана зависит то какие задачу каким сабагентам уйдут в работу. От того как задача поставлена сабагенту и какие lsp/mcp доступны такой и будет результат.
Я бы сказал что пока не пройдешь путь с лимитированными планами, и оптимизациями, идти в платное API смысла нету, токены будут улетать.
И еще, если проект большой, и надо модели с большим контекстом, то тут вариант только API. Если окно забито больше чем на 50% то llm начинает галлюцинировать, а на лимитированном плане копилота например всего 128К для любой модели, а через API можно получить окно 1М для Opus/Sonnet
У Вас же просто ручной роутинг без учета особенностей моделей, и вы по сути залили проблему деньгами. За 50 баксов можно взять Copilot Pro+ (40 баксов) + OpenCode Go(10 баксов) - в таком сетапе моделей будет больше(и полностью бесплатные тоже есть в этих планах) и по лимитам явно не меньше чем в Вашем сетапе. Так же явная проблема с том что качество кода всегда плавает из-за того что разные задачи идут в разные модели, с оркестратором качество +- одинаковое из-за того что этапы и модели стандартизированы.
Переходить на оплату по токенам нужно тогда когда не влазишь в лимиты подписки. И тот же opencode(как и другие оркестратор) никак не управляет подписками, он просто подключает провайдер и дергает внутри агента нужную модель в нужно провайдере.
Объясняю на примере Copilit Pro за 10 баксов доступно 300 запросов в месяц, для Cloude Sonnet 4.6 мультипликатор 1, тоесть в месяц доступно 300 запросов, для Grok Code Fast 1 мультипликатор 0.25 тоесть всего доступно 1200 запросов в месяц.
Причем один запрос максимально 128К входящих токенов, тоесть в идеальной ситуации мы можем послать 128К * 300 токенов = 37.5M токенов. Да это все в 5 часовых лимитах и прочие ограничения.
А если те же 37.5М токенов заслать через api для того же Cloude Sonnet 4.6 это 3$ за миллион токенов это уже 112.5$.
Но вот для Grok Code Fast 1 ситуация другая, можно послать 128К * 1200 токенов = 150M токенов. Через api 150M токенов для Grok Code Fast 1 обойдутся 30 баксов, по 0.2$ за миллион. Думаю что это из-за того что Microsoft вложился в Anthropic и получает ресурсы по скидки, и заинтересован в раскрутке их моделей.
У opencode go в доке написано
Тоесть если посылать максимально большие запросы как в примере выше то максимум можно утилизировать на 60$, если сравнивать с ценой за токены.
Похоже что для провайдеров выгодно продавать такие планы, потому что клиенты не утилизируют все запросы по максимуму, плюс многие пользователи берут минималку чтобы просто попробовать, и в реальности не тратят даже 10$ если смотреть по цене api.
У копилота плюс что у него доступны модели Anthropic и OpenAI одновременно, и для оркестраторов это круто, потому что там где сильны модели Anthropic слабы модели от OpenAI и наоборот. Но c 1-го июня майки меняют тарификацию и вроде как мультипликаторы и надо будет смотреть выгодно будет их дальше использовать или нет.
А тут и писать особо нечего, ставим opencode в виде cli или плагина для ide. Все делаете по инструкции. Если надо чтобы это все было заряжено, ставите ohmyopenagent или расширяете плагинами. Так же читаете доку на ohmyopenagent, там есть рекомендованный сетап на 30 баксов, есть описание всех моделей, и почему и для чего они были выбраны и для каких задач лучше. Что подключать зависит уже от вас, можете подключить любой провайдер, тот же openrouter или copilot c кучей моделей (если ставите ohmyopenagent то он спросит что за провайдеры нужны и сгенерирует нужную конфигурацию)
Можно использовать Claude code + proxy, через прокси подменить модели на нужные, и потом уже переключаться вручную между ними.
Я бы использовал так, Claude code + proxy если именно надо все фишки Claude code, скилы, хуки, и прочие возможности. Вот статья на эту тему https://habr.com/ru/companies/yadro/articles/1029288/
Чистый opencode, если охота иметь больше контроля, и меньше тратить токенов. Всегда можно навернуть плагинов, чтобы получить например Ralph режим (это что-то типа while true; делай задачу пока все тесты не будут зелеными)
И opencode + ohmyopenagent, куча интергированных плагинов, разные агенты, автоматические режимы работы. Больше потребляет токенов.
Есть и другие агенты(оркестраторы агентов) - roo, kilo, cline, но их я не пробовал.
С opencode бывают проблемы, за ним надо следить, бывает игнорирует промпт, надо повторять, бывает в авторежиме (ohmyopenagent) как будто зацикливаться на этапе планирования и его выполняет по кругу не переходя к кодингу, бывает сабтаска подвисает. В этом плане Claude code получше будет.
Есть еще get-shit-done, это полностью разработка автоматическая разработка, тоже есть возможность настраивать модели для разных задач (под капотом там pi agent). Но мне не сильно зашло, сильно много вопросов задает, результат очень зависит от того что ты отвечаешь. Создавал один и тот же проект с нуля, чуть по разному отвечал, план создания и развития проекта получался очень разный. В существующий проект интегрировалось сложно, генерит кучу документов которые забивают контекстное окно. Вообщем вещь хорошая, но не для моих задач.
Конкретно сейчас мой сетап такой opencode + ohmyopenagent и copilot за 10 баксов, поменяется тарификация или лимиты у copilot перейду что-то другое.
Какой-то древний подход. Сейчас используют сабагентов и умный роутинг. Главный агент (например Claude oppus) разбивает задачу на подзадачи для других агентов, доку пишет например gemini, код пишет например sonnet, мр ревьюит например deepseek, анализирует код например chatgp и так далее. Для каждой задачи/шага выбирают своего оптимального агента. И это все работает в связке, chatgp проанализировал код и отдал главному, главный прям в плане вписал какие именно файлы надо менять, чтобы кодописатель не лез в кодовую базу и ничего не анализиовал сам. Причем если например закончились токены для кодописателя sonnet, через конфигурацию идем и меняет на что-то другое.
Такой подход позволяет более равномерно утилизировать токены на всех агентах и использовать бесплатных/дешевых агентов для вспомогательных вещей, типа поиск по кодовой базе.
Лучше NFT для этого использовать.
Схема бекапа не полная, еще надо бекапить как минимум на одной планете и одном спутнике
Почему выбор пал именно на Claude Code и CCR? Если разница не очень велика то не лучше ли выбрать более подходящий инструмент? OpenCode закрывает вопросы с подключением разных моделей от разных провайдеров, роутингом, персональными настройками для каждого проекта. И если этого всего не хватает, то с помощью oh-my-openagent можно очень сильно прокачать OpenCode.
За всю свою практику первый раз вижу идею обновлять что-то внутри json.
Обычно колонка с таким типом(json, jsonb) используется для хранения сырых неструктурированных данных. И в таблице обычно есть колонки которые обновляются из этих сырых данных.
А при миграции и добавлении новой колонки происходит что-то типа
С json/jsonb чуть сложнее работа с constraints, в частности с enum, и нет возможности создать pk.