Comments 11
Почему поддерживать сразу Cursor, Codex, Claude Code и OpenCode? это не избыточно?
Потому что сами практики часто не завязаны на один инструмент. Сегодня команда использует Cursor, завтра часть людей работает в Codex или Claude Code. Если skill описывает процесс, хочется переиспользовать его, а не писать под каждую IDE заново.
следующий вопрос: почему нет стандарта, почему " Сегодня команда использует Cursor, завтра часть людей работает в Codex или Claude Code "?
Это тяжелый вопрос… Первая причина: компания к сожалению не оплачивает курсор всем, и настаивать на том, чтобы все за свои деньги покупали именно курсор по меньшей мере странно. Вторая причина: инструментов много, они конкурируют между собой и постоянно выходят очередные киллер фичи, как сообщество разработчиков мы не хотим застрять в одном решении, мы постоянно обсуждаем и сравниваем.
я понял. но, не согласился. Когда с одной стороны в компании принято, что разработчики что-то там себе покупают (!), а с другой - налаживает процесс согласования всего этого в один рабочий процесс, это явно ненормально. Возникает вопрос ко всему этому - не было бы эффективнее и дешевле централизованно управлять средствами разработки, стандартизовать процесс и тд. Вместо того, чтобы латать дыры.
Было бы эффективней, но у нас госкомпания и всякие закупки делаются так долго, что пока совершается закупка средства могут быть уже неактуальны, у нас согласовываются закупки аж на след год. Но это одна причина, самая горькая. Вторая, что не хочется что-то навязывать, не смотря на бюрократию в финансовых вопросах, мы стараемся быть свободными в командах. Ну и я сам пользуюсь Cursor + Codex, для каких-то задач эффективен один инструмент, для каких-то другой, а скиллы переносимы, там разницы только в какие папочки ставить. И через мини утилиту, это делается в несколько кликов. С другой стороны есть rules, там уже не все так радужно.
У Деда Мороза попрошу быть таким же неленивым, я бы остановился на репозитории со скиллами, дальше сами выгребайте. А вообще забавно, что по сути LLM c таким подходом это просто глорификация выдачи скриптов.
У LLM-разработки есть одна неприятная черта: непредсказуемость. Вот этот промпт вот с этой LLM на таком-то уровне дает хороший результат. Чуть измени промпт - конец эффекту. Вышла новая версия LLM - перестало работать. Хозяин LLM что-то подкрутил в невидимом системном промпте - получается ерунда. Вышла новая, улучшенная версия - нелепые действия вместо решения. Невоспроизводимость результатов выбивает кресло из-под моего седалища, привыкшего к паттернам и детерминированности. Классический язык программирования такую свинью не подкладывал никогда. LLM пришел, надо его осваивать и привыкать, но нынешняя стадия его развития наверняка пройдет и мы получим что-то более управляемое. Невозможно строить АЭС (к примеру) с вероятностью успеха 90.6%
Да, это ровно причина, почему я не хочу строить процесс на одном “священном промпте”. Поэтому мне ближе схема, где всё детерминированное уезжает в скрипты, проверки и явные stop conditions, а LLM остаётся не источником истины, а интерфейсом к процессу: собрать контекст, объяснить блокер, предложить следующий шаг, помочь на развилке. Мне кажется, зрелость LLM-инструментов как раз будет не в том, что модель станет магически безошибочной, а в том, что вокруг неё появится больше инженерных ограничителей.
Хорошие конкретные примеры как делать скиллы, которые помогают делать миграцию проектов со старого стека, библиотек и т.п.
Вы не внедрили AI. Вы завели кладбище промптов