BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike — Michal Cichra, Safe Intelligence

Michal Cichra, co-founder of Safe Intelligence (and previously at Microsoft and Red Hat), delivers a talk on how to capture architectural and product decisions in ways that remain enforceable for both human engineers and AI coding agents. The central premise is that humans and LLMs share a fundamental weakness — limited context — and the only reliable solution is to encode decisions into machine-enforceable artifacts rather than relying on prompts, culture, or memory.

Cichra opens with a parable about five monkeys who learn not to climb a banana-laden ladder through punishment, then keep enforcing the rule even after all original monkeys have been replaced, with no one left who knows why. He draws a direct parallel to software teams where founding engineers leave and LLMs context-compact: without documented rationale, teams repeat mistakes or break rules without understanding them. He notes this problem appears in every organization he has worked at, but emerges far faster with AI than with traditional teams.

The talk covers three complementary specification artifacts. Architecture Decision Records (ADRs) capture not just what the rules are but why they exist, along with code snippets showing how to enforce them. As a concrete example, Safe Intelligence uses module import linting to enforce a strict layering rule: rendering templates cannot access the database, and end-to-end BDD tests cannot import any module that touches the database. This structurally prevents N+1 queries — not by detecting them in code review, but by making them impossible at the import graph level. When an agent's commit violates an ADR, it is rejected at the git hook stage and linked back to the ADR document so the agent can read, understand, and fix the issue.

Product Requirements Documents (PRDs) are kept deliberately lightweight — capturing the why, the problem, the goal, and the user journey through the application. They serve both agents and human engineers who will return to a feature six weeks later having forgotten the original motivation.

Behavior-Driven Development (BDD) with Cucumber closes the validation gap that spec-driven development leaves open: a markdown spec describes how something should work, but it doesn't verify that it actually does. Cichra argues that one of the hardest problems with AI-generated code is that AI-generated tests are even harder to read and review than the code itself. Cucumber's executable, human-readable Gherkin scenarios act as an intermediate layer that can be reviewed, understood, and linked back to PRDs and critical user journeys — and then executed as automated tests.

For UI consistency, Cichra advocates formal design systems: defining primary buttons as blue with specific dimensions, enforcing a rule that only one primary button can appear on a page at any time, and building components compositionally from atomic pieces. Agents are given these definitions and can be evaluated against them.

The enforcement harness ties everything together: git hooks, skills, CI pipelines, linters, type checkers, architecture checks, and document linters all run identically in hooks and in CI so agents cannot skip them. Cichra reports that his agent sessions run 20 to 50 context compacts, and this does not cause problems because the rules live in git and CI — not in the prompt — so they survive context resets. Skill-specific loops (ADR skill, PRD skill, UI loop, test skill) tune the agent's focus within the same generic harness: commit, get feedback, iterate.

The talk concludes that what you cannot find you cannot enforce; the goal is to prevent entire classes of problems structurally rather than detect them case by case. The spec-to-test loop closes with Cucumber, the architecture-enforcement loop closes with module linting, and the decision-capture loop closes with ADRs linked from CI failures.