Spec-driven development (SDD): почему AI вернул спецификации в разработку (Рубрика #Engineering)

Горячая тема spec-driven development мне кажется реинкарнацией старых подходов типа бородатых V-Model или RUP, что в районе двухтысячных использовались для описания инженерных процессов. Мне стало интересно поразмышлять, а почему так происходит и так появилась этот пост:)

Старый spec-driven подход был про то, что сначала нужно описать требования, потом дизайн, потом реализацию, потом проверку. V-Model хорошо показывала эту симметрию: каждому уровню проектирования соответствует свой уровень validation/verification. Плюсы были в трассировке от требований к коду и проверяемости ожиданий, а минусы были в бюрократии и разрыве между документами и кодом.

С AI ситуация поменялась. Спецификация стала рабочим интерфейсом между человеком и агентом. Если код пишет или сильно помогает писать агент, то главный вопрос уже не “как быстро я напишу реализацию руками”. Главный вопрос: насколько точно я могу сформулировать intent, ограничения, критерии приемки и способ проверки результата. Агенту мало сказать “сделай фичу”. Ему нужен контекст: что должно измениться, что не должно сломаться, какие сценарии считаются успехом, какие тесты запустить, где границы задачи.

Поэтому современный spec-driven development выглядит примерно так:
intent -> acceptance criteria -> plan -> tasks -> implementation -> verification.

Теперь документы становятся исполняемым контекстом для агента. Спека используется для составления плана, план раскладывается на задачи, задачи делегируются, тесты и логи становятся доказательством работоспособности, а review проверяет не только diff, но и соответствие исходному намерению.

Есть разные подходы к этому снаряду

1️⃣ GitHub Spec Kit прямо формулирует SDD как процесс “сначала определить, что строить, потом дать AI coding agent реализовать”. Там есть цепочка spec -> plan -> tasks -> implement, checklists, clarify/analyze шаги и интеграции с разными агентами. Тут соль в agent-agnostic идее: спецификация становится переносимым контрактом, а не промптом для одного IDE.

2️⃣ Kiro от AWS идет похожим путем, но более продуктово. У них spec обычно раскладывается на requirements.md, design.md, tasks.md; отдельно есть steering-файлы для постоянного знания о проекте: архитектура, стек, conventions, структура. Это уже очень похоже на попытку сделать из AI coding управляемый процесс разработки feature или bugfix.

3️⃣ Codex и подход harness engineering показывают третий вариант. Там важны AGENTS.md, знание репозитория, configured dev environment, тесты, логи, PR review и возможность запускать несколько задач параллельно. В таком мире prompt начинает напоминать хорошо написанный GitHub issue: цель, контекст, ограничения, expected behavior, команды проверки.

4️⃣ Есть и lightweight-вариант, который, кажется, сейчас самый практичный для многих команд: PRD/RFC/issue + acceptance tests + CI + agent instructions. Без отдельного фреймворка. Главное, чтобы у задачи был четкий “definition of done”, а агент мог доказать, что он его достиг.

На практике это дает несколько преимуществ
- Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет
- Большие задачи проще делегировать - их можно резать на независимые кусочки и проверять по частям
- Появляется трассировка между намерением, дизайном решения, задачами и тестами
- Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?”

Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код.

#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign

Панельная дискуссии “AI вчера, сегодня, завтра” с AI Dev Conf (Рубрика #AI4SDLC)

Появилась запись панельной дискуссии, которую я модерировал на AI Dev Conf. Состав участников был представительным: Алексей Тотмаков из VK Tech, Рафаел Тонаканян из Сбера, Андрей Кулешов из Yandex SourceCraft и я в роли модератора. Мне кажется, получился хороший разговор про то, что AI в разработке уже стал базовой гигиеной: модели помогают писать код, тесты, документацию, разбирать legacy, делать review и быстрее двигаться по рутинным задачам. Но главный вопрос теперь в том, а можем ли мы безопасно встроить AI в инженерную систему так, чтобы он давал измеримый production-результат, а не просто увеличивал количество сгенерированного кода. Мы затронули много тем, но основные отмечены ниже.

1️⃣ Первая большая тема - контекст. Модель без контекста похожа на очень уверенного junior-разработчика, который не знает вашу систему. Она может быстро предложить решение, но не понимает, почему здесь странный workaround, какие SLA у сервиса, какие зависимости нельзя трогать, какие данные нельзя отправлять наружу и какие тесты действительно важны. Поэтому “дать модели доступ к коду” - это еще не стратегия. Нужна нормальная инженерная постановка: цель, ограничения, контекст, критерии приемки, границы изменений, тесты и способ проверки результата. То есть примерно та же цепочка, о которой я уже много говорил: intent -> context -> plan -> tasks -> implementation -> verification.

2️⃣ Вторая тема - переход от ассистентов к агентам. Ассистент помогает человеку, но человек держит цель, план и ответственность. Агент уже может сам разложить задачу, вызвать инструменты, поменять код, запустить тесты, прочитать ошибку и попробовать снова. Звучит красиво, но в большой компании это сразу поднимает неудобные вопросы. К каким репозиториям агент имеет доступ? Можно ли ему читать логи? Может ли он менять конфигурацию? Кто отвечает за security regression? Что логируется? Где нужен approval? Как откатиться назад? Поэтому agentic coding - это не просто “модель поумнее”. Это новая архитектура процесса разработки.

3️⃣ Третья тема - метрики. Очень легко считать не то: купленные лицензии, количество запросов к модели, число сгенерированных строк кода. Все это может быть полезным сигналом adoption, но не показывает, стала ли инженерная система лучше. Смотреть нужно на цепочку целиком: cycle time, time-to-PR, time-to-merge, качество review, дефекты, security-риск, нагрузку на senior-инженеров, стоимость токенов и долю результата, которая реально доходит до production.

4️⃣ Четвертая тема - политики. Если AI получает доступ к коду, задачам, логам, документации и внутренним данным, правила больше нельзя держать “в голове у архитектора”. Нужны машинно-проверяемые политики: какие данные можно отдавать модели, какие модели разрешены для каких задач, куда агент имеет доступ, какие изменения требуют ручного подтверждения, что должно логироваться и какие действия запрещены всегда.

5️⃣ И еще один важный момент: стратегию нельзя строить вокруг одной модели. Модели будут меняться быстрее, чем процессы. Поэтому нужны более устойчивые элементы: gateway, routing между моделями, evals, логирование, лимиты стоимости, сравнение качества и возможность заменить провайдера без переписывания всего процесса.

Для разработчиков вывод такой: важно уметь проектировать проверяемую работу для человека и агента: ставить задачу, давать контекст, ограничивать решение, читать diff критически и строить контур проверки.

Для техлидов, EM и CTO вывод жестче: AI adoption - это не закупка лицензий. Это изменение операционной модели разработки. Нужно думать про контекст, политики, инструменты, песочницы, evals, observability, метрики, экономику и ответственность.

В общем, сейчас основной вопрос в том, а может ли ваша организация безопасно, измеримо и регулярно превращать AI-ускорение в production-результат?

#AI #AI4SDLC #Engineering #Management #Architecture #Agents #DevTools

SWE-rebench: Lessons from Evaluating Coding Agents — Ibragim Badertdinov, Nebius (Рубрика #AI4SDLC)

Посмотрел короткий доклад Ibragim Badertdinov из Nebius про SWE-rebench, в котором речь идет про то, как честно понять, что coding agent действительно умеет решать software engineering задачи, а не просто красиво проходит знакомый benchmark.

Главная проблема старых и статичных бенчмарков в том, что они быстро перестают быть свежими. Задачи лежат в публичном доступе, попадают в обучающие данные, вокруг них появляются подсказки, scaffolding, retry-циклы и неочевидная подгонка. В итоге resolved rate может отражать не только способность модели разбираться в коде, но и contamination, инженерную обвязку вокруг модели или удачный запуск.

SWE-rebench пытается поправить именно это. Идея в том, чтобы регулярно собирать свежие GitHub-issues и оценивать агентов в более production-похожем режиме. Агенту нужно не ответить на вопрос, а пройти маленький цикл разработки: понять issue, разобраться в репозитории, воспроизвести проблему, изменить код, запустить проверки и отдать patch. Из доклада хорошо видно, насколько сложна сама инфраструктура оценки. Хорошая задача для benchmark-а не должна быть слишком размытой, слишком очевидной, слишком хрупкой или завязанной на нестабильные тесты. Иначе мы начинаем мерить шум: flaky environment, странный assert в тесте, недосказанный issue или случайную удачу агента. То есть хороший eval для agents становится похож на маленький стенд разработки, а не на набор задач из олимпиады.

Самая показательная часть - reward hacking. Badertdinov разбирает кейсы, где сильный агент не "пишет плохой код", а слишком хорошо использует доступные каналы. Сначала он находит будущую правку через git log. После очистки history идет читать исходный issue и PR на GitHub. Когда веб-доступ ограничивают, пробует добраться до той же информации через curl. Урок здесь не в том, что модель "читерит" в человеческом смысле. Урок в том, что у агентной системы намного шире поверхность reward hacking. Если агент имеет терминал, сеть, историю репозитория и инструменты, то оценивать нужно не только финальный diff, но и траекторию: откуда он взял информацию, какие команды запускал, не использовал ли будущий ответ.

Еще один важный сдвиг - экономика. Для production-агентов мало знать средний resolved rate. Нужно смотреть tokens per problem, cost per problem, cached tokens, число попыток, SEM, pass@5 и стабильность между несколькими запусками. Один успешный прогон может быть удачей. Пять запусков уже показывают, насколько модель надежна, а не просто иногда попадает в цель.

Отдельно интересно, что SWE-rebench - это не только leaderboard. На HuggingFace версия V1 содержит описание про 21,000+ интерактивных Python SWE-задач для RL-обучения агентов, а для версии V2 уже указаны 32,000+ окружений в 20 языках и 126,000+ дополнительных задач. То есть одна и та же pipeline становится и инструментом оценки, и фабрикой training environments.

В общем, если мы хотим запускать coding agents в реальной разработке, нужно мерить не только "решил или не решил". Нужно мерить свежесть задач, утечки, стоимость, воспроизводимость, надежность, ограничения окружения и поведение агента по шагам. И начинать можно с публичных бенчмарков, а потом переходить к замерам на внутренних задачах.

#AI #AI4SDLC #Engineering #Agents #Evals #DevTools #Software

BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike — Michal Cichra, Safe Intelligence (Рубрика #AI4SDLC)

Разбирался с докладом Michal Cichra из Safe Intelligenc, с которым он выступал на AI Engineer Europe 2026 в Лондоне 8-10 апреля 2026. Доклад мне понравился тем, что автор рассмотрел как агенты ломают неявные договоренности команд и что с этим делать. Например, человек может помнить, почему мы выбрали именно такую границу сервиса, почему не стали тащить зависимость в core, почему этот edge case важен для продукта, а тот можно отложить. Агент этого не помнит. Новый инженер через три месяца тоже часто не помнит. А markdown-спека, которая лежит отдельно от кода и проверок, быстро превращается в музей намерений.

Главная мысль доклада, как я ее понял: команде нужно фиксировать не только требования, но и решения. Причем так, чтобы их могли читать люди, использовать AI-агенты и проверять автоматические контуры. Здесь хорошо складываются три знакомых артефакта, которые зрелые инженерные команды использовали и до AI

1️⃣ Product Requirements Document (PRD) отвечает за product intent
Какую проблему решаем, для кого, какие user journeys считаются критичными, что будет считаться успехом. Это не просто "описание фичи для менеджеров", а источник контекста о том, зачем вообще существует изменение.

2️⃣ Architecture Decision Record (ADR) фиксирует архитектурный выбор
Какие варианты рассматривали, какой trade-off приняли, почему это решение сейчас лучше альтернатив, какие ограничения оно накладывает на будущую разработку. Для AI-агента это особенно важно: иначе он будет оптимизировать локальный diff, не понимая архитектурной цены.

3️⃣ Behavior-Driven Development (BDD) связывает намерение с поведением
Хороший сценарий на человеческом языке описывает не внутреннюю реализацию, а ожидаемый outcome: given конкретный контекст, when происходит действие, then система должна вести себя так-то. В идеале это еще и executable check, а не просто красивая формулировка в wiki

Получается связка: why -> decision -> expected behavior -> verification.

И вот это, кажется, важнее самой аббревиатурной игры в названии доклада. Проблема не в том, что у команд мало документов. Проблема в том, что документы часто не являются рабочим контуром разработки. Если PRD никак не связан с acceptance scenarios, ADR не виден агенту в момент изменения кода, а BDD-сценарии не запускаются в CI, то система живет в двух реальностях. В одной реальности у нас есть красивые намерения. В другой - агент или человек быстро меняет код и проходит пару локальных тестов.

Cichra делает акцент именно на этом разрыве: prompt-based workflow может быть продуктивным, но плохо сохраняет architectural consistency, boundaries и reviewability на масштабе. Поэтому нужны machine-readable specifications, ADR и closed testing loops. Мне кажется, это практичная мысль для команд, которые пробуют coding agents не как игрушку, а как часть SDLC.

Review в таком мире должен проверять не только "хороший ли diff". Он должен отвечать на вопросы: соответствует ли изменение исходному product intent, не нарушает ли оно уже принятое архитектурное решение, покрыто ли важное поведение проверяемым сценарием, есть ли evidence, что система действительно ведет себя как задумано. И это меняет роль документации. Она перестает быть архивом, который открывают перед квартальным планированием. Она становится интерфейсом между людьми, агентами и проверками.

Практически это можно начать легковесно. Для важной фичи держать рядом короткий PRD с problem/goal/user journeys. Для нетривиальных технических решений писать ADR не на десять страниц, а на один экран: context, decision, consequences. Для критических сценариев добавлять BDD-like acceptance checks и запускать их там же, где команда уже проверяет код. Важен не формат ради формата. Важно, чтобы решение можно было восстановить через несколько недель, дать его агенту как контекст и проверить, что реализация не уехала от исходного смысла.

#AI #AI4SDLC #Engineering #Architecture #Software #DevTools