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

Dealing with report Michal Cichra of Safe Intelligenc, with whom he spoke at AI Engineer Europe 2026 London 8-10 April 2026. I liked the report because the author looked at how agents break the implicit agreements of the teams and what to do about it. For example, a person can remember why we chose such a service boundary, why we did not drag addiction into the core, why this edge case is important for the product, and it can be postponed. The agent doesn't remember that. A new engineer often doesn’t remember after three months. And markdown steak, which lies separate from code and checks, quickly turns into a museum of intent.

The main message of the report, as I understood it, is that the team needs to fix not only the requirements, but also the decisions. And so that people can read them, use AI agents and check automatic contours. Here are three familiar artifacts that mature engineering teams used before AI.

1️⃣ Product Requirements Document (PRD) responsible for product intent What problem we solve, for whom, which user journeys are considered critical, which will be considered a success. It's not just a "manager feature description," but a source of context about why change exists at all.

2️⃣ Architecture Decision Record (ADR) fixes the architectural choice What options were considered, what trade-off was adopted, why this decision is now better than alternatives, what restrictions it imposes on future development. This is especially important for an AI agent, otherwise it will optimize local diff without understanding the architectural price.

3️⃣ Behavior-Driven Development (BDD) linking intent to behavior A good scenario in human language does not describe an internal realization, but an expected outcome: given a specific context, when an action occurs, then the system must behave this way. Ideally, this is also an executable check, and not just a beautiful wording in the wiki.

It makes a bunch. why -> decision -> expected behavior -> verification.

And this seems to be more important than the most acronymous game in the title of the report. The problem is not that teams have few documents. The problem is that documents are often not a working outline of development. If PRD is not associated with acceptance scenarios, ADR is not visible to the agent at the time of code change, and BDD scripts are not run in CI, then the system lives in two realities. In one reality, we have beautiful intentions. In another, an agent or person changes the code quickly and passes a couple of local tests.

Cichra emphasizes this gap: prompt-based workflow can be productive, but does not maintain architectural consistency, boundaries and reviewability at scale. Machine-readable specifications, ADR and closed testing loops are needed. I think this is a practical idea for teams who try coding agents not as a toy, but as part of an SDLC.

Review in such a world should not only check if the diff is good. It must answer questions such as whether the change corresponds to the original product intention, whether it violates an already accepted architectural decision, whether the important behavior is covered by a testable scenario, whether there is evidence that the system is indeed behaving as intended. This changes the role of documentation. It ceases to be an archive that is opened before quarterly planning. It becomes an interface between people, agents and checks.

It can almost be started lightly. For an important feature, keep a short PRD with problem/goal/user journeys nearby. For non-trivial technical solutions, write ADR not on ten pages, but on one screen: context, decision, consequences. For critical scenarios, add BDD-like acceptance checks and run them where the team is already checking the code. It's not format for format. It is important that the solution can be restored in a few weeks, given to the agent as context, and verified that the implementation has not departed from its original meaning.

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