← Все статьи
2026-11-08 14:03 · 🤖 AI World

Claude Code vs Pi: почему разработчики уходят на open source

Разработчик Caleb, пользовавшийся Claude Code с первых дней, публично объяснил переход на Pi — открытый минималистичный харнесс. Его аргументы: 244 релиза за год, нестабильный VSCode-плагин и описание Bash-инструмента на ~3 000 токенов, которое моделям давно не нужно.

Claude Code vs Pi: почему разработчики уходят на open source

В сентябре 2026 года разработчик Caleb опубликовал разбор ухода с Claude Code — харнесса Anthropic, которым он пользовался больше года. Переход — на Pi, опенсорсный минималистичный аналог. Список претензий короткий, но системный: 244 релиза за год, три четверти из которых меняли системный промпт; многолетний баг с одной IDE-сессией на весь процесс; VSCode-расширение, у которого половина slash-команд не работает вовсе; описание Bash-инструмента на ~3 000 токенов, большую часть которых занимают инструкции по git и созданию PR — то, что модели заведомо умеют без подсказок.

Контекст

Claude Code появился как один из первых полноценных LLM-харнессов — инструментов, которые «одевают» языковую модель в интерфейс для реальной работы с кодом: терминал, IDE, контекст файловой системы, наборы инструментов. Поначалу это был почти магический опыт: один промпт — и готовый рабочий код. С тех пор рынок вырос, у Claude Code появились конкуренты, в том числе опенсорсные.

Pi — один из таких альтернативных харнессов. Опенсорсный, построен на принципе минимализма, даёт высокий уровень кастомизации через расширения. Caleb за 20 минут написал расширение, которое решило его главную боль с Claude Code — поддержку нескольких IDE-вкладок с text selection в контексте. Это деталь, но симптоматичная: в открытой экосистеме пользователь сам закрывает то, что продуктовая команда месяцами игнорирует.

Характерно, что Anthropic анонсировала поддержку AGENTS.md файлов ровно на следующий день после того, как автор принял решение уйти. Он сам иронизирует: «слишком мало, слишком поздно». Это отдельная история — Claude Code годами использовал собственный формат CLAUDE.md, что создавало головную боль совместимости для всех, кто хотел работать с другими харнессами.

Аналитика

Претензии Caleb'а не уникальны. Быстрый релиз-темп — управленческий выбор: покупать market share и фичи для enterprise-продаж ценой стабильности для power users. С точки зрения бизнеса это понятно: крупные контракты важнее лояльности одиночных разработчиков. Но в AI-инструментах есть нюанс — именно «продвинутые пользователи» формируют восприятие продукта в developer community. Их публичный уход — это репутационный сигнал, который со временем влияет на adoption в командах.

«В итоге CC ощущается как продукт без чёткого видения. Куча увлечённых инженеров и PM'ов быстро добавляют фичи под свой workflow — не думая о том, как это ухудшает жизнь остальных пользователей», — Caleb, после года ежедневной работы с Claude Code.

Отдельная тема — стоимость inference. Caleb замечает: если срезать 1 000 токенов из системного промпта при 100 млн запросов в день, экономия составит миллионы долларов в год. Для конечного пользователя это тоже не абстракция: лишние токены в scaffolding — прямой расход. Open source харнессы, спроектированные под «ноль overhead», дают измеримый экономический выигрыш при любых объёмах.

Есть и более широкий тренд: модели взрослеют быстрее, чем обновляется scaffolding вокруг них. Детальные инструкции «как делать git add» в системном промпте были оправданы два года назад — современные модели всё это знают. Инструменты, которые не успевают отпускать костыли по мере роста моделей, накапливают балласт. И именно здесь опенсорс с его прозрачностью и кастомизацией выигрывает у закрытых продуктов.

Кейсы применения в бизнесе

B2B-SaaS стартап (3–5 разработчиков). Активное кодовое ревью, несколько параллельных задач. Если IDE-ограничения Claude Code тормозят workflow — стоит протестировать опенсорсный харнесс хотя бы на одном разработчике. Параллельно: аудит AGENTS.md/CLAUDE.md — убрать всё, что модель знает без подсказок. Даже 10% ускорение pull request-цикла ощутимо на скорости итераций.

Корпорация с legacy и enterprise-лицензией. Смена харнесса не приоритет — но аудит системных промптов в pipelines стоит сделать. Лишние тысячи токенов на описание инструментов умножаются на тысячи запросов в день. Без смены продукта, только оптимизацией промптов, можно заметно снизить inference-расходы.

Местный бизнес и фрилансеры в КР/СНГ. Для одиночного разработчика или небольшой команды опенсорсный харнесс означает отсутствие подписки и полный контроль над тем, что уходит в контекст модели. Это особенно актуально при работе с локальными моделями или при соображениях о конфиденциальности кода клиентов.

Кейсы в личной жизни

Разработчик с накопленным раздражением. Если ежедневно используете Claude Code и устали от мелких багов — потратьте час на установку опенсорсного харнесса. Напишите одно расширение под свой workflow. Скорее всего, оно закроет 80% ваших болей и займёт меньше времени, чем вы думаете — Caleb уложился в 20 минут.

Студент или джуниор. Для обучения опенсорсные харнессы полезны иначе: вы видите, как устроен scaffolding вокруг LLM — как промпты, инструменты и контекст работают вместе. Это понимание ценнее любого сертификата по AI.

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

Как применить сегодня

  • Поищите открытые LLM coding harnesses и сравните с вашим текущим инструментом по overhead, стабильности и возможности расширений.
  • Аудируйте ваш CLAUDE.md / AGENTS.md: уберите всё, что современная модель знает без подсказок — короче промпт, ниже стоимость, выше предсказуемость поведения.
  • Измерьте количество токенов в системном промпте ваших coding-агентов. Есть ли там блоки, которые устарели или дублируют встроенные знания модели?
  • Попробуйте написать одно расширение для вашего харнесса под конкретную боль — зачастую это несколько часов, а не месяцев ожидания патча.
  • При выборе AI-инструмента для команды оценивайте не только список фичей, но и release cadence: 244 релиза за год с регулярными изменениями системного промпта — это сигнал о нестабильной продуктовой базе.
← Все статьи