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