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

[koha2102]

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

[Anselm_nn]

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

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

[AppCrafter]

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

[Pubert]

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

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

[Muluc]

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

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

[Pubert]

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

[Muluc]

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

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

[Pubert]

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

[Muluc]

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