Comments 12
Очень ожидал увидеть примеры файлов спецификаций.
Пожалуйста, шаблон.
Аж итересно было узнать чем же этот новый Spec Driven Development отличается от лампового дизайна по требованиям, которого все гнобили в угоду аджайлу. Но так ничего и не показали.
Так это ж он и есть, в этом вся прелесть.
Аджайл угоден бизнесу, возможно, потому что умело прячет расходы в доходах, но я например не считаю, что это лучше ватерфолла того же.
Просто в разработке по требованиям в начале может тратиться очень много времени на первичную проработку, прежде чем можно будет продавать продукт, а в аджайле бац бац и в продакшн. И то что решение сырое, растет технический долг и потенциально конфликты в зависимостях никого не волнует, главное что заказчик уже платит деньги за сырую заготовку, подписку там какую нибудь и фактически обещания сделать лучше, да и можно ведь втюхивать заготовку сразу нескольким заказчикам.
А по теме Spec Driven - он решает основную проблему взаимодействия с LLM в промышленной разработке, а именно отсутствие навыка чтения мыслей и соответственно сильный дрифт и несоответствие ожиданиям. При этом LLM, как и положено, берет на себя рутинную работу, в данном случае по написанию документов. Разработчик берет на себя роль product owner + tech lead, пока LLM отыгрывает бизнес/системного аналитика. Разработчик подмечает детали в процессе ревью, отправляет несколько раз на переработку/доработку документацию на разных стадиях и дальше может быть вполне уверен в полученном результате с минимальным или вообще отсутствующим техническим долгом.
Это на самом деле прилично занимает время, особенно для больших идей/фичей, но при этом позволяет добиться успеха быстрее, чем просто запускать LLM на сложную задачу и затем множество раз ее направлять со словами "тут кнопка делает не совсем то что я хотел" или "перекрась цвета", а потом "неправильно перекрасил, опять перекрась", "вот тут забыл" и т.д.
Spec Driven вообще меньше всего похож на вайб кодинг. Мне кажется, что развитие подобного подхода будет очень полезно в преобразование взаимодействия в настоящую работу с инструментом. Сейчас выглядит так будто на всю планету из космоса прилетела технология без инструкции по использованию и человечество пытается придумать эту инструкцию.
Заплюсовал за идею - сам двигаюсь в подобном направлении. Но как практик хотел бы увидеть меньше нейрогенерёнки и больше кода или хотя бы скриншотов, на которых видна структура ваших спецификаций. По моему опыту в плоских файлах (типа constitution.md) архитектуру проекта не описать - нужна иерархия каталогов и файлов в них. Так-то можно по коду распихать AGENTS.md и в них хранить спецификации и для /services/, и для /api/client. Мне нейронка выжимку по структуре сделала, но не уверен, что это именно то, что вы имели в виду.
У меня написаны подобные спецификации. Только я от них пока отказался. Слишком большой объем для чата получается. Сделал одну спецификацию небольшую, которой пользуюсь.
Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.
у кого-то месяцы уходят на разработку, у кого-то разработать MVP от силы за месяц и дальше релиз каждые две недели
Команды, использующие инструменты на базе ИИ (AI-native), такие как Copilot, Cursor, Windsurf, Claude Code или Gemini CLI, которым нужны структурированные намерения для получения надежного, не галлюцинирующего результата от AI-агентов.
раз вы решили вторую статью написать по одной и той же теме, то я и здесь задам тот же вопрос - как вам удается заставить Cursor следовать этим правилам? Да, я понимаю, что статья - всего лишь перевод, но если вы публикуете такое, то вы же соглашаетесь с написанным авторами оригинала?
У меня он умудряется игнорировать даже 300 строчек базовых правил, а ваших правил явно больше. Он же скорее всего действует по правилам LLM - запомнить начало и конец, а середину можно проигнорировать
Используйте вызовы правил по сценариям, а не "Always use" или "Auto", или если желаете интеллектуально чтоб агенты сами понимали какие правила и что читать, развивайте их по определениям, на что ссылаться и какой участок правил использовать
По-идее, здесь должна помогать иерархия файлов AGENTS.md. По крайней мере Codex пытается выстраивать их в цепочку и создавать корпус инструкций, применяемых по текущему месту работы (нахождению модифицируемого исходника).
Для LLM важен контекст. Даже не так - важны плотность и однородность контекста. Если ваши 300 строчек правил противоречат друг другу, то модель не сможет следовать им всем одновременно. А вот как сделать так, чтобы для каждого исходника у агента был плотный и однородный контекст (причём для различных исходников и для различных сценариев модификаций этих исходников должен быть различный контекст) - вот это уже большой вопрос, на который у Spec Kit пока что ответа нет.
правила явно написаны правильно, потому что следует им в 90% случаев. Спросил у cursor, почему он иногда игнорит правила:
Длинные цепочки действий
В начале сессии правила в фокусе, но после множества шагов внимание рассеивается.
Фокус на функциональности
При сложных задачах приоритет смещается на "работает", а не на "соответствует правилам".
Неявные правила
Некоторые правила требуют контекста проекта, который не всегда очевиден.
Первое не подходит, потому что cursor игнорит правила даже на единичных запросах в чат. Если имеется в виду несколько сообщений в одном чате, то он умудряется игнорить правила даже на первое сообщение в чате.
Третье не подходит, потому что cursor игнорит даже правило "скомпилируй проект перед тем, как рапортовать, что все готово", которое не зависит от контекста.
Остается второе, но не понятно, как с этим бороться - он же любую задачу может посчитать сложной.
Пример правил курсора
---
description: ""
alwaysApply: false
---
# Manual Rule
Этот набор команд применяется только при явном упоминании: `@manual-rule`.Общая структура
/
├── .cursor/
│ └── rules
│
├── AGENTS.md
│
├── specs/
│ ├── constitution.md
│ ├── system/
│ └── features/
│
├── schematics/
│ ├── system/
│ │ ├── architecture.mmd
│ │ ├── dataflow.mmd
│ │ ├── states.mmd
│ │ └── contracts.yaml
│ │
│ ├── features/
│ │ └── feature-x/
│ │ ├── flow.mmd
│ │ ├── states.mmd
│ │ └── api.yaml
│ │
│ └── README.md
│
└── src/
Внутри Spec-Driven Development: на что способен Spec Kit