Часть первая. Караул устал Рассказали мне историю. Поучительную, спешу поучить. По АйАйному нетелеграму пронёсся хайптрейн про СУПЕРСИЛЫ, которые дадут вам СУПЕРСИЛЫ. . Обещается набор скилов для вашего Клода, который поднимет культуру разработки на недосягаемую высоту, внедрит полный фарш передовых опытов SDL прямо в контекст агентов и сформирует вам персональную инжиниринговую армию из бренштормов, продактов, фасилитаторов, SDD, TDD, ИТД. Знакомец повёлся. Красиво загрузил. Красиво запустил. Красиво поговорил с продактом и архитектором, получил миллион страниц красивых букв и красиво сказал — выпекай. ушла в глубокий 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, если читать его трезво. Если бы я хотел тут поставить точку — поставил бы. Но мне кажется, тут есть ещё один поворот. Потому что мы только что много говорили про эмпирику и реальность. А что если сама реальность, на которую мы смотрим, тоже не та?-Источник
