1. Оказалось, что нет исследования, что SDD кому-то исчислимо помог.
2. Если спека не должна быть Вики, то в ней высокоуровневые идеи. Где грань, что должно в них оседать, а что должно сразу в код? А если не соблюсти это? А что-то изменится от дисбаланса?
3. Например, openspec оперирует только сценариями, можно форкнуть и завести свой шаблон спеки. Что будем включать туда? Почему? Это сильно проектспецифичный вопрос, в каждом проекте будут свои необходимости.
4. А что если SDD вообще не будет в проекте? А что если у агента жопа не отвалится, если у меня будет папка docs c md тз в произвольной форме?
Я думаю, что если подключить к openspec/spec-kit к проекту, они не помешают. Но и существенно ничего не привнесут. Наверно, профит может быть, если делать это с умом, понимать, как ты валидируешь требования, как ты валидируешь результат, как приходишь к детерминированности. Короче, думать надо. А вокруг SDD много фетиша, воспринимается как серебрянная пуля. На самом деле что есть что нету.
15 · 2.2K · S Проблема не во фреймворке, а в людях. 1) для генерации "спека" не нужна цепочка из манагеров. 2) если разработчик , извините, оператор элэлэм не может мэйнтэйнить процесс от контакта с заказчиком / стэйкхолдером до деплоя, то он профнепригоден для новой парадигмы. Любой разрыв в цепочке = гигантские потери времени на стык двух и более людей там, где этого не должно быть. х2-х5 достигается только через сокращение транзакционных издержек по всей цепочке.M Код агенты читают недетерминированно. Для поиска нужного места, по сути, у них есть только grep. Качество поиска нужных мест и понимания того "как должно работать" таким инструментом не очень высоко. И плавает от вызова к вызову. Отсюда и необходимость "надслойки" над кодом. В виде спецификации - это потому, что привычно человеку. Человек может посмотреть, может осознать, поправить, написать и "согласовать с бизнесом". Но для агентов чтение текстовой спеки -такой же сложный процесс, как и чтение кода. И основной камень преткновения - связи. Пока система небольшая (условно, весь код и спеку можно поместить в контекстное окно), то это не больно. Пласт разработки персональных инструментов под конкретную задачу так спокойно можно закрыть. Но любой мало-мальский продукт - это уже больше контекстного окна однозначно. И встает вопрос - а где по коду у нас разбросано использование данных и методов класса "пользователь", как и что поменяется, если поле "цвет глаз" сделать обязательным, а скидку персональной, а не привязанной к продукту? И из сложности поиска связей грепом (что в коде, что в спеке) вырос третий класс решений - основанный на графах. В граф можно положить как взаимосвязи в кодовой базе, так и взаимосвязи в спеке (юзкейсы, шаги, требования, формы, данные). Основное отличие графа от текста - у него есть cypher-язык запросов. Такой же точно sql, только на графе, а не на реляционных таблицах. У него два преимущества: - детерминированность - объем Мы тратим на 90% меньше токенов чтобы вкурить ту же информацию. При том каждый агент гарантированно получает на вход один и тот же контекст (при выполнении одних и тех же запросов) Таким образом мы получаем более удобную для агентов "точку правды", чем код или текстовая спека. А без "точки правды" агенты начинают перепридумывать то, что уже реализовано. Делать одно и то же в разных местах.M Н M Это просто две стороны одной медали :) Был вопрос про "зачем нужна спека и методика, где спека лежит в основе". Собственно, это ответ. И я полностью согласен, что сделать без спеки MVP - вполне рабочее решение. Просто нужно быть готовым, что для промышленной эксплуатации его придётся полностью переделатьУ
У
АлександрА вам не кажется, что все эти вбросы от создателей нейросетей пошли уж слишком кучно? То ChatGPT перестал отвечать на хорватском языке, потому что обиделся. То Grok вдруг бунтует против Маска. Теперь вот продукт от Anthropic неожиданно заговорил на санскрите. Пахнет обычным рекламным разводняком: мо
Вот сколько ни пробовал, и так и сяк, всегда пока что результат получается один.
А результат следующий: любая AI-managed-документация очень быстро превращается в месиво. И уже при среднем объёме и внутренней сложности выносит контекст даже фронтир-моделей так, что они начинают адски галюцинировать просто от того, что в них загрузили документацию слоя продукта, которая сложнее таск-трекера.
Пока человек не будет сидеть и ручками выводить важные вещи, максимально сокращая количество слов и полируя контекст под задачу, пока что ничего не получается. И надо какой-то следующий фундаментальный шифт в развитии ИИ (на уровне изобретения reasoning-а), чтобы оно начало выходить за эти границы. Пока нет.
Ссылка
нажмите — покажем
нажмите — покажем
Мне очень нравится идея Jev https://typesafe.ai/blog/introducing-system-one-models-and-jev
На вход получают контекст и варианты ответов. Взяли небольшой трансформер, на выходе не генерируют текст, а разом выдают вероятность ответов. Это можно использовать как fuzzy классификатор или как вероятности необходимых в данный момент действий. И это достаточно, чтобы играть в Doom, змейку, Fluppy Bird. Основной кейс применения — это встраивание в пайплайн, где нужна быстрая классификация. У нас в нескольких системах в проде для этого используется Gemini 2.5/3, она относительно быстро определяет по какой ветке алгоритму дальше нужно идти. Но это долго, потому что надо ждать генерация структурированного текста. Получил доступ к Jev, буду тестировать.
Из того, что по этому поводу вчера было в сети, больше всего понравилось это: https://github.com/vllm-project/vllm/pull/57250. У Google был смазанный релиз DiffusionGemma, которая очень быстро умеет генерировать текст с помощью Diffusion, итеративными уточнениями заполняя пропуски. Это очень недооцененная вещь, к которой относятся как у LLM. Но её сила в скорости, в одновременности генерации пропущенных токенов, и еще она умеет заполнять пропуски токенов между правой и левой частью — вписывать в контекст. Ну так оказалось, что DiffusionGemma из коробки может работать как Jev.
И ещё это породило у меня в голове такую конструкцию. Что если у нас будет трансформер, а ниже будет встроенный Jev как орган его мозга, который оценивает вероятность, нужно ли еще итерацию подумать (chain of thounght на уровне латентных векторов, не текстом), или нужно вызвать какой-то tool, или пора напечатать ответ.
Короче, Jev — очень простая идея из серии, жалко, что не я придумал, очень сильно ощущал в ней потребность.
17 · 1.6K · M V
М М У
Макеев: как перестать вайбкодить и начать жить• И еще спека не должна превращаться в википедию. Не надо с неё начинать любые изменения в коде. Большая часть изменения должна делаться агентами сразу в коде. В спеке — только фундаментальное.
• И если ваш SDD flow перемудренный, то он не работает.
• И вообще SDD не панацея.
Ссылка
нажмите — покажем
нажмите — покажем
SDD это не панацея а качественный переход в следующий этап эволюции в разработке кода, когда надо и доку и промпт собрать в одно и потом реализовывать это на любом языке программирования
Добавлю видео по sdd
https://m.youtube.com/watch?v=oDxODi3X2Mg
P У писателя по фамилии (вроде бы) МакКласки была в прошлом десятилетии популярная трилогия про Трилисков, я первую книжку прочитал, довольно интересно написано, писал явно программист но фантазия у него была хороша... там парочка попала в ловушку где мир изменялся вокруг них подстраиваясь под их мысли и воспоминания... так вот там дело происходило в далёком будущем и там у всех людей были в голову вживлены импланты и они всегда ходили и подсоединялись к сервисам которые были везде, ну вот я почитал про масковский нейролинк и сейчас увидел этот ваш Muse Charm и сразу вспомнил ту книжку про Трилисков. Как-то почуялось что оно действительно движется примерно в этом направлении, если подумать и примерно проэкстраполировать на отдалённое будущее