Most component libraries are designed for human developers. When AI agents are generating the code that uses them, the design requirements shift. Here is what we changed in our component library after a year of AI-native development.
Explicit prop contracts over flexibility
AI agents do better with components that have clear, constrained APIs than with components that are flexible but ambiguous. A Button component with a variant prop that accepts 'primary' | 'secondary' | 'ghost' is used correctly more often than a button that accepts arbitrary className overrides. The constraint is the documentation.
Semantic names over descriptive names
Components named for their role in the design system — SectionHeader, CardContent, MetaLine — are used more consistently by AI agents than components named for their appearance — LargeBoldText, GreySmallText. The semantic name carries intent that the AI can apply to the right context.
Composition over configuration
A Card component with Card.Header, Card.Body, and Card.Footer sub-components generates more consistent output from AI agents than a monolithic Card component with fifty optional props. The composition pattern makes the structure visible in the usage, which helps the agent reason about what belongs where.
TypeScript types as guardrails
Strict TypeScript types catch a category of AI agent errors before they reach review. If the agent tries to pass a string where the component expects a specific union type, the type checker catches it. We treat TypeScript errors in AI-generated code as signals about component API clarity — if the agent repeatedly makes the same type error, the API probably needs to be redesigned.
What we document differently
Component documentation for an AI-native workflow includes explicit do-not-use guidance: which props are deprecated, which combinations produce layout problems, which props should be left at their default. This negative documentation is often more useful than the positive description.