All courses / AI Developer / Module 2 / Chapter 6
Learning objectives
After the lesson the participant can:
- Review a design against the five kinds of constraint: boundary, interface, data, failure and security
- Draft an ADR that states who decided, what the tool contributed, what the human added, the dissent and the reversibility
- Explain four mechanisms that weaken an assistant as a design reviewer
- Classify a design decision as the developer's or the architect's by scope and reversibility
Key concepts
- Design as the choice of constraints
- A design is a set of constraints on the code that will be written. Five kinds recur (boundary, interface, data, failure and security), and a design review that does not ask about all five has not reviewed the design.
- ADR fields when AI took part
- Beside the classic fields, the record states who decided (one named developer), what the tool contributed, what the human added or rejected, the dissent, and the reversibility with a review date. Together they apply Name, Understand and Revert to design.
- What the assistant flatters
- Four mechanisms bear on design review: agreement with the user's framing, homogenisation of the options teams consider, blind spots shared between models whose errors are correlated, and automation bias in the person who reads the advice.
- Architectural drift
- The gradual divergence of the code from the design intended for it. The mechanism not in doubt is that a tool sees the files it is given, so a constraint that appears in no file cannot be seen by it.
- Conformance rule
- A machine-checkable rule derived from an ADR that sets a boundary, run in the pipeline and owned by someone other than the generator. No agent may change the rule that checks its own output.
Interactive exercises
Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.
Interactive exercise 1 · Sort
The developer's decision or the architect's
Sort each design decision by who decides it, following the chapter's table of the seam between developer and architect.
Interactive exercise 2 · Scenario
Options first, or the assistant first
Apply the chapter's practical guide for writing an ADR in which an assistant proposed options and a named developer decided.
Teaching plan
| 15 min | Lecture on design as constraint, with Table 6.1; participants name a past outage that became the design review because a failure constraint was unanswered. |
| 15 min | The teacher walks through the worked decision ADR-NR-0031 at Nordvik Region: three options from the tech lead, what the assistant added, and the fourth option from a senior developer. |
| 10 min | Short input on drift, the evidence table and its limits, and the seam to the architect by scope and reversibility. |
| 25 min | Exercise: pairs write an ADR in which an assistant proposed options and a named developer decided. |
| 10 min | Pairs read each other's ADR as the second human who knows the codebase and name the missing option. |
Discussion
- In the Nordvik example the option that changed the discussion came from a person who knows the system, not from the assistant. What does the repository not say in your own codebase?
- The practical guide tells the developer to write their own options before asking the tool. What is lost when the order is reversed?
- The seam to the architect runs along scope and reversibility, not seniority. Which of your team's recent decisions were one-way without anyone saying so?
Written exercise
Exercise · 25 minutes
An ADR with a stated AI contribution
Choose a design decision your team faces, or the status interface between the citizen portal and the case-management system at Nordvik Region. State the decision as a question with its context and non-negotiable constraints. Write your own options first. Then add the options and objections an assistant offered or would be asked for, and at least one option it did not offer. Hold a short pre-mortem: assume the decision failed in a year and record the likeliest reasons. Decide, give reasons in your own words, record dissent, mark the decision one-way or two-way, set a review date, and derive one rule the pipeline could check, with its owner.
Deliverable: An ADR with named decider, tool contribution, human additions, dissent, reversibility, review date and one derived conformance rule.
Self-test
Choose an answer to see whether it is right, or open the answer below each question.
In the worked decision ADR-NR-0031, which element does the decider mark as one-way?
Show the answer
D. The public status vocabulary shown to applicants, because residents rely on it
Anders Falk marks the public status vocabulary as one-way because residents rely on it, and the interface itself as two-way. The enterprise architect is consulted on the vocabulary because it crosses to the citizen channel.Which ADR field is, according to the chapter, the evidence that the decision was the developer's own and not the tool's?
Show the answer
A. What the human added or rejected, with reasons
The field lists the options the tool did not offer and those the developer set aside, with reasons. The chapter calls this the evidence that the decision was not the tool's first answer accepted.Which statement about drift does the chapter treat as a mechanism that does not depend on the studies?
Show the answer
C. A design constraint that appears in no file cannot be seen by a tool that generates code
The evidence on drift is young and partly from vendors. The mechanism the chapter relies on is that a tool sees only the files it is given, which is why each boundary-setting ADR derives a checkable rule.