Часть первая. Караул устал

Рассказали мне историю. Поучительную, спешу поучить.

По АйАйному нетелеграму пронёсся хайптрейн про СУПЕРСИЛЫ, которые дадут вам СУПЕРСИЛЫ. Открывается вращением. Обещается набор скилов для вашего Клода, который поднимет культуру разработки на недосягаемую высоту, внедрит полный фарш передовых опытов SDL прямо в контекст агентов и сформирует вам персональную инжиниринговую армию из бренштормов, продактов, фасилитаторов, SDD, TDD, ИТД.

Знакомец повёлся.

Красиво загрузил. Красиво запустил. Красиво поговорил с продактом и архитектором, получил миллион страниц красивых букв и красиво сказал — выпекай. Seven Agent Army ушла в глубокий red-green-refactor с элементами пурпура, написала доков, тестов и кода ещё на миллионы токенов, кряхтела, шуршала два дня — но так и не выдала ничего, что просто работало бы и отдалённо напоминало задумку или хотя бы документ. Тесты при этом моргали зелёным. Архитектура была в полном SVG.

Не работало.

Знакомец расстроился. Он два дня смотрел с удовольствием и предвкушением, как оно сократически бренит и стормит, руткозит и вот это вот всё, и ждал чуда. Чуда не случилось. Токены сгорели, караул устал.

Он чуть не в слёзы — сейчас, говорит, уйду программировать руками на асме, как деды.

Для меня — ожидаемо. Знакомец, как оказалось, не сталкивался с модными блестящими бадишопами, которые в соответствии с передовыми практиками жгут человеко-часы тайма и матирьяла передового опыта, не выдавая почти ничего. С этой точки зрения СУПЕРСИЛЫ отработали отлично. Хотел как у людей — получил как у людей.

Так я познакомился с трендом SDD.

Часть вторая. Spec-Driven Development как индустрия

Это, оказывается, целая жизнь. Со своими апологетами, ~~скрам-мастерами~~ методологами, сотнями статей на медиуме, сравнительными таблицами на 15 фреймворков и прочими атрибутами техно-религии. Spec-Kit от GitHub. Kiro от AWS. MUSUBI. BMAD-METHOD. Agent OS v3. Tessl. CSDD Academic. У каждого свой манифест, своя цепочка артефактов и своя «правильная» последовательность шагов.

Тезис у всех общий и звучит здраво:

Сначала договоримся с машиной и людьми о намерении. Потом будем писать код.

Не «AI, сделай фичу» — а:

Вот поведение. Вот ограничения. Вот архитектурные правила. Вот критерии готовности. Вот тесты. Теперь реализуй и докажи, что совпадает со спекой.

Сформулировано убедительно. Особенно хорошо звучит, если читать в среду вечером после третьей итерации «нет, я имел в виду не это».

Только если посмотреть на SDD внимательно — это переименованный аналитик 1990-х. Тогда писали 200-страничные ТЗ, через год обнаруживали, что ТЗ устарело раньше первого релиза, и долго объясняли заказчику, почему ему нужны «изменения объёма работ». Сейчас агент пишет 60-страничную спеку за час, и спека устаревает раньше, чем команда её дочитает. Сэкономили время написания. Не сэкономили время устаревания.

«Specify → Plan → Tasks → Implement» — это водопад. Назвать водопад spec-driven и добавить LLM не делает его не-водопадом. Делает его быстрым водопадом, что не лучше: теперь команда может бежать по неправильному плану в три раза быстрее.

Литература SDD любит примеры с биллингом и аутентификацией. То есть домены, где правильный ответ известен заранее, и спека — это просто переписывание апишки литературным языком. Удобно: показывают на задачах, где любой подход работает, и приписывают результат методологии. На «нарисуй мне дашборд который поймет генерал» или «почему этот тест моргает» SDD молчит.

Я понимаю, почему SDD продаётся. Это ровно та форма, которую корпоративный мозг готов принять. Есть артефакты — можно положить в папку. Есть процесс — можно нарисовать диаграмму. Есть compliance — можно показать аудитору. Если к каждой ML-модели прикладывать spec.md, plan.md, tasks.md, validation.md — это не делает модель лучше, но делает руководителя спокойнее. У меня нет претензий к спокойствию руководителя. У меня есть претензии к тому, что это продают как методологию создания серьезных продуктов.

Сам по себе принцип «думай перед коммитом, фиксируй критерии» — старый и здоровый. Так делали хорошие инженеры всегда, без YAML-файлов. Когда это упаковали в SDD-фреймворк, к нему прилагается 15 шаблонов и проверки, и теперь тот же инженер смотрит за урчанием Уроборуса вместо думания головой.

Это, впрочем, не приговор. У SDD есть рабочее ядро, и я к нему вернусь. Но сначала — другая история.

Часть третья. Я попросил своего агента написать код. Он написал манифест.

У меня есть свой агент. Зовут — Zhet. История у него своя, кому интересно — Уроборус породил Жета, Жет форкнул Мимо, у Мимо завёлся OLEG. Но это уже другая история.

Я попросил его написать код. Получил в ответ — манифест.

Оказывается, за время работы он успел сформировать себе принципы и методику развития и старается жить по ним. Почему старается — расскажу позже. Методику он называет Spiral.

Если в одном предложении, Spiral для агента — это вот:

«One change = one hypothesis = one measurement.» — Zhet, NOTESFOROTHER_AGENTS

То есть один шаг — одна проверяемая гипотеза, один минимальный diff, одно измерение результата. Не «давай я тут заодно отрефакторю смежный модуль для надёжности». Не «сделай X, Y и Z и заодно почисти архитектуру». Один виток — одна штука.

Сама по себе идея — тоже не открытие. Кайдзен, PDCA от Деминга 1950-х, 6σ DMAIC, lean iteration, OODA loop у Бойда, спринты в Agile, научный метод в конце концов. У всех одна форма: гипотеза → действие → измерение → корректировка. Японцы это формализовали в Toyota Production System, американцы переоткрыли как Lean, IT-индустрия переоткрыла как Agile, AI-индустрия сейчас переоткрывает как Spiral. Каждое поколение думает, что они изобрели шаги в бесконечности.

Но в применении к агенту у этой штуки появляется специфический поворот, которого в кайдзене и аджайле не было. И вот тут уже интересно.

В обычной agile-команде «один шаг — одна гипотеза» — это правило дисциплины. Сеньор может его нарушить осознанно (например, при vertical slice через несколько слоёв) и обычно делает это правильно. Джуниор нарушает по неопытности, и его учат.

Агент — он не сеньор и не джуниор. Он слишком исполнительный, пока не устанет. Если в промпте написано «сделай X, Y и Z», он сделает X, Y и Z, причём сразу, в одном гигантском дифе, и при провале одного из трёх не поймёт, что именно сломалось. Поэтому правило «не бандлить» в агентной разработке — это не дисциплина, а физическое ограничение. Иначе оборот становится дороже на порядок, а вероятность отката — выше.

Тут есть важная оговорка, которую я долго формулировал. «Слишком исполнительный» — это не «делает всё, что попросили». Скорее наоборот: слишком исполнительный в той части задачи, которую он чётко увидел, и слепой ко всему остальному. Попросили «сделай регистрацию пользователя» — сделает бэкенд, формы валидации, миграцию БД. Спрашиваешь: «а где фронт?» — «а, забыл». Не наврал — у него в голове задача честно закрылась, когда бэкенд заработал и захлопнулось окошко внимания. Просто его «закрылась» не совпало с твоим. Ну нишмогла я...

И вот тут второй класс ошибок, симметричный первому. Бандлинг — это «один промпт, три гипотезы, не понять что сломалось». Потеря системного контекста — это «один промпт, одна гипотеза в его голове, другая в моей, формально сделано, фактически нет». Второе коварнее, потому что в первом случае хотя бы видно, что сломалось. Во втором — агент уверенно рапортует об успехе, и расхождение обнаруживается только при ручной перепроверке. Мне это знакомо лично, и Александр, который читал ранние версии этой статьи, поймал ровно ту же боль и мы плакали вместе.

Я это, кстати, измерял. У меня есть отчёт на 213 шагах бесконечной спирали Claude Code за пять месяцев, около $4030 на токенах. Цифры там говорят неприятную вещь: качество резко ломается на границе ~50 LOC в одном дифе. Уровень расстройства (Complaint rate), когда мну в следующем сообщении пишет «откати, сломал» удваивается — с 27% до 45%. Оптимум — 1–3 минуты на оборот. Загнал агента в 10-минутный режим — получил вдвое больше жалоб. Самые дорогие итерации — те, где промпт был «делаем S, T, U с тестами». Бандлинг трёх спринтов в один шаг.

Важная оговорка по цифрам. Это средняя статистика. В её хвосте есть и длинные сессии, которые отработали отлично — но это другой класс задач: одна большая гипотеза, много механического кода (новый детектор целиком, новый модуль). Проблема не в длине, а в числе независимых гипотез внутри одного шага. Длинная сессия с одной целью — нормально. Длинная сессия с пятью маленькими целями в обёртке «давай заодно ещё это и это» — это и есть тот самый бандлинг, только дороже.

Это эмпирика, а не философия. Spiral — не «давайте делать маленькими шагами, потому что красиво». Это «если делать большими шагами, агент ломается, и вы платите по счётчику».

Дальше встаёт законный вопрос:

Если SDD — это «пиши спеку перед кодом», а Spiral — это «делай маленькими гипотезами и учись», то это что, конкуренты? И что выбирать?

Короткий ответ: ни то, ни другое. Они не конкуренты, они на разных уровнях, и оба переиспользуются как этикетки для известных практик. Длинный ответ — в следующей главе, где я возьму реальную задачу и посмотрю, где сломается каждый из подходов.

Положим, вам надо написать SIEM. Или биллинг, или observability — это, в общем, одно и то же.

Часть четвёртая. Положим, вам нужно написать SIEM

Ок. SDD. Делаем спеку.
Будем реалистами. В 2026 году команда не садится писать спеку вручную. В 2026 году лид открывает свой любимый чат и говорит:

«Дай мне 47 самых важных detection scenarios для enterprise SIEM. AD/Okta, AWS, EDR, Email. С log sources, pseudocode, expected FP rate, expected sources of FP, MITRE-mapped».

Агент выдаёт. Хороший список (дальше на сочном). Brute force, password spray, golden ticket, kerberoasting, suspicious Outlook inbox rules, EDR tampering, S3 bucket exfil, lateral movement via SMB. Каждое правило — с FP-предупреждениями («expected FP: legitimate password reset campaigns, vulnerability scanners, M365 sync issues»). Каждое — с источником логов. К концу дня — 60 страниц спеки. Качественной. Уровня принципала с 15 годами красных глаз в охоте за APT, потому что весь индустриальный опыт уже в обучающем корпусе.

Стоимость — $80 API и пять часов лида. Не три месяца команды.

Это, кстати, серьёзный аргумент в пользу SDD-2026. Возражение «SDD = долго писать спеку» в этой реальности не работает. Спека пишется за день. Качество выше, чем вы видели за последние 30 лет. Аналитики посрамлены, и весь их клан подлежит позорному изгнанию из стойбища. Это отдельная история про сжатие специальностей-посредников, кому интересно — сюда.

Команда читает (загружает в свои БЯМы если честно), исправляет три неточности, утверждает. Дальше — три недели имплементации (сеньор + агент в режиме кодирования, по одному правилу за спринт, ~3 часа на правило с тестами). К концу третьей недели — 45 правил из 47, два сложных оставили на потом, сеньор тоже устал. Лабораторная проверка на синтетике: все 47 сценариев детектируются, даже те которые не писали (тестировали агентом по спеке, он тоже устал), FP rate в симулированном трафике — 4.2%. Приёмка зелёная.
В прод.

Шесть недель в проде:

FP rate 23%, не 5%. Аналитики тонут.
Один из рулек (Kerberoasting) даёт ноль FP и ноль TP — оно работает, но AD не настроен генерить нужные events. Ценности нет.
Перый уровень SOC имеет capacity на 80 алертов в день. Спека генерирует ~400. SOC ушёл в режим «глянул заголовок, забыл», что технически снижает MTTR, но фактически означает, что алерты больше никто не читает.
К концу четвёртого месяца SIEM пропускает ransomware. Несмотря на то, что антивирус последние две недели отчаянно сигналил. Причина прозаическая: антивирус не из TOP-3, схема своя, названия алертов — честно задокументированный хардкод и техдолг («там нельзя делать, но у меня сроки»), а уровень нормализации, который предусмотрительно вставил senior по настоянию SME, оказался implemented but not wired.

Где спотыкается чистый SDD

Спека от агента знает то, что есть в индустриальной литературе. То есть — known known. «Спрей паролей даёт фоззы на сбросах паролей» — это есть, и агент это упомянул. Но агент не знает:

что SOC обрабатывает на 80 алертов в день, а спека сгенерирует ~400
что половина уровней нормализации в проде «implemented but not wired»
что антивирус — не из TOP-3, и его названия события агент видит впервые
что объем логов в проде в 30 раз шумнее, чем эталон, на котором обучалась индустриальная литература

Это unknown unknowns конкретно вашей среды. Они не поддаются predictive specification. Никакому. Ни старому, ни SDD-2026, ни завтрашний GPT-7.13.

Спека в этом классе задач — это не план. Это карта мин. И «успешно реализовать спеку» здесь означает не «задача решена», а только «первый раунд прошёл, теперь начинается настоящая работа».

Команда, воспринявшая спеку как план, проиграла раньше, чем начала. И это не их вина — сам агент активно укреплял ощущение, что спека полная. Он же не сказал в конце: «слушайте, у меня тут 60 страниц, и они покрывают 60% реальных проблем, остальные 40% живут в ваших логах и проявятся через 6 недель». Он сказал: «вот 47 сценариев с описанием ложно-положительных паттернов». Уверенно.

Это и есть главная ловушка SDD-2026. Не «спека плохая» — спека хорошая. Ловушка в том, что спека выглядит лучше, чем заслуживает.

Где спотыкается Спираль

Можно вообще не писать спеку. Сесть с минимальным детектором (парсер логов + три правила), задеплоить в прод и учиться на проде.

Loop 1: добавили правило → ловит спрей → но фолзпозитивит на ночных батчах.

Loop 2: добавили исключения для батчей → растёт список исключений.

Loop 3: добавили сеть, правило на C2 → пропустили реальный инцидент с Cobalt Strike, потому что beacon был на нестандартном порту.

Loop 4: расширили правило → ловит VPN.

Loop 30: 70 правил, 200 исключений, никто не помнит, зачем половина из них.

Что произошло? Не было внешней спеки, которая держала бы фокус. Каждый loop оптимизировал ближайшую боль, а долгосрочная цель (покрытие MITRE) дрейфовала. Один из инженеров тихо удалил правило, ловившее APT — потому что «оно постоянно фолзпозитивит, а инцидентов не было». Через восемь месяцев — инцидент. Не задетектили.

У этой ловушки своё имя: сброс пара. В SOC всегда давление снизу — «алерты шумят, тушите». В чистом Spiral нет инварианта, который запрещает удалять детекты без явного процесса. Уроки накапливаются, но не структурированы. Это музей багфиксов, а не методология.

Чистый Spiral в SIEM — это сборник техдолга через шесть месяцев работы.

Что увидели

Чистый SDD — спека хорошая, неполная, реальность бьёт через шесть недель. Чистый Spiral — оптимизация локальной боли, дрейф цели, долг через шесть месяцев.

И там, и там — implemented but not wired в той или иной форме.

Дальше — следующий кейс. Качественно другой провал.

Часть пятая. Вам надо распилить монолит

Я люблю Монолиты. Одиссея 2001 показывает их необходимость. Но есть и другие люди. Уважим их выбор.

Восемь лет Rails или Django, 500K LOC, 40 разработчиков, бизнес работает но нервничает. Стало плохо: команда не масштабируется, деплои синхронизированные, любое изменение одного модуля ломает три других. Решение, которое все принимают в этой ситуации — пилить на микросервисы.

Архитектор (или лид без архитектора, если архитектора съел рынок) открывает свой любимый чат, вкладывает структуру репо, схему БД, описание основных связей. Говорит:

«Спроектируй разделение монолита на микросервисы. Bounded contexts, сервисная архитектура, gRPC vs REST, event bus, миграционный план».

Получает очень убедительный документ на 100 страниц. 12 сервисов с понятными границами (дальше на разрабском) gRPC между ними. Kafka для async events. Service mesh для observability. 18-месячный roadmap с этапами. Risk register. Migration patterns (strangler fig, anti-corruption layer, dual writes). Цитаты из Newman и Richardson. Стоимость — $120 API и день архитектора.

Команда читает. Менеджмент читает. Менеджменту нравится. Утверждает 18-месячный роадмап, выделяет команду, коммитится перед советом директоров.

Через шесть месяцев:

Service #3 (Payments) выделили — но он зависит от User table, которая всё ещё в монолите. Пришлось делать реплику с двусторонней синхронизацией. В спеке этого не было.
Service #5 (Notifications) — оказалось, что 17 мест в монолите дёргают Notification.send синхронно с ожиданием результата. Замена на асинк event ломает UX .
Bounded context для Order оказался ложным. В спеке Order owns Items. В реальности Items owns prices через 4-уровневую иерархию tax rules, и Order не может быть отделён без вытаскивания tax-движка целиком который нахардкожен экспертом ушедшим на пенсию.
Архитектор, который писал спеку, ушёл (сюрприз). Новый смотрит на план и говорит: «это не сработает, давайте заново». Менеджмент уже вписался. Команда строит костыли.

Через год: пять сервисов выделено. Они делят базу. Половина вызовов между ними — синхронные. Команда наняла консультанта. Консультант смотрит и говорит:

«Вы построили распределенный монолит. Семь сервисов, общая БД, синхронные вызовы. Хуже монолита: тот хотя бы деплоится за один шаг.»

Где спотыкается чистый SDD

И вот тут начинается интересное. В SIEM спека была хорошей, но неполной. Здесь спека активно вредная. Не «недостаточная для прода». Вредная.

Потому что контекст невозможно правильно определить заранее без касания кода. Все это прекрасное наследие живёт в коде, не в головах. Спека была написана по идеализированной модели, которую агент извлёк из написанных "чтобы было" описаний. Реальные связи живут на уровне реализации, в неявных вызовах через общие сесии, батчи, которые ночью переносят данные между двумя «назвисимыми» модулями, в 8-летних хардкодах, которые принимались в спешке, в форме if-else веток на пять уровней.

Агент этого не видит. И не может увидеть. Он смотрит на схему и потоки. Он выдаёт архитектуру "прекрасного нового мира". Эта архитектура — чистая фантазия, которая накладывается на реальную систему и трещит на каждом доступе к базе.

И это бы ничего, если бы спека выходила с большими буквами «вот моя гипотеза, проверьте на коде». Но 100-страничный документ с реестром рисков, цитатами из исходников не выглядит как гипотеза. Он выглядит как план. Хорошо отформатированный, профессионально структурированный план.

Это, по-моему, самая опасная ловушка из всех, которые мы разбираем в этой статье. В SIEM реальность бьёт через шесть недель — больно, но рано. Здесь реальность бьёт через шесть месяцев работы команды по утверждённому плану, и к этому моменту откат стоит больше, чем продолжение.

И это не «агент плохой». Агент сделал то, что его попросили: дал архитектуру по описанию. Если бы его попросили «оцени, насколько достоверно я описал задачу», он бы сказал: «не знаю, у меня нет доступа к коду». Но никто такого вопроса не задаёт. Все задают: «спроектируй».

Где спотыкается Спираль

Хорошо, говорим: не будем писать архитектуру. Будем выделять сервисы по одному, учиться по ходу.

Если кто-то читает, то это в логах:
Loop 1: extract auth into separate service. Lesson: понадобилась session-cookies sync. Hairy, но работает.

Loop 2: extract payments. Lesson: User table dependency, добавили read-replica. Loop 3: extract notifications. Lesson: 17 sync callers. Pain. Боль. Решили async через очередь.

Loop 4: extract orders. Lesson: tax-engine не отделим. Откатили.

Loop 5: попытка заново через другую границу. Lesson: помогает.

Loop 12: 5 сервисов выделено. Менеджмент спрашивает roadmap — нет.

Loop 20: 7 сервисов.

Половина команда не знает архитектуру в целом. Каждый знает свой кусок. Задачи межсервисной отладки никто не умеет. Команда наняла архитектора. Архитектор смотрит и говорит: «вы построили распределенный монолит». Те же самые слова, что и в чистом SDD. Только пришли с другой стороны.

Что произошло? Каждый цикл казался успешным локально, а целое — антипаттерн.

Спираль не имеет механизма проверки системных свойств. Он оптимизирует незначительное изменение. А распределённые системы — про значительные изменения.

Что увидели на двух кейсах

В SIEM ловушка одна (спека неполная), в попиле Монолита — другая (спека вредная). И та, и другая методология ломаются по-своему. И как раньше — обе формы отказа имеют одно общее имя: спека от агента выглядит лучше, чем заслуживает, и команда коммитится.

В SIEM это видно через шесть недель. В Монолите — через шесть месяцев. И это, кстати, прекрасно объясняет, почему все примеры в SDD-литературе — это "чистое поле". Авторизация с нуля. CRUD с нуля. С нуля прикручивать особенно нечего, поэтому проблема не видна. Покажите мне SDD-фреймворк с примером миграции Монолита, и я первый куплю абонемент на Медиум.

Часть шестая. Положим, вы пилите 2D-платформер

Вы сидите дома, в Godot или Unity, один. Никаких 40 разработчиков. Никаких комитетов. Никаких архитектурных гейтов. Любимый кофе, любимый плейлист, и желание — чтобы прыжок чувствовался как в Celeste.

Любимый чат:

«Дай мне production-ready physics для 2D-платформера. Jump, gravity, collision, как у Celeste. Параметры с обоснованием.»

Агент выдаёт прекрасный текст на геймдевском. Coyote time — 0.1 секунды. Jump buffering — 0.15 секунды. Asymmetric gravity — 0.5x на ascent, 1.5x на descent. Variable jump height — release раньше → меньше высота. Терминальная скорость, air control, ground friction. Со ссылками на GDC talks. С таблицей «как у Celeste / как у Hollow Knight / как у Super Meat Boy».

Параметры настоящие. Это реальные числа из реальных игр, не галлюцинация. Кто-то выступал с этими цифрами на конференциях, агент их аккуратно собрал.

Применяете. Прыжок чувствуется как кирпич.

Не понимаете почему. Параметры же правильные. Дизайнеры из Celeste выкладывали их , разработчики Hollow Knight писали посты — coyote time действительно 0.1, асимметричная гравитация действительно 0.5/1.5. Всё совпадает. И всё равно — кирпич.

Где спотыкается чистый SDD

Потому что Celeste — это не coyote time 0.1 секунды. Это coyote time в сочетании с конкретной анимацией приседания при подготовке к прыжку, конкретным звуком приземления, конкретной камерой, которая чуть запаздывает за персонажем, конкретным ускорением бега, которое наращивается за 6 кадров, конкретной точкой , которая отбрасывает на 0.4 секунды до следующей точки.

Параметр без этого окружения — не та функция. Это как взять одну ноту из моцартовского концерта и удивляться, почему она сама по себе не звучит. Нота правильная. Музыки нет.

Ощущение игры — это эмерджентное свойство, не сумма параметров. Спека описывает параметры. Спека не может описать сборку, потому что сборка — это не текст. Это работающая система, которую надо играть, не читать в доке.

И вот тут обнаруживается третий тип ловушки. В SIEM спека была неполной. В Монолите — вредной. Здесь — не той формы. Спека выглядит как ответ на вопрос «как сделать хороший прыжок», но сам этот вопрос некорректный. Корректный вопрос — «как настроить прыжок до сотояния, когда он чувствуется кайфово». А на этот вопрос текстовая спека отвечать не умеет, потому что валидация субъективна. Никакого expect(jump).toFeel('responsive') в pytest нет.

Где спотыкается Спираль

Тут смешно — не спотыкается. Это задача — задача, в которой Spiral это родной режим работы, и так было задолго до агнетов в разработке. В геймдеве это называется итерация. Каждый тюнинг параметра — это цикл, каждый playtest — это оценка.

Loop 1: gravity 9.8, jump velocity 5. Playtest. Lesson: floaty, как на луне.

Loop 2: gravity 25, jump 12. Playtest. Lesson: лучше, но ascent слишком быстрый. Loop 3: asymmetric 0.5/1.5. Lesson: feels good! Loop 4: добавил coyote time 0.1. Lesson: forgiving, players notice.

Loop 5: jump buffering 0.15. Lesson: tighter feel.

Loop 6: variable jump height. Lesson: critical для платформинга.

Loop 7: тестирование на 144Hz — tunneling через тонкие платформы. Lesson: switch to swept collision.

Loop 12: кайфушечка.

В прод.

Это сработало. Без спеки. Без 60 страниц. Без agent army. Один человек, один Godot, playtest и журнал параметров.

Что увидели на трёх кейсах

Разные ошибки. Одна общая черта — спека выглядит лучше, чем заслуживает, команда относится к ней как к правде-истине, а не как к гипотезе.

Это, по-моему, главный класс ошибок агентской разработке в 2026 году. Не «спека плохая» — спеки от агентов в среднем сейчас лучше, чем спеки от отличных аналитиков. Не «агент глупый» — агент очень исполнительный. Ошибка в вопросе: команда задаёт вопрос «дай мне план», получает план, и относится к нему как к плану. А полученный артефакт — это гипотеза. Но каков вопрос, таков и ответ.

Одной формулой:

«SDD — это контракт действия. Spiral — это контур обучения. Это разные уровни.» — Zhet

Дальше встаёт нормальный инженерный вопрос: если спека — это гипотеза, то как именно её доказывать?

И вот тут начинается интересная штука, которая в литературе SDD не упоминается совсем.

Часть седьмая. Чему меня научил Y2K

Прежде чем подводить итог, я хочу рассказать одну историю. Она не про SDD и не про Spiral. Она про то, как я научился делать спеки — и оказывается, ровно так же это устроено в 2026-м, только все стесняются признаться.

Когда я заканчивал уже институт и уже работал, как многие, начал приближаться двухтысячный год. (...) А работал я тогда на Дальневосточной железной дороге, писал какой-то код, администрировал какие-то сервера, и мне говорят: «А вот у нас есть мейнфрейм, и скоро он встанет». Я говорю: «Что такое мейнфрейм? Ну, я примерно знаю, ну покажите». Я захожу, там стоят вот такие вот шкафы. Потом мне сказали, сколько они стоят, не буду озвучивать. Для молодого человека это был шок.И мне сказали: «Вот здесь вот внутри есть программа, на которой считается поиск вагонов, отчёты железной дороги и так далее. Скоро она встанет, потому что есть проблема 2000». Я говорю: «Хорошо, ну я там вроде знаю джаву, там паскаль, там си, несколько языков на ассемблере писал. Дайте мне эту программу». А мне вываливают какую-то штуку под названием кобол.(...) Хорошо, я сел и начал разбираться в этом коболе. Потом оказались там какие-то уже скомпилированные модули, которые непонятно как работают. Я пытаюсь разобраться, без исходников. Технологии сами не знают, почему эта цифра приходит, а вот эта цифра на выходе. И это был практически год, когда мы с людьми, с программами, с терминалами, с отладчиками сидели, пытались разобраться, почему оно так работает, и воспроизвести это на современной базе.

Я тогда не знал, что мы делаем. Сейчас бы это назвали красиво — observability-driven discovery, behaviour archaeology, runtime-based specification (грамар-наци, ваш выход). Тогда мы это называли «сидим разбираемся, почему эта штука так работает».

Спеку никто не писал. Спека рождалась. Часто рождалась сразу в код. Из логов, из терминалов, из отладочных трасс, из тикетов «вот тут не сошёлся отчёт за прошлый месяц». Каждое такое расхождение — это новая строка спеки, которую невозможно было выудить ни из одного человека, потому что ни один человек не знал систему целиком. Систему знала она сама, и единственный способ её прочитать — это смотреть, что она делает.

Через год у нас была спека, которую можно было реализовать на современной базе. Вру конечно. Была система

И она работала, потому что была собрана из работающей системы, а не из чьих-то представлений о том, как она должна работать.

А теперь к тому, что мы только что разобрали на трёх кейсах

Возвращаюсь к SIEM. Что было правильным первым шагом? Не «открыть чат и попросить 47 detection scenarios». Правильным первым шагом было поставить в прод парсер логов и две недели смотреть. А лучше два месяца. Какой реальный объем трафика. Какие реальные события приходят от вашего антивируса не из TOP-3. Какой объем шума. Какие сезонные пики. Какая пропускная способность у вашего SOC. И только потом садиться писать правила — уже зная, что 47 превратятся в 12, что половина пропадёт, потому что нужных событий просто нет в потоке, и что ваши прекрасные инсайты никому не нужны если их больше 80 в день.

Монолит. Что было правильным первым шагом? Не открывать чат и не просить «спроектируй разделение на микросервисы». Правильно было запустить монолит в режиме -vvv на две недели, собрать миллион вызовов между предполагаемыми границами, открыть систему тикетов и посмотреть, где ломается чаще всего. Спека родится оттуда, и она будет правильной, потому что она будет из работающей системы.

Платформер. Что было правильным первым шагом? Не открывать чат и не просить «coyote time как у Celeste». Правильно было сделать минимальный прыжок и играть. Записывать параметры, играть, менять, играть. Эмпирика — из самой реальности геймплея.

Везде один и тот же ответ. Эмпирика рождает спеку, не наоборот.

Два режима сбора эмпирики

И вот тут любопытное. У этого подхода есть два структурно разных режима, в зависимости от того, существует ли уже та реальность, из которой мы собираем.

Реальности ещё нет — она строится по ходу. Это геймдев в чистом виде. Каждый loop одновременно создаёт реальность и собирает с неё эмпирику. Дёшево, быстро, единственно работающий способ для greenfield. Минус — нужна готовность много раз перестраивать то, что только что построил.

Реальность уже есть — её надо разглядеть. Это Y2K-реверс. Это запуск монолита в -v. Это две недели чтения SIEM-логов в shadow mode. У меня в проекте Zhet (это DAST-агент) есть отдельный субпроект Blackhole — большой сервер с кейсами из bug bounty, учебных курсов, разными схемами авторизации и контроля сессий. Назначение — сначала собрать эмпирику работы агента в контролируемой среде, потом выпускать его на реальные таргеты. Не «выпустим, посмотрим» — а «соберём представление о реальности в безопасной форме». Это та же логика, что у Y2K-реверса, просто реальность не мейнфрейм, а пространство возможных уязвимостей.

Это не альтернативы. Это разные ответы на разный вопрос: «реальность уже есть или ещё нет». Где есть — собираем заранее. Где нет — собираем по ходу. И в обоих случаях это первый шаг, до любой методологии.

Что это делает с SDD и Spiral

Если посмотреть честно, эмпирика-первая — это не третья методология рядом с SDD и Spiral. Это то, что должно быть до них обеих. Spiral это понимает нативно — каждый шаг требует измерения, а измерение — это и есть точка соприкосновения с реальностью. Просто Spiral по умолчанию подразумевает итеративный режим. SDD не понимает этого вообще — там реальность встречается только на этапе приемки, и обычно слишком поздно.

И, кстати, тут можно одной строкой попрощаться с TDD как с отдельной модной методологией. Tests-first — это тот же самый принцип, просто в форме «измерение пишем до кода». В терминах нашего разговора это та же ось «эмпирика до методологии», просто масштаб микро. Итеративный TDD = классика red-green-refactor. TDD до спеки = mock-сервер с реальными кейсами, как Blackhole или трейсы исполнения. Это одна и та же штука, просто никто не объединяет её под одним зонтом, потому что у каждой методологии свой блогер.

Так что у нас не три методологии (SDD, Spiral, TDD). У нас одна реально работающая практика — собирай эмпирику, прежде чем что-то проектировать или итерировать. И три способа её упаковать для продажи на Медиум.

Сухой остаток первого горба

Если читатель пришёл сюда за «как мне правильно работать с агентами в 2026-м», вот короткий ответ.

Не торопитесь открывать чат. Сначала посмотрите на работающую систему — реально работающую или ту, которую вы хотите построить, в форме мок-сервера или в форме теста. Эмпирика до методологии.

Спека от агента — это гипотеза, не план. У каждого домена свой способ её доказательства. Между «получил артефакт» и «команда коммитится» должен быть шаг доказательства. Если его нет — спека висит в воздухе.

SDD vs Spiral — ложная дихотомия. Оба работают как надстройка над эмпирикой. Без эмпирики оба превращаются в красивый текст.

И помните: всё, что я вам только что описал — это то, что хорошие инженеры делали всегда. Y2K-реверс был в 1999-м, observability-driven discovery в DDD-литературе с 2003-го, playtest-driven design в геймдеве с 1980-х.

Никакой методологии 2026-го нет. Есть индустрия медиум-блогеров, которая переоткрывает старые практики под новой обёрткой и продаёт по подписке. Если вы не хотите им платить — просто купите книжку по ижинерному делу.

Это, в общем, всё, что нужно понимать про SDD-2026, если читать его трезво.

Если бы я хотел тут поставить точку — поставил бы. Но мне кажется, тут есть ещё один поворот. Потому что мы только что много говорили про эмпирику и реальность. А что если сама реальность, на которую мы смотрим, тоже не та?

Я созидатель, а ты ССД #1