1. Оказалось, что нет исследования, что SDD кому-то исчислимо помог.
2. Если спека не должна быть Вики, то в ней высокоуровневые идеи. Где грань, что должно в них оседать, а что должно сразу в код? А если не соблюсти это? А что-то изменится от дисбаланса?
3. Например, openspec оперирует только сценариями, можно форкнуть и завести свой шаблон спеки. Что будем включать туда? Почему? Это сильно проектспецифичный вопрос, в каждом проекте будут свои необходимости.
4. А что если SDD вообще не будет в проекте? А что если у агента жопа не отвалится, если у меня будет папка docs c md тз в произвольной форме?
Я думаю, что если подключить к openspec/spec-kit к проекту, они не помешают. Но и существенно ничего не привнесут. Наверно, профит может быть, если делать это с умом, понимать, как ты валидируешь требования, как ты валидируешь результат, как приходишь к детерминированности. Короче, думать надо. А вокруг SDD много фетиша, воспринимается как серебрянная пуля. На самом деле что есть что нету.
15 · 2.2K · Ветка1. Оказалось, что нет исследования, что SDD кому-то исчислимо помог.
9 сообщений · –S Проблема не во фреймворке, а в людях. 1) для генерации "спека" не нужна цепочка из манагеров. 2) если разработчик , извините, оператор элэлэм не может мэйнтэйнить процесс от контакта с заказчиком / стэйкхолдером до деплоя, то он профнепригоден для новой парадигмы. Любой разрыв в цепочке = гигантские потери времени на стык двух и более людей там, где этого не должно быть. х2-х5 достигается только через сокращение транзакционных издержек по всей цепочке.M Код агенты читают недетерминированно. Для поиска нужного места, по сути, у них есть только grep. Качество поиска нужных мест и понимания того "как должно работать" таким инструментом не очень высоко. И плавает от вызова к вызову. Отсюда и необходимость "надслойки" над кодом. В виде спецификации - это потому, что привычно человеку. Человек может посмотреть, может осознать, поправить, написать и "согласовать с бизнесом". Но для агентов чтение текстовой спеки -такой же сложный процесс, как и чтение кода. И основной камень преткновения - связи. Пока система небольшая (условно, весь код и спеку можно поместить в контекстное окно), то это не больно. Пласт разработки персональных инструментов под конкретную задачу так спокойно можно закрыть. Но любой мало-мальский продукт - это уже больше контекстного окна однозначно. И встает вопрос - а где по коду у нас разбросано использование данных и методов класса "пользователь", как и что поменяется, если поле "цвет глаз" сделать обязательным, а скидку персональной, а не привязанной к продукту? И из сложности поиска связей грепом (что в коде, что в спеке) вырос третий класс решений - основанный на графах. В граф можно положить как взаимосвязи в кодовой базе, так и взаимосвязи в спеке (юзкейсы, шаги, требования, формы, данные). Основное отличие графа от текста - у него есть cypher-язык запросов. Такой же точно sql, только на графе, а не на реляционных таблицах. У него два преимущества: - детерминированность - объем Мы тратим на 90% меньше токенов чтобы вкурить ту же информацию. При том каждый агент гарантированно получает на вход один и тот же контекст (при выполнении одних и тех же запросов) Таким образом мы получаем более удобную для агентов "точку правды", чем код или текстовая спека. А без "точки правды" агенты начинают перепридумывать то, что уже реализовано. Делать одно и то же в разных местах.M Н M Это просто две стороны одной медали :) Был вопрос про "зачем нужна спека и методика, где спека лежит в основе". Собственно, это ответ. И я полностью согласен, что сделать без спеки MVP - вполне рабочее решение. Просто нужно быть готовым, что для промышленной эксплуатации его придётся полностью переделатьЭ
У