Spotify выпустили Xirp — единую среду для Claude Code, Codex и т.д

Spotify представили Xirp — независимую от поставщика среду для агентной разработки. Она позволяет запускать и управлять сессиями Claude Code, Gemini CLI и OpenAI Codex из одного приложения, переключаясь между агентами без потери контекста.

По данным компании, внутри Spotify инструментом уже пользуются более 1300 инженеров. Теперь разработчики и команды вне Spotify могут подать заявку на участие в бета‑тестировании.

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

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

Сессии можно запускать локально или удалённо. Разработчики могут переключаться между Claude, Gemini и Codex, сохраняя общий корпоративный контекст независимо от выбранной модели.

Xirp пока распространяется в формате беты. На лендинге не указаны стоимость и дата полноценного релиза, для получения доступа необходимо оставить заявку. Участники тестирования также могут запросить собственный экземпляр Spotify Portal.

Русскоязычное сообщество про AI в разработке

Друзья! Эту новость подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI‑агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!

Комментарии

@koha2102

11.08.2026 07:51 UTC

В чем проблема оркестрировать CLI агентов из того же Codex Desktop? если немного потанцевать с бубном все довольно сносно работает

@Anselm_nn

11.08.2026 08:25 UTC

самое в этой статье шокирующее, что 1300 (минимум) ~~балбесов~~ инженеров работает в спотике

а расщепление сессии мобилки и пк клиента как было, так и есть

@AppCrafter

11.08.2026 08:44 UTC

и чем это отличается от Cursor?

@Pubert

11.08.2026 18:08 UTC

OpenCode, OpenClaw, Cursor и ещё тысячи им подобных: ну да, ну да, пошли мы нафиг

Ну а вообще, документация по завершении работы агента - нормальная тема. Вот бы они ещё умели в нормальную работу с git и хоть раз воспользовались bisect - цены бы им не было

@Muluc

13.08.2026 05:06 UTC

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

Чтобы агенты самостоятельно испозовали его - напишите короткий skill говорящий в таких-то ситуациях использовать bisect в таких-то не использовать. Многие подобные задачки довольно удобно решать таким способом, да и на контекст - минимальное внимание оказывает. Тем же способом можно и подключение пакетов и тд организовывать (у меня так например взаимодействие с nuget построено, модели сами по себе тоже ни в какую не хотят смотреть ни актульную версию пакета, ни ставить .net пакеты специализированной для этого командой, всегда предпочитают редактировать сам csproj файл. Скилы решают эту проблему)

@Pubert

19.08.2026 15:28 UTC

Согласен с Вами. Но никакой скилл не будет валидировать output модели. Я бы хотел, чтобы существовал набор типовых сценариев разработки с жёсткой валидацией шагов, совершаемых ИИ моделью. Написание документации по завершении - один из таких сценариев. Т.е. я не хочу, чтобы нейронка это хорошо умела делать, я хочу, чтобы система заставляла её это делать. Если есть событие "Найден баг", нужно выполнить следующие шаги: найти коммит, на котором баг воспроизводится, выполнить правки, открыть pull request и т.д. Если модель не сильно умная, она очень легко теряется в этих инструкциях, поэтому контролировать надёжнее не контекстом, а внешними ограничениями

@Muluc

21.08.2026 19:33 UTC

Если модель не шибком умная, то там какие бы ограничения не городили вокруг неё, она один хрен по своему будет до талого пытаться делать. По опыту в ответ на жёсткие ограничения из вне они реагируют крайне неадекватно: "мне вернулся отказ, с чётко расписанной причиной и инструкцией как это преодолеть?! В мусор его! Попробую другой способ `bash rm -rf`". В целом слабую модель вот изначально как запустил, так её лучше после этого не трогать и не дышать в её сторону, как правило то как она сама сделает - выйдет лучше, чем если её наставлять на путь истинный. Любую правку поведения она либо вообще не вдупляет потом, либо ставит в абсурдистский абсолют.

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

@Pubert

23.08.2026 22:21 UTC

Ну вот, я, по сути, и имел ввиду "скрипт" для "жёсткого сценария". Только какое-то универсальное настраиваемое решение. Понятно, что для мелких проектов это нафиг не надо, но для каких-нибудь больших компаний, где сложные бюрократические процессы, стоит составить для ИИ полноценный пайплайн. Например, если есть отдельный репозиторий для документации какого-то модуля и модель затронула этот модуль в своём пулл реквесте, нужно затриггерить её и попросить сделать PR в док репо. Мб для этого уже существуют решения, я, честно говоря, не особо шарю. Мб какой-нибудь n8n это позволяет реализовать...

@Muluc

25.08.2026 07:32 UTC

Сомневаюсь что такие решения могут быть прям универсальным (а иначе всё и везде уже было бы автоматизировано), максимум покрывать какой-либо набор наиболее частых сценариев. В плане универсальности возможен разве что подход как в упомянутом n8n (построй всё сам, вот тебе кирпичики-лего и станок для производства своих кирпичиков (возможность писать свои скрипты)). А так это появилось до агентских систем, в данном случае триггером является не модель, да и сама она как правило ничего не вызывает. Ну и из этого стоит понимать, что это тоже не для всех сценариев удобно/подходит. (Это всегда должны быть строго повторяемые задачи, эпизодические, например фикс/поиск багов тут не развернуть, слишком много вариантов развития событий, общая траектория если есть, то строгой последовательности действий - нет. В данном случае как ни крути, а свободу нейронке давать надо. Но вот если говорить про документирование - более чем возможно, это вполне повторяемая задача, со строгой последовательностью действий. И да, можно построить через n8n).