AI and Composition: Getting Slots Instead of Props In short: Ask a model for "a card with an optional badge" and you get . It is not guessing — configuration is genuinely the more common pattern in its training data, and it is the shorter answer. You have to ask differently and check differently. Every lesson in this chapter argued the same thing: composition beats configuration. This one is about the fact that your assistant has the opposite prior. Why models reach for props Three reasons, all structural rather than fixable by a better model. Configuration is what most component code looks like. Years of Angular, React, and Vue components in training data solve variation with props. Composition is the minority pattern, and multi-slot projection with signal queries is a small minority of that. Configuration is locally shorter. Asked for "a card with an optional badge", is one line. The composition answer needs a slot directive, an , a , a , and an export. A model optimising for the immediate request will take the one-liner every time, and by the standard of that request it is right. The cost is invisible from inside the file. Nothing in reveals that it is imported by twenty applications, or that an input is a permanent promise. That information lives in your architecture, and Chapter 2 already established the general shape of this problem: models optimise locally, and this is a global constraint. Ask for the API before the code The highest-leverage change is to split the request in two. Do not ask for a component; ask for its contract, and review that. That last sentence does most of the work. It forces the model to justify each input against the rule instead of producing them by default, and the justifications are easy to check: " — a visual variant of the box, not content." ✅ " — behaviour, applies to the whole card." ✅ " — the text in the header." ❌ That is a slot. Reviewing a six-line API proposal takes thirty seconds. Reviewing a 120-line component to find the same problem takes ten minutes, and by then it is written and the momentum is against you. Put the rule in the rules file Extend your with the specific decision: The / naming rule is unusually effective because it is mechanical. A model can apply it without judgement, and so can a linter. Make the rule checkable Naming conventions can be enforced, which turns a preference into a gate: It will occasionally catch a legitimate name. That is a fine trade — the message tells the author what to do instead, and a false positive costs one comment while a false negative costs a major version. Add the input-count check from the same angle: There is no stock rule for "too many inputs", which makes it a good candidate for the API snapshot job in Chapter 8 — a diff that shows a component going from two inputs to seven is very easy to spot in review. The reflex This is the highest-value line in the rules file, because it saves the most work and models are least likely to do it unprompted. Asked for an accordion, a model will happily produce 200 lines: a group component, a panel component, click handlers, , and — if you are lucky — a partial keyboard implementation. It is plausible code. It will pass review from anyone who does not know the WAI-ARIA accordion pattern by heart. The right output is fifteen lines using . So make it a question the agent has to answer first: Pairing that with the MCP tool matters here more than anywhere else in the course: only became stable in v22, so it is almost absent from training data. A model cannot know about it from memory. It has to look. Reviewing generated components Five things, in order of how much they cost to get wrong: 1. Count the inputs. More than five or six on a layout component is the signal. 2. Look for / . Each one is a slot that did not happen. 3. Check for a hand-rolled ARIA pattern. , , or a on means was skipped. 4. Check . New exports are permanent — Chapter 4's rule. 5. Check for in new code. It should be . Items 3 and 5 are the version-drift ones, and they are the reason the Chapter 1 setup exists. "But I thought I could just tell it to use composition" You can, and it works — for one component, in one conversation, while the instruction is still recent. Three things erode it, and they are the same three from Chapter 1, so the pattern is worth recognising rather than relearning. Specificity beats generality over time. "Prefer composition" is abstract. The concrete request in front of the model — "lab needs a badge in the header" — is vivid, and satisfies it exactly. By turn thirty the abstract rule is competing with thirty turns of specific context, and specific wins. Follow-up requests arrive one at a time. This is the one that actually gets teams. You correctly get a composed card on Monday. On Thursday, in a different session, someone asks for "a compact variant". Nothing about that request mentions composition, the model has no memory of Monday, and is a perfectly good answer to the question asked.…