Комментарии 5
На ваш вопрос про тех, кто гоняет агентов подолгу.
У меня исследовательский проект на Rust, агенты работают часами в автономном режиме, бывает и днями/ночами. Спеки есть, но в другой форме: перед каждым запуском замораживается протокол - что меряем, что считается успехом, какие проверки блокирующие - и только потом сборка.
План и отчёт ревьюю сам, плюс отдельная модель-рецензент. /goal использую, но с оговоркой: он честно не даёт агенту остановиться, и агент начинает искать себе работу там, где уже нужно решение человека. Пришлось явно записать, что прямое указание владельца важнее цели.
Три вещи, которые обошлись мне дороже всего и которых в схеме не видно:
Проверки могут быть зелёными при общей ошибке. У меня два независимых исполнения совпадали побитово и долго пропускали баг: оба опирались на одно неверное допущение в постановке. Смена модели-исполнителя от этого не спасает. Помогает одно: ожидаемый результат выводится отдельно от кода, и проверяется, что намеренно внесённый дефект тест действительно ловит.
В handoff нужно писать не только «что дальше», но и «что ещё работает». На длинных задачах тишину от агента легко принять за остановку и запустить дубликат поверх живого процесса. Теперь в передаче обязательно: ревизия, команда проверки, где лежит её журнал и какой процесс ещё идёт.
Реестр решений не спасает от переоткрытий. Я несколько раз заново «находили» то, что уже было найдено и записано, потому что новый этап стартовал, не сверившись с тем, что уже умеет система. Сейчас перед каждым блоком работ - обязательная опись: что из этого уже есть.
И вопрос к вам: запрет агентам править backlog.md и критерии приёмки держится на инструкции или ещё на чём-то? У Anthropic в исходном тексте для этого хуки - блокировка правок тестов на время фикса; у нас поверх инструкции стоят контрольные суммы замороженных файлов, одной инструкции не хватило.
Привет!
> агентам править backlog.md и критерии приёмки держится на инструкции или ещё на чём-то? У Anthropic в исходном тексте для этого хуки - блокировка правок тестов на время фикса
По хорошему, да, нужно переносить на хуки, но для меня пока это будет overkill. Пока они не пытались даже поправить самостоятельно + я могу это держать на контроле и увидеть изменение в файле банально через гит.
И спасибо большое за комментарий, попробую и посмотрю на хуки, возможно их можно использовать не только как guardrails, но и как способ экономии токенов/сбор контекста.
Вопрос к вам: подскажите, я правильно понимаю, что есть по итогу один большой или несколько файлов, которые описывают работу системы и они актуализируются после каждого прохода, а перед началом агент сверяется с актуальной докой? И если так, то нет ли дрейфа, если работаете в команде?
Выражу свое мнение по поводу SDD как концепции, хотя никто не спрашивал.
1. Мне абсолютно не нравится, что SDD пытается в себя взять условную Jira + Confluence.
2. Spec's не место в коде (код для текущий агентов самодостаточный и он абсолютно легко ими читается на любом языке агентами, без необходимости спек)
3. Это раздувание потребления токенов
4. Гораздо выгоднее все спеки перенести в тесты Unit/E2E и так далее, чтобы условная проверка на соответсвтие спекам, не жрала токены а просто запускала один процесс(пусть будут тесты)
5. Antropic конечно выгодно это, больше потребление токенов больше выручка
6. Говнище Навязанное решение ваше SDD
7. Почему-то кто то решил, что спеки должны делать программу иммутабельной(чтобы по спекам можно было ее воссоздать), зачем тогда система контроля версий
Складывается ощущение, что SDD — новый карго-культ.
Генерируем тонны текста, который не нужен ни пользователю, ни агентам.
Тут на ESEM 2026 недавно был доклад, где рассказали, что почти 90000 PR, в рамках исследования, не получили никакого прироста качества от использования SDD.
Ну и вообще советую https://specroot.io/research/spec-driven-development-studies/ почитать. Помогает снять розовые очки.
Ограничение в два полных пересмотра плана, после которых агент переходит к вопросам делаем/не делаем, мне кажется самой практичной находкой в тексте. Про сверку отчётов с планом: я пришёл к тому, что проще, когда у каждого критерия приёмки есть свой идентификатор, тогда в report.md агент ссылается на них, и пропущенный критерий видно без чтения всего кода. Я делаю SpecScore.md, открытый формат спецификаций на Markdown + YAML, который линтится в CI, как раз под такие проверки. Вы сверяете критерии из плана с отчётом вручную или поручаете агентам?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SDD в организации и в Solo‑проекте